Classic development workflows follow a circle: a person, an edit, an error, and finally a fix. Instead, agentic development has a loop that goes from human to agent to review. The person becomes the boss, not the execution engine.
Most teams still think of agents as ‘better code completion,’ which is just a plugin feature added to existing tools. That works for demos, but it doesn’t work in production because agents do more than just write code. They follow through on plans, use call tools, run builds, and manage workflows with more than one step. That needs a separate runtime that works differently from a human IDE.
The teams that are getting real value from agents realise that you can only scale agentic development by breaking the stack into three parts: the app, the agent, and the workspace.
The three layers of agentic development
Production-grade agent stacks break down into three distinct layers:
- The app layer — the interface where developers interact, review, and approve changes
- The agent layer — the AI reasoning engine that plans, coordinates, and makes decisions
- The workspace layer — the secure, isolated environment where code actually executes
This separation matters because collapsing these layers creates real problems. When agents operate through desktop tooling, there’s no centralised policy enforcement, no audit trail, and no way to govern what the agent can access. And when a single system tries to handle the UI, reasoning, and execution all at once, it breaks down as tasks grow in duration and complexity.
The app layer is where humans direct and approve. The agent layer decides what to do. And the workspace layer — running on centralised, cloud-based infrastructure — executes the work in environments that are standardised, ephemeral, and governed by IT. No local state. No ungoverned access. Full visibility into what every agent is doing, and where.
The performance issue that no one is talking about
Most agent stacks can only handle one agent. Resource limits show up immediately on laptops. IDE overhead, background services, and one agent are manageable, but when you add two or three, things slow down and become unstable. Cloud VMs (Cloud Virtual Machines) are not an easy fix either. When you share them, you get ‘noisy neighbour’ variance, and when the system is under-provisioned, agents look slow on machines that are too small.
The three-layer architecture changes this by letting the workspace layer scale horizontally. You don’t have to wait for one agent to finish each task. Instead, you run a small fleet in parallel, doing tests, refactors, dependency updates, and validation all at once.
A quick look at the math shows that while five 10-minute tasks will take 50 minutes when done one after the other, they take just 10 to 15 minutes when carried out by multiple agents simultaneously.
But speed alone isn’t enough. Agents are only useful when they have the right context and tools to operate correctly. Things like your team’s style guides and repository conventions, your linting and test workflows, and access to the internal documentation and systems that explain how the software actually works. They also need credentials that are appropriately scoped for the task.
The error is treating agent and human access the same. Humans can be allowed more privileged access due to human intentionality and the potential for consequences. Because agents are quick, persistent, and probabilistic, agent privilege needs to be tightly limited and enforceable through practical controls such as network and egress restrictions, scoped secrets with short-lived credentials, audit logs for every action, and sandbox boundaries per agent, task, or branch.
MCP (Model Context Protocol) is a natural choice for providing access to tools consistently in this situation. For example, an agent can log into GitHub, read internal repos, run tests, and open PRs (Pull Requests), but they can’t access the public internet or write outside of a controlled workflow. That’s how you gain power without losing control.
Why vertically integrated stacks don’t work at scale
Vertical stacks (a setup in which one vendor provides everything end-to-end in a single, bundled system) are usually faster to adopt and easier to use. But they often fall short for businesses, because at scale, teams need:
- Auditability
- Data residency and compliance controls
- Internal tool integration
- Predictable resource allocation
- Multi-model flexibility
If you use a single vendor for UI, agents, and runtime, you are operating under the vendor’s rules, not yours. That can be helpful at first, because there are fewer decisions to make. However, over time, the vendor’s rules can conflict with your organisation’s needs, as you can’t easily introduce new internal policies, connecting custom or legacy systems can become awkward, or near impossible, and you can lose control over data flow.
Building for the third wave
We’ve already seen two waves of AI-assisted development. The first wave was about finishing code faster. Tools like autocomplete improve speed, but the human still does the work end-to-end. The second wave introduced agents that can chat with you, take on larger tasks, explain changes, and even make edits, but most of the work still happens one request at a time.
The third wave will involve teams of agents running in parallel and operating more independently. That shift will demand infrastructure that provides scheduling, orchestration, isolation, and cross-agent coordination, because the main constraint becomes the number of agents each developer can run safely and reliably. If you’re building for that future now, start with the workspace layer, because it’s the foundation for both parallelisation and governance as agent independence increases.
Architectural decisions that matter in 2026
Agentic development is a new way to make things, and it’s clear that the winning approach is to break up the stack: own your workspace layer, rent your models, optimise for parallel agents instead of sequential workflows, and treat governance as mandatory, not optional.
By the end of 2026, strong teams won’t have one agent for every developer. They’ll run more than ten stacks, and the ones that win will be flexible at the app layer and controlled at the workspace layer.
