Book a call

Control

The agent can only do what it should.

Control is made of three disciplines: Capability, Delegation, and Environment. Capability sets what the agent can do at all: the tools you connect and the ones you withhold, like a database it can read but never write. Delegation sets what it decides alone versus what waits for a person, like merging a dependency bump on its own but never running a production migration. Environment is the machinery that catches mistakes, the tests and checks a change must pass before it ships.

Control

The agent can only do what it should.

Control
The domain

The business outcome

Moving fast without betting the company on an agent's judgment. A bounded agent can be trusted with more work, and several can run at once, because a mistake stays small and every action has an answer to who allowed it.

Before investment

Safety depends on each engineer's personal caution. Agents hold credentials nobody remembers granting, a confident mistake can reach production before a person sees it, and after an incident nobody can say what the agent was allowed to do. So everything gets re-reviewed by hand, and the speed you were buying evaporates.

After investment

The boundaries are set once and hold for everyone. Agents get the access the work needs and nothing more, high-stakes calls are reserved for people by design, and most mistakes die in a failing check instead of a postmortem. That is what makes it safe to hand agents bigger work.

The three disciplines

Capability

An agent is only as useful as what you let it touch, and only as safe as what you keep out of its reach. Capability is the discipline of connecting your agent to the systems the task calls for: the test runner that proves its work, the PR tooling that carries a change toward review, the staging environment where it can try things without consequence. The other half of the discipline is deliberate withholding: production, the credentials that open it, and the destructive commands are kept where no prompt can reach them.

The question

Can our agents reach the tools the work needs, and are they walled off from the ones that could do real damage?

Delegation

Control buys your team speed inside safe boundaries, and Delegation is where you draw the line that makes the speed safe: what an agent handles without asking, what it brings to a person first, and how much work you hand it at once. You let the agent draft freely, explore an approach, and propose the change, then have it pause at the moves that are expensive to walk back: before it merges a PR, ships to production, or touches a database. When that line is deliberate, you get the throughput of an agent that rarely blocks and the calm of knowing the riskiest actions still pass a human gate, so a confident wrong call costs a review comment instead of an incident.

The question

Which decisions do we let an agent make on its own, and which still wait for a human?

Environment

The work an agent produces is only as trustworthy as the harness it runs inside. Environment is that harness: the lint and test gates a change has to clear before it counts as done, the branch or worktree isolation that keeps two parallel runs from overwriting each other, the handoff points that force a checkpoint before work moves on. When those checks are built into the environment itself rather than left to whoever is paying attention, mistakes get caught where they happen instead of in a reviewer's lap. Your team stops finding out about a broken build or a colliding branch after the fact, and quality stops being something you pay for downstream: fewer surprises, less cleanup, parallel agents that stay out of each other's way.

The question

Does the system around the agent catch its mistakes before they land, or do we find out in review?

In your org, each of these disciplines already sits at one of four investment tiers: , , , or . Every discipline page walks all four: what each tier buys, what it costs to maintain, and the techniques that get you there.

Domain overlap

Control's disciplines read as separate budgets: what the agent can reach, what it may decide, and what catches it when it is wrong. The safety is in how they combine, and the same tensions reach across into Context, Observability, and Improvement. Treat each pairing as one funding decision, not two.

Within Control

  • Capability and Delegation

    Capability sets what the agent can reach; Delegation sets what it is trusted to decide on its own. Connect a tool but reserve every call about it and you have a locked drawer; hand over a decision for a system the agent cannot touch and you have named a responsibility it has no way to exercise.

    Buy both in step, and reach and judgment cover the same work; buy one ahead of the other and you pay for a surface no one is cleared to use.

  • Delegation and Environment

    Delegation draws the line on what the agent decides alone; Environment is the harness that catches the call when it goes wrong. How far you can safely move that line depends on what the system behind it catches: solid gates let you delegate more, because a bad decision meets a test failure instead of a customer.

    Widen the line with no harness and every handed-over call rides on the agent being right; harden the harness but never widen the line and the safety net goes unused.

  • Capability and Environment

    Every tool you connect through Capability raises the stakes Environment has to hold. A wider reach is more the agent can break, and the harness of gates and isolation is what turns that reach into throughput instead of cleanup.

    Grow the surface faster than the guardrails and each new connection is one more unwatched way to cause damage; grow the guardrails with no new reach and you have hardened a cage around work the agent cannot do anyway.

Where Control reaches across

  • Management and Environment

    Context

    A convention starts in Management as a documented pattern the agent is meant to follow, and crosses into Environment the day you build it into a gate that will not let a change pass without it. It is one rule at two postures: written down it informs and can be ignored, enforced it stops the work until it is met.

    Leave it in the doc and you are trusting everyone to remember it on a busy afternoon; promote it to a gate with no doc behind it and you get a red build no one can explain. The rule migrates across the line as the stakes climb, so keep the convention current where it lives and enforce only the few that have earned it.

  • Delegation and Trace

    Observability

    You can only safely hand over a decision you are able to reconstruct later. Delegation is how much you let the agent settle on its own; Trace is what keeps those solo calls something you can still answer for when one goes wrong.

    Push the line out past what you can trace and every autonomous decision becomes a call with no path back to the reasoning behind it, which is exactly the call an incident or an auditor will make you explain. So the honest ceiling on how far you delegate is how deep you can reconstruct: widen the line and the record together, or the reach you handed over is reach you cannot account for.

  • Convergence and Environment

    Improvement

    The same good practice can travel two ways: Convergence makes it the easy default people opt into, and Environment makes it the gate no run is allowed to skip. Carrot and stick on one standard. Offer only the carrot and the holdouts never come; build only the stick and you enforce a habit no one was persuaded was worth it, which just teaches people to route around the gate.

    The deeper tie is that these are one risk posture expressed at two scales: the enforced check around a single agent's run and the norm you spread across the whole team are the same call about how much you are willing to trust, made once at the machine and once at the org. Set the posture first, then reach for the carrot where persuasion is enough and the stick where the stakes will not wait for it.

  • Capability and Disclosure

    Context

    What an agent can actually do in a single session is a smaller thing than everything your org made reachable: it is the tools Capability connected and the slice of context Disclosure served this run, and nothing outside that. A capable agent handed a briefing that never mentions the tool for the job will not reach for it, and perfectly aimed context is inert the moment it depends on a system Capability keeps off the table.

    Reach and briefing have to describe the same working set. Connect a tool without ever surfacing it and you have paid for an ability the agent is never told it has; serve a workflow built on access it does not have and you have written an instruction it cannot follow.

  • Environment and Evaluation

    Improvement

    A gate and an eval both stand between a change and the team's trust, and they judge by different lights. Environment is the deterministic check that blocks: the build goes red or green, and red stops the work where it stands. Evaluation is the judged measure that grades whether the change was worth making at all, a question no test suite can answer.

    The same lint and test run serves both ends: once as the gate a break cannot pass, again as the before-and-after baseline an improvement has to argue from. Ask the gate alone to speak and you ship on green, forgetting a passing build is not the same as a good outcome; keep one check binary and the other honest, and the build tells you it still works while the eval tells you it works better.

Browse the framework
You are here
Control

The agent can only do what it should.

  • CapabilityWhat the agent can do: the tools you connect, and the ones you deliberately withhold.
  • DelegationWhat the agent should do: the responsibilities you hand over, and the ones you reserve.
  • EnvironmentThe system the agent works within: the tests and gates its work must clear, and the points where a human takes over.
Read the Control domain