Repetition Is Not the Dividing Line

Two pieces of work landed on the same operations team last quarter. The first: read eleven carrier contracts, three years of lane history, and a pile of email threads, then explain why a customer's accessorial costs rose 22% while volume stayed flat. Ambiguous, non-repetitive, unstructured, no fixed path through it. The second: apply an approved fuel surcharge update to the invoices in a nightly batch. Four steps, same every time.

Nearly every company I talk to would hand the second one to an agent and keep the first one for a person. That instinct is backwards, and the reason it is backwards explains most of what goes wrong in agent deployments.

The analysis is safe to delegate. Its output is a document. A human reads the document, and if the reasoning is wrong the cost is a wasted afternoon. Nothing moves, nothing posts, nothing is irreversible. The invoice job is dangerous. One misread threshold applies the surcharge to the wrong customer tier, the batch runs at 2 a.m., and by morning four thousand invoices are wrong in a way that hits your customers' accounting departments before it hits yours.

Repetition is why automation is worth building. It has almost nothing to do with whether autonomy is safe.

Repetition is the wrong axis

Sorting work by "is it repetitive" produces two failures at once. Agents get pushed into narrow, repetitive, high-consequence tasks — the exact place where conventional automation was already fine and where a quiet error compounds. And agents get withheld from broad, messy, non-repetitive work — the exact place where their tolerance for ambiguity pays, and where a wrong answer is just a wrong answer.

Both vendors publishing serious guidance point the same direction. OpenAI's practical guide to building agents names three conditions worth reaching for an agent: complex decision-making, rules that have become expensive to maintain, and heavy reliance on unstructured data. Anthropic's building effective agents draws the architectural line — workflows orchestrate models and tools through predefined code paths, agents dynamically direct their own process and tool use — and then advises finding the simplest thing that works, which frequently means not building an agent at all.

Neither says "start with the repetitive stuff." The condition for using an agent is that the work resists encoding. The condition for letting it run is something else entirely, and it comes down to six questions:

• Can correctness be evaluated? Not "does it look right" — is there a check, a reconciliation, a source of truth, a second system that disagrees when the agent is wrong?
• Can harmful actions be prevented? Is the dangerous action gated by something other than the agent's own judgment about whether to take it?
• Can errors be reversed? How long is the window between a mistake and its becoming permanent, and who is standing in it?
• Can uncertainty be detected? Does the agent know when it is guessing, and does that state reach anyone?
• Can authority be bounded? Are there limits — dollars, records, recipients, tiers — that hold even when the agent is confident?
• Can exceptional cases reach a human? Is there a defined path, a named owner, and a response time — or does escalation mean a message in a channel nobody reads on Friday?

The deployment equation looks roughly like this:

Autonomy = capability × observability × recoverability × bounded authority

It is a product, not a sum. A zero anywhere sets the whole thing to zero. A highly capable agent with no observability is not a fast operation, it is an unaudited one. Risk alone does not determine autonomy either — high-stakes work with strong verification and easy reversal can be delegated further than low-stakes work that silently writes to a system of record.

The ladder most deployments are actually climbing

Companies do not go from nothing to autonomous operations. They climb, and the rungs are more distinct than the marketing suggests.

First: flexible automation

This is where nearly all production deployment starts. Read documents and extract fields. Research and compile a report. Reconcile records across two systems that disagree. Draft communications. Classify and route exceptions. Update systems under deterministic rules. Complete a browser workflow in an application with no usable API.

The agent absorbs the variability that made ordinary automation brittle — the vendor whose invoice layout changed, the portal that times out, the document that arrives as a photograph of a fax. It interprets, retries, and picks among tools.

But the organization still defines the workflow. This is automation that can reason locally. It is worth real money and it changes nothing structural about the company.

Second: bounded operators

The next rung is not unlimited autonomy. It is delegated authority inside an operational envelope.

A freight agent at this stage might be permitted to request missing documents, recalculate an ETA, notify an approved list of recipients, reschedule a non-critical appointment inside permitted windows, and propose a driver reassignment — but execute that reassignment only below a defined cost and service-risk threshold. Above the threshold it proposes and waits.

The agent is not following one rigid path. It is pursuing an outcome inside permitted actions, spending limits, policy constraints, confidence thresholds, escalation conditions, and audit requirements. Which is, almost exactly, how you delegate to a capable new hire: a goal, some tools, limited authority, and clear instructions about when to come find you.

Notice what the enterprise platforms have been building toward. Not smarter chat windows — shared organizational context, permissions, boundaries, memory, feedback, and execution environments. The industry has quietly conceded that the hard part is the envelope, not the reasoning.

Third: exception absorbers

Operational work is not evenly difficult. There is usually a large center of routine and moderately variable cases, a smaller band of genuine exceptions, and a thin edge that requires senior judgment.

An agent does not need to replicate your best dispatcher. It needs to keep expanding the share it can handle safely. Thirty percent, then sixty, then ninety — while humans concentrate on the novel, the consequential, and the politically delicate.

This is what resolves the chicken-and-egg problem of knowledge capture. You do not spend two years interviewing employees to document intuition before the agent can start. The agent works first, imperfectly. Humans correct it at the boundary. The corrections are the curriculum. Over time the system learns where its authority should expand and where it should stay fenced.

The valuable asset that accumulates is not the agent. It is the boundary — the tested, documented, continuously moving line between automated execution and human escalation. That boundary is the thing competitors cannot copy, because it was earned one correction at a time. We built knowledge capture around exactly this: the moment of override, escalation, or exception is where the reasoning is still recoverable, and it is the only moment when asking costs almost nothing.

Fourth: decision infrastructure

Further up, the agent stops completing discrete tasks. It holds standing responsibility: observing operating conditions, detecting emerging problems, gathering context, simulating options, estimating consequences, executing permitted responses, routing meaningful exceptions, recording why a decision changed, and evaluating what happened.

Compare two instructions.

"Send this email."

"Keep this customer's loads moving within service expectations, hold avoidable accessorial costs down, and involve me when the trade-off exceeds our approved thresholds."

The first is a task. The second is a delegated objective with an accountability clause attached. Everything difficult about agent deployment lives in the gap between them — and none of it is model capability.

Fifth: the organization becomes a learning system

The largest change is not the autonomous agent. It is a company that learns from every execution cycle.

Today most companies make thousands of decisions a week and accumulate almost no understanding from them. Someone solves a problem in a message thread. A manager approves an exception without recording why. The customer reacts. The outcome happens. The reasoning evaporates, and six months later a different person solves the same problem from scratch, slightly worse.

An agentic operating layer can hold the whole chain: context, recommendation, human correction, action, outcome. That produces institutional memory without asking anyone to document their thinking, which is fortunate, because nobody has ever sustainably done that.

Microsoft's 2026 Work Trend Index — 20,000 knowledge workers across ten markets — frames the same division: as agents take on more execution, the human contribution shifts toward directing work, setting standards, and owning outcomes. It also reports that 86% of AI users treat model output as a starting point rather than a final answer, and that only 19% of respondents land in what Microsoft calls the frontier zone on capability and organizational readiness together. The capability is arriving faster than the readiness to use it. That gap is the whole opportunity.

Judgment is not one thing

The debate usually poses a clean split: agents do execution, humans do judgment. That framing survives about ten minutes of contact with real work, because judgment is not one faculty. It is at least six, and they automate at wildly different rates.

1. Pattern recognition. "This looks like three situations we've seen before."
2. Prediction. "This customer will reject that outcome."
3. Preference weighting. "Service reliability matters more than margin on this account."
4. Policy interpretation. "The rule technically permits it, but that isn't what it's for."
5. Social awareness. "Escalating this today damages a relationship we need in March."
6. Accountability. "Someone has to personally own this decision."

Pattern recognition and prediction are already substantially automatable — they are the parts that improve with data, and the parts humans are measurably mediocre at. Preference weighting can be encoded or learned from a corpus of past decisions, provided someone recorded the trade-offs. Policy interpretation can be partly delegated with the interpretation itself written down and reviewed. Social awareness and accountability stay human for a long time, and accountability may stay human permanently — not because the analysis is worse, but because responsibility is a thing only a person can hold.

So the frontier is not a line between execution and judgment. Judgment gets decomposed, and its components migrate at different speeds. That is a more useful map, because it tells you what to build next: capture the reasoning behind preference weighting, keep accountability explicitly assigned, and stop pretending the two are the same problem. I wrote about the underlying shift — from issuing instructions to issuing judgments — in The End of Instructions.

"Human in the loop" is a stage, not a destination

Human-in-the-loop gets treated as the permanent safe answer. Agent proposes, human approves, everyone sleeps.

It is the right control early. It becomes theater when a reviewer approves 99% of recommendations without changing them. At that point the gate is not measuring anything — it is a tax that trains people to click through, which is worse than no gate at all, because now the approval has a name attached to it and no attention behind it.

The mature progression runs through six stages:

• Observe. The agent watches humans do the work and builds context. It executes nothing.
• Recommend. It proposes actions with reasoning. Humans act.
• Approve. It executes only after explicit authorization.
• Supervise. It executes routine cases and reports what it did.
• Audit. It executes independently; humans sample results and investigate anomalies.
• Govern. Humans set objectives, authority, constraints, evaluation standards, and accountability.

Microsoft's research describes four collaboration patterns — author, editor, director, orchestrator — that map onto the same arc from doing the work yourself to designing a system that flags exceptions to you.

The thing to insist on: movement between stages is earned with evidence. A measured error rate, on your data, against a defined standard, over enough volume to mean something. Not a vendor's roadmap, not a demo, not a quarter-end deadline. If you cannot state what performance would justify the next rung, you are not running a promotion process, you are guessing. That is the substance of human-in-the-loop design — and it is a design problem, not a checkbox.

The hard part was never the reasoning

Current systems already perform multi-step reasoning, use tools, operate software, work across files, and pursue longer assignments. What remains genuinely hard is durability: holding context, memory, coordination, and consistency together across long-running work. Anthropic's own context engineering guidance treats this as active engineering rather than a solved problem — compaction, structured note-taking, sub-agents — because context windows get exhausted and deciding what to discard is a bet on what future turns will need.

But in most deployments I've seen, the model is not the constraint. The constraints are organizational:

• data fragmented across systems that disagree about the same customer
• processes that exist in three incompatible versions depending on who you ask
• policies that contradict each other and are reconciled informally by whoever has been there longest
• permissions nobody will grant because no one can articulate the blast radius
• no working definition of a good outcome for the task
• no feedback signal that survives contact with a busy week
• exceptions handled entirely in message threads and never written down
• nobody willing to own what the agent does

An agent walks into that and exposes it immediately. Not because it is fragile, but because it needs the operating model stated, and most companies never stated theirs. They relied on experienced people to compensate for systems that did not quite work — an arrangement that functioned right up until the compensating people started retiring. This is the same pattern behind the chatbox in the corner: the interface was never the problem.

"We deploy agents" will sound like "we use APIs"

The phrase is on a well-worn path. Build a website. Move to the cloud. Ship a mobile app. Implement a CRM. Each looked like a differentiator while the infrastructure was new, and each became a line item once it was standard.

Model access, agent SDKs, connectors, computer use, memory, and orchestration are consolidating into platform features right now. Within a couple of years, "we deploy agents" will carry about as much weight as "we use APIs."

What does not commoditize is the work around the agent: deciding which processes deserve redesign rather than automation, building the operational context layer, defining authority and escalation boundaries, instrumenting outcomes so performance is measurable, designing the evaluation system, connecting agent actions to actual business economics, converting exceptions into organizational learning, and owning the operational improvement that results. That is governance in the practical sense — not a policy document, but the machinery that makes autonomy defensible.

What this looks like in the first ninety days

Concretely, for an operations-heavy company starting now:

Pick one decision, not one department. Something recurring, where experience clearly affects cost, speed, risk, or a customer outcome, and where you can name the person who currently makes the call. Breadth is the enemy at this stage.

Answer the six questions before writing code. If you cannot describe how you would detect a wrong answer, you are not ready to let anything execute. That is not a reason to stop — it is the first thing to build.

Run it in observe and recommend for real volume. Not a pilot with ten curated cases. Real work, real mess, side by side with the person doing it, long enough to produce an honest error rate.

Write down the envelope explicitly. Permitted actions, dollar limits, record counts, approved recipients, confidence thresholds, escalation triggers, and what gets logged. If it lives in someone's head, it is not a boundary.

Instrument the corrections. Every override is a data point about where the boundary belongs. Captured at the moment of the override, with the reasoning attached, it is worth more than any documentation project you could fund.

Promote on evidence. Move from recommend to approve to supervise when the numbers justify it, and be willing to demote a capability that starts drifting. Autonomy should be revocable, and everyone involved should know that.

Ninety days of that produces something more useful than an agent: a tested boundary, a measured error rate, and an organization that knows what it means by a good outcome. The agent is the easy part to replace afterward.

Where this ends up

The final frontier is not an agent that independently performs every task. It is an organization that can translate intent into coordinated execution, learn continuously from outcomes, and reserve human attention for the decisions where human responsibility actually creates value.

The mature version of this probably has very few things labeled "agent products." Agents get embedded in the operating fabric — moving information, investigating conditions, coordinating systems, executing permitted actions, escalating meaningful uncertainty. Humans supply objectives, taste, priorities, values, accountability, novel interpretation, social judgment, and the willingness to redefine the system itself. Agents supply attention at scale, memory, search, simulation, monitoring, coordination, execution, consistency, and fast learning from structured feedback.

The migration is continuous. Agents absorb whatever can be sufficiently understood, evaluated, bounded, and governed. Humans move toward deciding what the organization should optimize for, when its rules should change, and which consequences it is prepared to own.

That is a strategy question wearing a technology costume. The companies that answer it deliberately will spend the next five years compounding. The ones that sort their work by "is it repetitive" will deploy agents into the four thousand invoices and find out the expensive way.

---

If you are trying to decide which work belongs on the ladder and where the boundary should sit, that is the conversation we have with clients before anything gets built — see how we deploy operational AI, or start with an operational assessment that names the first decision worth delegating and what would have to be true to let an agent execute it.