What Happens When AI Agents Stop Working Alone?

A developer describes an emerging pattern in AI-assisted software development where a powerful frontier model creates an implementation plan and a smaller, local coding model executes it. This separation of reasoning from execution reduces inference costs and reveals that the quality of results depends more on the planning phase than on the implementing model's intelligence.

Something interesting is happening in AI-assisted software development. We are getting very good at giving an AI agent a repository and a problem and letting it figure things out. The agent can explore the codebase, understand dependencies, make changes, run tests, interpret failures and continue working until it reaches a result. That is already changing the role of the developer. But there is another change happening underneath it that I find even more interesting. We are beginning to realize that the most capable model does not necessarily need to do all of the work. A recent approach to AI-assisted development illustrates this well: use a powerful frontier model to understand the problem and create the implementation plan, then let a smaller or local coding model carry out the implementation. At first, this sounds like a way of reducing inference costs. It is. But I think it reveals something much more fundamental about where agentic AI is going. When an AI coding agent receives a request such as “add customer notifications,” it isn't really being asked to write some code. Before it can write anything meaningful, it has to understand the system around that code. It needs to discover where customers are represented, how changes are propagated, which messaging infrastructure already exists, where the relevant business logic lives, what persistence mechanisms are being used and what conventions the existing application follows. Then it has to make decisions. Should the notification be synchronous or asynchronous? Should it be a new service or part of an existing domain? What happens if delivery fails? How should duplicate events be handled? Which existing abstractions should be reused? Only after all of that does implementation become relatively straightforward. This is an important distinction because those activities require very different kinds of capability. Understanding an unfamiliar architecture is a reasoning problem. Creating another repository class after the architecture has already been established is mostly an execution problem. Yet when we use a single autonomous agent, we ask the same model to perform both. That isn't necessarily wrong. Frontier models are increasingly capable of doing it. But it is not necessarily the most efficient architecture either. Imagine that the first agent has already explored the repository and produced a detailed implementation plan. It has identified the existing customer domain, the event infrastructure and the transaction boundaries. It has decided that the notification capability belongs in an existing bounded context. It has specified which components need to change, which interfaces should remain untouched and what the tests need to prove. The second agent now receives that plan. Its job is no longer to figure out what the system should become. Its job is to make the system become it. That is a much smaller problem. And this is where local models become particularly interesting. A smaller model may struggle when asked to independently understand a large, unfamiliar architecture. But once the problem has been decomposed and the constraints are explicit, the same model may be perfectly capable of implementing the individual changes. The quality of the overall result no longer depends entirely on the intelligence of the implementation model. It depends on the quality of the reasoning that happened before implementation . That gives the plan a new role. It is no longer just documentation. It becomes the contract between two different forms of intelligence. There is nothing particularly new about separating reasoning from execution. We do it in human engineering teams all the time. An architect doesn't normally implement every line of a system. A technical lead doesn't personally write every test. A developer doesn't make every architectural decision from scratch for every task. The organization divides the problem. People specialize. Information moves between those specialists in the form of artifacts: architecture decisions, specifications, designs, acceptance criteria, test plans and tickets. AI agents are beginning to create the same possibility in software. The difference is that an AI system can potentially make those decisions dynamically. A task can be analyzed, decomposed and assigned to different agents depending on what is actually required. A complex architectural decision might go to a frontier reasoning model. A well-defined coding task might go to a local model. A database migration might be handled by a deterministic tool. A security-sensitive change might require another model to review the result. The interesting part isn't that we have several models. The interesting part is that something has to coordinate them . This changes the way I think about AI agents. We have spent a lot of time treating an agent as if it were an employee: give it a goal, give it tools, and let it get the job done. That works surprisingly well for small problems. But as the problems become larger, the agent itself starts looking less like an employee and more like a component in a distributed system. A business objective becomes a workflow. The workflow is decomposed into tasks. Tasks acquire context. Context is passed to agents. Agents use models and tools. Results are validated. Failures create new tasks or trigger replanning. The system maintains state throughout the process. Once you look at AI this way, model selection becomes only one part of the problem. The bigger challenge is coordinating the entire execution. This distinction becomes unavoidable when AI moves into large organizations. An autonomous agent operating against a developer's personal repository is one thing. An agent operating against a bank's production environment is something entirely different. The organization needs to know what the agent is allowed to see and what it is allowed to do. It needs to control which tools are available, where sensitive information can be processed and which actions require human approval. It needs to understand what happened when something goes wrong. It needs an audit trail. It needs policies. It needs observability. And it needs the freedom to change the underlying AI models without rebuilding the entire automation layer. These requirements have little to do with whether Claude, GPT, Llama or another model is currently the best model. They are properties of the system surrounding the models . That system is the orchestration layer. The rapid improvement of local models adds another dimension. A company can potentially keep its source code and sensitive data inside its own environment while using local models for implementation and routine execution. At the same time, it can use a much stronger model for problems where deeper reasoning is worth the additional cost or where local models are not yet capable enough. There is no reason these have to be competing architectures. They can be different workers in the same workflow. That means the decision is no longer simply “cloud AI or local AI.” It becomes a routing decision. Where does this particular task belong? Which model has the capability required to solve it? What information does it need? What is the cost of using it? How sensitive is the information? How much autonomy should it have? Those decisions can themselves become part of the orchestration. And once that happens, the AI system starts to behave less like a chatbot and more like an operating environment for intelligent work. This is also the thinking behind Archy. We started from a very practical problem: how do you make AI agents useful when the work itself is complex, interconnected and continuously changing? It is tempting to solve that by building a better agent. We believe the more interesting problem is building the environment in which agents work. Archy provides that environment. A goal can be turned into a structured workflow. The workflow can be broken into tasks and dependencies. Agents can be assigned to those tasks. Different models and tools can be used where they make the most sense. Context can be provided at the point where it is needed rather than indiscriminately passed to every agent. Execution can be observed and validated, and the workflow can react when reality differs from the original plan. That is why Jira is a use case for Archy rather than its definition. A Jira backlog happens to be a very useful representation of work. It contains objectives, dependencies, priorities and acceptance criteria, making it a natural environment for demonstrating agentic orchestration. But the same underlying architecture can be applied to much more than software delivery. An enterprise migration. A regulatory change. A customer onboarding process. A technology modernization program. A complex operational procedure. In each case, the problem is essentially the same: take an objective, understand what needs to happen, coordinate the necessary intelligence and tools, and bring the work to a controlled outcome. This is probably the most important conclusion I take from the recent experiments with frontier models and local coding models. We are entering a period where models will change incredibly quickly. Today's best reasoning model will eventually be replaced. Today's impressive local coding model will become ordinary. New specialized models will appear for tasks we haven't even considered yet. If the architecture of an AI system is built around one particular model, every improvement in the model landscape becomes an architectural disruption. If the architecture is built around goals, workflows, tasks, capabilities, context and policies, the models become replaceable components. That is a much more sustainable way to build enterprise AI. The question stops being which model should run the whole process. Instead, the system can decide which intelligence is appropriate for each part of the process. A frontier model can reason about the architecture. A local model can implement it. A deterministic tool can execute a migration. Another agent can test the result. A human can approve the decision that matters. And the orchestration layer keeps the whole thing coherent. I think this is the transition we are beginning to see. The first generation of AI applications was largely about putting a model behind an interface. The next generation is about giving models tools. The next step is more consequential: coordinating multiple agents, models and tools around an outcome. That requires state. It requires context. It requires planning. It requires routing. It requires governance. And it requires a way to recover when the plan meets reality. In other words, it requires architecture. The exciting part isn't that we can now make an AI agent write code using another AI model. The exciting part is that we are beginning to build systems in which different forms of intelligence can work together. That is a much bigger opportunity. The future of AI may not belong to the single smartest agent. It may belong to the platform that knows which intelligence to use, when to use it, and how to make all of it work together. That is the problem Archy is being built to solve.