# Steer by Intent, Monitor by Exception > Source: > Published: 2026-07-17 21:35:38+00:00 The most expensive thing you can do with an AI agent is watch it. Not audit it. Not review its output. Watch it -- step by step, approval by approval, second-guessing every action before it takes the next one. And yet that is precisely how most engineering teams are deploying AI agents in 2026: on a leash so short the agent cannot take three steps without a human tapping it on the shoulder. I understand why. The models hallucinate. The stakes are real. Nobody wants to be the engineering manager who let an AI agent push a bad migration to production at 2am. So we wrap the agents in confirmation dialogs, require human sign-off at every branch point, and celebrate our careful governance. What we have actually built is an automation system that requires more human attention than the manual process it replaced. The better answer is not more control at the action level. It is better design at the intent level. Steer by intent, monitor by exception. Tell the agent clearly what outcome you need, what it must never do, and what constitutes a result worth stopping for. Then let it work. Watch the outcomes, not the steps. We have built automation systems that require more human attention than the manual process they replaced. That is not a governance success. That is a design failure. Why we got here The model for human-AI collaboration that most teams are using today was inherited from the model for junior developer supervision. You review every pull request. You approve every deployment. You sign off on every schema change. That model exists because junior developers are learning, because their mental models are incomplete, because their judgment has not yet been earned. Applied to AI agents, it assumes the same thing: the agent is a novice that needs supervision. But an AI agent is not a junior developer. It does not have an incomplete mental model of the codebase that will improve with mentorship. It has exactly the mental model you gave it via its context, its tools, and its instructions -- and it will use that model consistently and at a speed no human reviewer can match. The bottleneck in most AI-agent workflows today is not the agent. It is the queue of human approvals the agent must wait in. More importantly, action-level oversight creates a false sense of security. When you approve every individual step, you are not ensuring the outcome is correct. You are ensuring each step looked reasonable to someone who reviewed it for thirty seconds. Those are not the same thing. A sequence of individually reasonable steps can produce a collectively disastrous result, and the approval chain will have signed off on every one of them. What intent-steering actually means Steering by intent means front-loading the governance. Before the agent starts, you define three things precisely. First, the outcome: not a list of tasks, but a measurable definition of done. Not 'refactor the authentication module' but 'the authentication module passes all existing tests, introduces no new dependencies, and reduces cyclomatic complexity by at least fifteen percent.' Second, the constraints: the things the agent must never do regardless of how reasonable they seem in context. No changes to production database schemas without a migration script. No external API calls to services not already in the approved ConnectionTwin registry. No file deletions without creating a recovery snapshot first. Third, the escalation threshold: the specific conditions under which the agent stops and waits for a human. Not 'when uncertain' -- that is too vague and the agent will never stop. Specific conditions: if test coverage drops below eighty percent, stop. If a dependency with a known CVE is introduced, stop. If the refactor touches more than twelve files, stop and summarise before proceeding. Everything else is the agent's to decide. How it structures the refactor. Which functions it rewrites first. What intermediate states it moves through. You do not care about those decisions. You care about the outcome. Stop trying to approve the route and start inspecting the destination. Stop trying to approve the route. Start inspecting the destination. What exception monitoring actually means Monitoring by exception means you are not reading transcripts of what the agent did. You are watching a dashboard of outcomes against the criteria you defined upfront. Test coverage: did it hold? Security surface: did it grow? Performance benchmarks: did they move? Constraints: were any violated? If all four are green, you review the agent's summary and ship. If any are red, you get paged. Not because the agent failed -- it did exactly what you told it to do, which was to stop when these conditions were met. It stopped. Now a human makes the call. This is how every well-designed automated system in software engineering already works. CI/CD pipelines do not ask a human to approve each compilation unit. They run the full suite and alert on failure. Observability platforms do not page you for every log entry. They model baseline behavior and alert on deviation. We designed those systems with a clear principle: trust the process, intervene on exception. We need to apply the same principle to AI agents, and we have been bizarrely reluctant to do so. The reluctance comes, I think, from a category error. We are treating AI agents as autonomous decision-makers whose judgment needs checking, rather than as deterministic-enough process executors whose outcomes need verifying. Once you make that shift, the governance model changes entirely. You are not supervising a person. You are operating a system. Systems get monitored, not managed. The objection worth taking seriously The real objection to this approach is not that it is wrong in principle. It is that defining precise intent is hard. Writing a genuinely measurable outcome definition, a complete constraints list, and a well-calibrated escalation threshold takes time and expertise. It requires the engineering manager to know, before the agent starts, what success looks like and what failure looks like -- specifically enough to automate the distinction. Most teams, if they are honest, do not currently invest that effort. They compensate for vague intent with dense oversight. That compensation is rational given the current state of most AI deployment practices. But it does not scale. The value of AI agents is in parallel, sustained, autonomous execution. A team that can steer three agents simultaneously toward well-defined outcomes and monitor their convergence on a dashboard has a fundamentally different capability than a team that runs one agent at a time under close supervision. The investment in precise intent-definition is the investment that unlocks that capability. Write better briefs. Define outcomes, not tasks. Specify constraints, not steps. Calibrate escalation thresholds before you start, not after you panic. Then let the agent work, and watch what matters: whether it got there, not how it walked. The governance model we actually need The AI-agent governance conversation in 2026 is dominated by two bad options: total autonomy with no guardrails, and action-by-action human supervision that makes the agent worthless. The right model is neither. It is what every mature engineering discipline already knows: design for the outcome, constrain the boundary conditions, and monitor the result. Steer by intent. Monitor by exception. Trust the system you built, and build it well enough to trust. If your AI agent needs a human to hold its hand through every decision, the problem is not the agent. The problem is that you have not yet decided what you actually want it to do.