The teams getting the most out of AI right now aren’t the ones with the flashiest assistant. They’re the ones who worked out that the model is the easy part, and the harness around it is the hard part.
Plenty of capable agentic harnesses already exist. Codex, Claude Code, and their peers are genuinely agentic, they run frontier models, and a lot of good teams use them every day. Point one at your codebase and it can absolutely build an Edge Delivery block. The catch isn’t capability, it’s consistency. They’re generalists by design, built to do anything, so they show up without the integrations, domain expertise, environment visibility, and project context that make output land right the first time instead of somewhere on a spread of plausible attempts.
That gap costs real money in a way that’s easy to miss. When a generalist agent’s knowledge doesn’t line up with your project or a business rule, it does exactly what it’s built to do and reaches for a web search, which pulls in generic patterns and pushes the result further from what the project actually needs. A skilled engineer can still get there, with careful prompts and a few rounds of correction, but every round is more tokens. “Eventually right” has a meter running on it.
So the realization spreading through the industry is real: the advantage isn’t the model, it’s a harness built for the job in front of you. Which sounds great until you price it. Building a purpose-fit harness is real work, much of it repeated per project, and getting a whole team onto a common way of working inside it is its own overhead, the AI-era cousin of onboarding developers and configuring their local environments, with fewer guarantees the setup will hold.
There’s a quieter cost underneath, too. AI has obfuscated how work actually gets done. A team lead can’t easily see the reasoning behind what shipped, and developers can’t learn from how a teammate solved something, because the thinking happened inside a tool and left no trace anyone can follow. The craft that used to travel across a team by watching each other work has gone dark.
Launch Studio is our answer to all of it. It isn’t a general-purpose harness you have to furnish yourself. It’s a harness built for Adobe delivery, with the domain knowledge, integrations, environment visibility, and governed memory already inside it, tuned to use the right tools without burning tokens it doesn’t need to, and wrapped in a management layer that makes the work legible again. The rest of this post is the parts that make that true.
The model isn’t the moat, and neither is a generic harness
Everyone rents the same models. We do too, and so do Codex and Claude Code. If the product were the model, there’d be no product, because your competitor can rent the identical one this afternoon.
A generic harness isn’t the moat either, for a related reason: anyone can stand one up, and then everyone is stuck maintaining it. What’s hard to replicate is a harness built for a specific domain and kept that way: the domain knowledge wired in, the requirement that it plan before it builds, the rule that it never grades its own work, the governed memory it carries between jobs, the discipline to use the right tool and cache the rest, and the visibility that lets a team see and trust the result. That’s the thing we build, and it’s why the same underlying model produces practice-grade Adobe delivery inside Launch Studio and a plausible first draft inside a bare general-purpose agent. Keep that in mind through the pieces below. Each one is a part of that harness, not a model feature.
It actually knows Adobe
A frontier model knows an enormous amount about software in general and very little about your project in particular. Ask it to build an Edge Delivery block and it can do it, but it’s reconstructing Adobe’s conventions from whatever it picked up across the public internet, so the result shifts from run to run and drifts toward generic web patterns wherever its sense of EDS is thin. Right sometimes is not the same as right reliably.
So the foundation is first-party domain expertise. Launch Studio carries a curated knowledge base of Adobe and Edge Delivery documentation, indexed for semantic search, so the agent builds against real EDS conventions instead of generic web patterns. It knows what a block is. It knows the difference between a document-authored project and a JCR-sourced one. It knows the shape of the repo Adobe expects. That grounding is the difference between code that compiles and code that belongs in an AEM project, and it’s the first reason the output is trustworthy enough to ship.
This is also what makes the rest of the platform specific rather than generic. When we say the platform reasons, we mean it reasons about Adobe delivery, with Adobe’s own guidance in context, not about software in the abstract. And when its knowledge doesn’t cover something, grounding is the default rather than a quiet fallback to a web search and a hope.
It uses the right tools, and caches the rest
Domain knowledge, planning, and memory get most of the attention, but there’s a less glamorous half of a harness that decides whether the whole thing is affordable: which tools and skills get used, when, and how often the same work gets paid for twice.
The generalist habit is to load a big library of skills and tools into context, twenty-five or more, and let the model choose the right one for each request. That’s expensive twice over. The extra context is tokens on every single call, and a wrong choice sends the agent down a wrong path that then has to be redone. Common development workflows and tool chains get re-run from scratch, uncached, every time they come up.
A good harness works the other way. It detects intent, so it knows which skill or tool a request actually needs and reaches for that one rather than the whole shelf. It caches requests and tool chains wherever it can, so predictable, repeated work isn’t billed again and again. This is table stakes for anything meant to run all day, and it’s exactly what generalist setups tend to skip.
The consequence lands about a month after onboarding, when the token bill comes in far higher than the demo implied. A lot of teams are having that sticker shock right now. And it’s worth being clear-eyed about why it doesn’t get fixed upstream: a frontier vendor’s revenue is a function of tokens consumed, so the incentive to make each task cheaper runs against the business model. A first-party harness has the opposite incentive, to get the job done right the first time and not pay for the same tokens twice.
It plans, builds, and checks its own work with fresh eyes
Ask a general-purpose agent for something and it starts typing. Ask Launch Studio and it drafts a plan first.
That ordering is deliberate, and it’s a core piece of the harness. The platform turns a request into a plan with explicit, checkable acceptance criteria, and waits for a one-tap approval before it writes anything. You see the intended approach while it’s still cheap to change, instead of discovering the approach by reading the finished code. Requirements come before implementation, the way they do on any team that ships reliably.
Once the plan is approved, an orchestrator executes it task by task. A development agent does the building in an isolated sandbox. Then the part that matters most: a separate QA agent, with fresh context and no exposure to how the code was written, verifies the result against the acceptance criteria that were set during planning, with screenshots across multiple viewports as evidence. The builder never signs off on itself.
That single rule carries an enormous amount of weight. An agent that wrote code is biased toward that code working, for exactly the reason a developer is a poor reviewer of their own pull request. Splitting the build and the check across two agents, and fixing the criteria before either runs, means “done” stops meaning “the model says it’s done” and starts meaning “an independent check produced evidence that it’s done.” We made the fuller architectural case for that separation in Why You Need an Agentic Platform, Not More AI Tools. It’s what earns the trust the whole platform rests on.
It learns, and you control what it remembers
Most AI memory is either nonexistent (every session starts from zero) or a black box (it remembers things you can’t see, edit, or trust). Both are wrong for delivery work, where the useful knowledge is specific and the stale knowledge is dangerous.
Launch Studio’s memory is yours to control, scoped per project. As the platform works, it captures durable build learnings: this repo’s nav lives here, this project authors in the Universal Editor, this client’s brand rules work like that. Those memories live in layers (organization, project, personal), they carry expiry and re-verification so a belief that was true in March can’t quietly calcify into a wrong assumption in July, and they surface in a manager interface with toggles for what gets captured and what gets used. You can look at what the platform believes about your project, and you can change it.
This is also part of the answer to work going dark. Because the memory is shared and inspectable, what one person’s project run learned doesn’t vanish into a private session; it becomes a team asset the next person inherits. The hundredth build in a project is more reliable than the first, because the platform accumulates real context instead of relearning the same things every session, and that context belongs to the org rather than to whoever happened to run the job.
It’s built to run many implementations, not demo one
A general-purpose agent can dazzle in a single session. An agency needs to run dozens of client properties without the wheels coming off, and that’s a different problem than being clever once.
The operations layer wraps around the agents. Planning, with plans and checkable acceptance criteria you can track. System configuration, so agent presets, connections, and skill and brand context are set once and applied everywhere instead of reconfigured per project. And monitoring: token governance and usage you can actually see, run history you can audit, and scan-driven Loops that turn findings from an audit directly into a plan the platform can execute. That last piece closes the gap most tools leave open, where a scan produces a report that sits in a dashboard and nothing happens. Here the finding becomes work.
This is also where the obfuscation problem gets solved. The plans, the runs, and the evidence are all visible and auditable, so a lead can see how something was built and why, not just that it shipped. The layer that lets one or two people oversee many client implementations with confidence is the same layer that makes the work legible again, at portfolio scale rather than one clever conversation at a time.
Why this is the through-line
Put them together and you have the reason a lean team can deliver Adobe work at practice grade. It knows Adobe, it plans before it builds, it verifies with fresh eyes, it uses the right tools and caches the rest, it remembers on your terms, and it’s manageable and legible across a whole book of clients. Each of those is a part of the harness a generalist tool leaves you to assemble yourself, built once and kept fit for this domain, and the harness is the product.
It’s also the engine under everything else we’ve written lately. The model-driven migration that maps a source once and lands it across multiple Adobe destinations, the safe Contentful content operations with reversible promotion, the dual-source Launch Kit that scaffolds a DA or JCR project in minutes: those are all this platform pointed at specific jobs. The reasoning, planning, verification, and memory are what make each of them repeatable instead of a one-off.
That’s what we mean by Agentic Delivery. Strategy and design stay human, where judgment belongs. The reasoning and the delivery become agentic, disciplined enough to trust with the build, and visible enough to learn from. Not a general-purpose tool you have to turn into a delivery platform yourself, but one built for the job.
If you want to see it rather than read about it, we can walk you through a real request getting planned, built, and independently verified in about twenty minutes. Tell us what you’re working on and we’ll show you the loop end to end.
