Agentic Coding: Emerging Architectures and the End of the Single-Agent Session

Coding agents are already a normal part of software development. Codex and Claude Code can work autonomously for long stretches, delegate to subagents, run in isolated environments, and take on increasingly large pieces of software development.

The architecture around them is evolving and expanding out of necessity. The coding-agent session, meaning the chat context you interact with, is no longer the obvious place where the entire job lives.

The single chat window where all your history lives (and that annoyingly is constantly compacting itself) is too constraining for the work we’re asking agents to do. We have outgrown it.

As agents take on larger jobs, work can be divided across multiple workers, carried through external state, and reviewed by separate agents. The agent still supplies most of the intelligence, but the larger system, not any one session, increasingly determines how that intelligence is applied.

Looking across how agentic coding is evolving today, six architectural patterns stand out.

1. The Primary Agent Is Becoming an Orchestrator

Historically, the coding agent and its session have owned most of the flow of work. A developer starts an agent, gives it a task, builds up context over time, reviews what it does, and eventually ends the session. The agent is both the worker and the place where much of the work is coordinated.

That is maturing as coding agents take on larger jobs. A primary agent can delegate pieces of work to subagents, hand work to an independent reviewer subagent, pull context from external systems, or continue work started by another agent. The larger job no longer has to map cleanly to one agent or one session.

A subagent can still have considerable freedom in how it completes an assignment, while the primary agent itself can own much of the outer loop. It delegates work to subagents, collects their results, and decides what happens next.

The orchestration can be as simple as a primary agent delegating work to a few subagents, collecting their results, and deciding what happens next. Or it can involve multiple agents working on different parts of the same job, with the primary agent coordinating the work between them.

OpenAI’s Agents API is one concrete example of this architecture. Its managed Codex harness supports multi-agent orchestration, allowing work to be delegated across agents. The root agent can spawn independent subagents, send them additional work, wait for their results, and combine what they produce. Subagents can even spawn their own subagents, creating a recursive agent hierarchy.

Cursor Projects has a coordinator agent that does not write code itself and intead directs other agents. Cursor’s earlier long-running-agent research arrived at a similar planner-and-worker architecture, with planners recursively creating work and workers concentrating on bounded tasks.

GitHub Copilot custom agents provide another version of the pattern. The main Copilot agent can invoke built-in or custom specialists as subagents with separate context windows, including read-only exploration, research, security review, and second-opinion agents.

Gemini CLI has adopted a similar architecture. Its primary agent acts as an orchestrator while specialized subagents operate with their own context, instructions, tools, and MCP servers. Multiple subagents can work in parallel and return their results to the primary agent.

2. Workers Are Becoming More Ephemeral (and Isolated)

If the primary agent can orchestrate work beyond its own session, then the subagents are just temporary workers. And these workers can increasingly be started and stopped at will by the primary agent.

A job can move between multiple workers, each operating with its own context and responsibility. A primary agent might delegate a bounded task to a subagent. An implementation agent can work in one sandbox or worktree while another agent independently reviews the resulting branch. Different workers can have different models, harnesses, tools, context, and permissions without inheriting whatever happens to be in the original agent’s session.

This does not mean every worker has to be stateless or short-lived. Some jobs are long and context-heavy. The important point is that one worker no longer has to survive for the entire lifetime of the job. It can receive a bounded responsibility, do the work, record the result, and hand control back to the primary agent. The subagent is becoming an execution unit inside the larger agent loop rather than the thing that holds the work together.

This pattern is already visible in current tooling. The Codex app supports multiple agents working in parallel and gives each agent an isolated worktree so they can work on the same repository without conflicting with one another.

Cursor’s worktrees do much the same thing. Each agent can get a separate checkout with its own files, dependencies, and changes. Cursor can also run the same task across multiple models in separate worktrees and let the developer compare the resulting implementations.

Context can be isolated too. Gemini CLI subagents can perform their own tool calls, searches, and tests in a separate context and return the result to the primary agent without bringing the entire subagent history back with them.

Claude Code has moved in the same direction. Anthropic describes subagents as a way to delegate specialized work in parallel, while its Claude Agent SDK exposes the same subagent and permission machinery outside Claude Code itself.

3. Work State Can Move Outside the Agent Session

Once work starts moving between agents, something else has to remember what is happening.

Some of this is the obvious stuff. Git already holds the code and its history, while GitHub and Linear can store work items. But as work moves between agents, more of what previously lived implicitly in the conversation can move outside it: plans, decisions, requirements, findings, repository knowledge, and other state that another subagent can pick up without inheriting the entire session.

Coding agents can also pull from wikis, company knowledge systems, shared memories, architectural documentation, and other sources that survive regardless of which agent is currently performing a given step. The work does not necessarily need to move between agents as a giant transcript. Instead, the relevant state can exist independently and each worker can get the context it needs.

There is not yet a standard way to represent all of this. Some state lives in Git, some lives in issue trackers, some is Markdown, and some sits in databases, wikis, or vendor-specific shared memory systems. The format is less important than the overall architectural possibility here: the work can outlive the session.

GitHub Copilot Memory is a direct example. Repository-level facts learned by one Copilot feature can be stored with citations back to the code and later reused by another feature, so knowledge discovered during one interaction does not have to disappear with that interaction.

Cursor Projects takes a similar approach at a larger scope. A Project maintains shared files across the cloud and local machines its agents use, and agents can add research, artifacts, and things they learn about the codebase for later workers to reuse.

Claude Code supports persistent subagent memory and project-level rules, skills, MCP configuration, and agent definitions outside the conversational history.

4. The Agent Loop Is Becoming Programmable

The harness itself is also becoming something developers can program around. Instead of only giving the agent instructions and tools, coding assistants increasingly expose ways to run code at different points inside the agent loop.

Claude Code, Cursor, GitHub Copilot, and Gemini CLI all now support hooks that run at different points during agent execution. Depending on the system, developers can intercept tool calls, run validation after file changes, inject context, enforce policies, or react when a subagent finishes.

That creates another way to control what happens inside the loop. Some behavior can come from instructions to the model, while other behavior can be deterministic code that runs at specific points. A company can enforce a security check before a tool call, run validation after an edit, or record what happened when a subagent finishes without relying on the model to remember to do it.

Skills are developing alongside hooks. Cursor, GitHub Copilot, Claude Code, and Gemini CLI can load packaged instructions, scripts, and other resources when they are relevant to a task. Gemini CLI extensions can package skills, hooks, subagents, MCP servers, commands, and policies together.

The coding assistant is becoming more than a model inside a tool loop. The loop itself is becoming something developers can extend.

5. Agent Loops Are Becoming Goal-Driven

Early coding agents were mostly organized around turns. A developer asks the agent to do something, the agent works for a while, returns a result, and the developer decides whether it is actually finished. If it isn’t, the developer sends it back to work.

Newer coding assistants are becoming goal-driven. Codex now has /goal, which lets a developer define a completion condition rather than just the next task. The agent can work, test what it produced, evaluate the result against the goal, and continue working if the condition has not been met. The human no longer has to be the thing that keeps restarting the loop.

A goal might be to get every test passing, reach a particular performance threshold, or complete a migration while keeping an existing test suite green. Instead of the agent deciding it has finished or the developer manually sending it back to work, a completion condition can keep the loop running.

There are related versions of this pattern elsewhere. Cursor’s long-running agents use plans and multiple agents checking one another’s work to keep larger tasks moving toward completion, while Cursor’s agent harness can use a browser to test its own changes and continue iterating on the result. Anthropic’s newer Claude Code dynamic workflows similarly run parallel subagents and verify their outputs before returning the result, including using an existing test suite as the bar for large migrations.

6. Chat Is Becoming Less Central

The chat session has been the primary interface for most coding agents. A developer gives the agent instructions, watches it work, answers questions, and reviews the result in the same conversational thread.

As more of the work moves outside that session, the interface can change too. A developer might assign work through an issue, define a goal, review a plan or diff, approve an action, or respond when the agent asks for help. GitHub, for example, now allows coding agents to be assigned directly to issues and pull requests, making the work item itself another entry point into the agent. GitHub supports its own Copilot cloud agent as well as third-party agents including Codex and Claude.

This becomes especially important when multiple agents are involved. A developer probably does not want to follow the conversational history of every subagent. Instead, we can interact with the state of the work, the decisions that were made, and what evidence was produced.

The chat window does not disappear, but it becomes one interface into the work rather than the container that holds the work itself.

Cursor 3 is another good example. Local and cloud agents can be started and managed across the desktop app, web, mobile, Slack, GitHub, and Linear, with the interface centered on the work agents are doing rather than a single conversation.

Google has also split the interaction model between Gemini CLI and Jules. Gemini CLI can remain the interactive agent in the terminal while work is delegated to Jules, which runs asynchronously in a remote environment and returns the resulting changes later.

Anthropic is pushing the same idea into team communication with Claude Tag, where work can begin by tagging Claude inside a Slack channel and the resulting context is shared with the team rather than belonging to one developer’s private coding-agent conversation.

Where Agentic Coding Goes Next

The coding agent has been a convenient unit of abstraction because the model, context, tools, and work all fit reasonably well inside one session. That is no longer the only way to organize the system. The next generation of coding systems may be defined less by the capabilities of any single agent and more by how well intelligence can be composed across models, harnesses, state, and execution.

There is a lot more to improve here than simply making Codex or Claude better at coding. The models underneath those systems will keep improving, but the architecture above them has plenty of room to improve independently.