The New Agent Stack Is a Control Plane

The first agent systems looked like chat wrapped around tools.

That was enough to prove the shape. A model could read a request, choose a tool, inspect the result, and continue. A few well-described tools could turn a chat window into something that felt active.

Then the systems started doing real work.

They edited repositories. They opened tickets. They touched customer data. They scheduled follow-ups. They ran in the background. They retried after failures. They asked for approvals. They needed to explain what happened after the operator came back hours later.

At that point, the agent is no longer just a prompt with tools.

It is part of a control plane.

Tools Are Not Enough

Tool access is the obvious first layer of an agent stack. The agent needs a way to search, read, write, call APIs, inspect logs, run builds, and communicate with people.

But tool access alone does not make the system safe or reliable. In fact, unrestricted tool access often makes the failure modes worse. The agent can do more, so a bad assumption has a larger blast radius.

A production stack has to answer questions the model should not be trusted to improvise every time:

• Which tools are available for this task?
• Which credentials can they use?
• Which paths, accounts, or environments are protected?
• Which actions require approval?
• What evidence is required before the run can say it is done?
• What happens if the work stalls halfway through?

Those are control-plane questions. They sit around the agent loop and shape what the loop is allowed to do.

Without that layer, the agent has to infer policy from instructions. That can work in a demo. It is not enough for production.

Permissions Become Product Design

Permissions are usually treated as a security concern. They are also product design.

A read-only research agent feels different from an agent that can edit files. An agent that can edit files feels different from one that can push to main. An agent that can draft an email feels different from one that can send it. The user experience changes at every permission boundary.

Good agent systems make those boundaries explicit. They do not rely on one giant instruction that says “be careful.” They separate observation from mutation. They separate local work from public publishing. They separate reversible actions from irreversible ones. They make approval prompts specific enough that a human can make a real decision.

The question is not only “can the model do this?”

The question is “should this run, in this state, with this evidence, be allowed to do this now?”

That is a control-plane decision.

State Is the Difference Between a Run and a Worker

A stateless chat session can be useful. It can answer a question, draft a paragraph, or walk through a task.

A worker needs state.

It needs to know what work item it owns, what it has already tried, what evidence it collected, what changed, what is waiting on a person, what failed, and what is safe to resume. It needs to survive a timeout, a process restart, a rate limit, or a human going offline.

This is where many agent demos quietly break. The reasoning loop looks impressive, but the surrounding state is fragile. Work lives in a browser tab, a terminal buffer, an in-memory queue, or a single conversation transcript. When anything interrupts the happy path, the system cannot distinguish unfinished work from forgotten work.

A control plane turns agent work into durable objects.

The task is pending. The task is running. The task is waiting for approval. The task is blocked. The task recovered. The task completed with evidence. Those states are not bureaucratic overhead. They are what let the system operate outside a single uninterrupted chat turn.

Observability Has to Include Intent

Traditional logs can tell you what code ran. Agent observability has to tell you more.

What did the agent see? Which assumption did it make? Which tool result changed the plan? Which validation gate passed? Which warning was ignored? Which approval unlocked the next step? Why did the run decide the work was complete?

If the system only logs API calls, operators are left reconstructing intent from fragments. That is not enough when the agent is choosing the next action dynamically.

A useful control plane preserves the shape of the run: request, context, tool calls, outputs, decisions, validation, retries, recovery, approvals, final evidence. Not private chain-of-thought. Operational evidence.

That evidence matters when something fails. It also matters when something succeeds and the team wants to trust the result again.

Approvals Need Context, Not Theater

Human-in-the-loop is often described as a feature. In production, it is a boundary.

A weak approval prompt asks, “Allow this action?” A better one says what will happen, what evidence supports it, what could go wrong, and what the user is actually approving.

That distinction matters because agents can create approval fatigue. If every step asks for permission, people stop reading. If no step asks for permission, the system crosses boundaries silently. The control plane has to decide where approval belongs and make each approval meaningful.

Publishing a blog post, modifying production data, sending a customer message, merging a pull request, or spending money should not be hidden inside a generic continuation prompt. Those actions need named gates with enough context for the operator to say yes, no, or revise the plan.

Approvals are not there to make the agent look supervised.

They are there to keep authority aligned with risk.

Recovery Is a First-Class Path

Every serious agent stack eventually learns that failures are not all the same.

Some failures deserve a retry. A network call timed out. A page loaded slowly. A dependency rate-limited the request.

Other failures require recovery. The agent searched the wrong place. The build output contradicted the plan. The public route returned a fallback page instead of the new content. The tool succeeded technically but did not prove the task was done.

A control plane gives recovery somewhere to live. It can preserve the failed evidence, update the task state, narrow permissions, ask for approval, fork a new attempt, or stop with a precise blocker. The alternative is to let the agent keep improvising inside the same loose loop until it produces a confident summary.

That is how quiet failures become expensive.

Recovery should be designed, not hoped for.

The Stack Around the Model

The model still matters. Better models make better judgments, follow longer context, and use tools more effectively.

But the agent stack is increasingly defined by the system around the model:

• Identity and scoped credentials.
• Tool registries and permission policies.
• Durable task state and queues.
• Sandboxes and protected paths.
• Structured outputs and validation gates.
• Traces, artifacts, and human-readable audit logs.
• Approval workflows.
• Retry and recovery policies.
• Notifications, schedules, and handoffs.

That is infrastructure. It is also product surface. Users experience it as trust: whether the agent knows what it is allowed to do, whether it can explain itself, whether it stops before risky actions, whether it can resume after interruption, and whether its final answer is backed by evidence.

The winning agent platforms will not be the ones with the longest prompt templates.

They will be the ones with the clearest control planes.

The Practical Takeaway

If an agent is only answering questions, a prompt and a few tools may be enough.

If it is doing work, the control plane becomes the product.

That means building the boring surfaces early: permissions, state, logs, approvals, validation, recovery, and deployment boundaries. It means deciding what the model should judge and what the system should enforce. It means making authority explicit instead of burying it in instructions.

Agents are moving from chat features to operating layers.

The stack has to grow up with them.