If workflows are about automating the toil done by people, then delegating to an agent is extracting a tedious slice of a job and handing it to a step in a workflow. Whether that workflow is a business process or a pipeline is a detail. It is reassuring, because it means the discipline is not new. Versioned inputs, an executable definition of good, evidence produced by default, repeatable results: the things a pipeline needs before anyone trusts it are exactly the things a fleet of agents needs. Most organisations have not finished building that for the humans. Finishing it now pays twice.
AI amplifies the architecture it finds, and each of the questions below is amplification surface. A strong answer gets faster. A weak one gets faster too, and this time in more copies than you can review. The loop on this site - design the boundary, agree the contract, deliver it, prove it continuously - was written for teams of people. Read it again as a pre-flight for delegation and it holds, because it was never really about people. It was about what has to be written down before work can move between parties without a conversation. An agent is the party that cannot have the conversation.
The structure: can the work find its edges?
Is the boundary discoverable? If a new engineer has to infer the design from the code, so does the model, and it will infer a different one on every invocation. A human infers once and then asks around; an agent has no one to ask and fills the gap with the median. The fix is the same one that makes a service built to be consumed: a boundary that says what it owns, what it exposes and what it may not do, in a place the next reader will look. If the boundary lives in a senior engineer's head, the cost is not that the agent gets it wrong. It is that it gets it wrong plausibly, in the same confident tone it uses when it is right.
Is the seam agreed, or assumed? Every boundary between two teams is a contract, whether anyone wrote it down or not. An assumed seam is negotiated by people who can push back, reinterpret or ignore it; an agent does none of that and guesses afresh each time. Agreed and versioned, the seam becomes something a gate can fail on and something an agent can be scoped to - a MicroContext that holds one slice of the organisation and does one useful thing inside it. The test is simple. Point at the seam and ask where its current version lives. "In the wiki" and "in the code" are both wrong answers, for different reasons.
The feedback: does the system say no?
Does the pipeline fail? Honestly? Lint, tests, contract checks and scans, with no human deciding whether to care. Turning intent into code that compiles is solved because code is checkable - the compiler, the types and the tests tell the model when it is wrong and it iterates against that. Strip the checks out, or leave them advisory, and you have removed the only thing that made the delegation safe. A pipeline a human can talk past is a pipeline an agent will talk past, and the agent will not know it did.
Are "good" and "bad" written down and executable? This is the question the other six depend on. If the definition of good lives in a reviewer's head, it cannot be delegated to anything - agent or graduate. It cannot even be reviewed consistently, because the reviewer is checking against something that moves with their week. The spec harness I have written about before took 15 days, and most of them went on fixtures, a written definition of good and bad, and a way to fail that was not a vibe. The harness code was the cheap part. The definition is the asset, and it is the part organisations skip because it looks like documentation rather than automation.
The runtime: can you see what it costs?
Is spend observable where everything else is? A microservice estate has a top end you can point at: cap the replicas, set the autoscaler ceiling, size the quota, walk away. An agent that re-plans, retries and calls itself has no replica count to cap, and an unbounded loop is a spending event that can clear a monthly budget before anything you configured has noticed. A token budget on the trace, a depth limit, a timeout, and a breaker that trips on spend rather than on errors. Cost that only surfaces on an invoice is not instrumented. If you could not see your services before, you will not see your agents now, and this time not seeing them has a price per token.
Is the agent's context versioned? Prompts, rules, skills and harnesses are build inputs now. An untracked build input is how you get an unreproducible build, and an unreproducible build is how you get an incident no one can explain. Treat them the way you treat the rest of the System Version: versioned, reviewed, promoted with the artefact they shaped. A change to a prompt is a change. Either it sits inside your change control or you have found a hole in it exactly the shape of the most consequential edits anyone will make.
The owner: who is holding this?
Who owns the mess if this goes wrong? If the answer is "the engineers, later", you have not delegated the work. You have deferred it, with interest, against people who were never asked. Responsibility delegates; accountability does not. A named owner is what turns a gate from something that happened to get built into something that is still there when its author has moved on, and it is the question most rollouts leave until the incident review answers it for them. Put the name on it before the agent runs. Which capability this fulfils, and how the function has to operate - somebody has to be able to answer that in a sentence, and it is not the agent.
Score it, then sequence it
Seven questions, seven answers, and the honest score for most estates is well short of seven. That is not a reason to wait. It is the order of work. Everything a "no" points at is something you needed anyway, and the organisation needed it before the agents arrived. Fix the definition of good first, because the other six are measured against it. Then the seam, because that is what scopes the agent. Then the pipeline, the spend, the context and the owner, in whichever order your next incident would have chosen for you.
Delegate the contexts where all seven hold. Keep the rest, for now, and say why. The list of what you kept is a backlog, not a failure - and it is a backlog written in the units an agent can eventually pick up: a context, a capability, a constraint, an owner.
Delegation is a claim that the answer is already written down. Where it is, agents accelerate and the acceleration is observable. Where it is not, the work has not moved. Only the date has.
Answer the seven before the agents answer them for you.
References & further reading
- Building Effective Agents - Anthropic (2024)
- Eliminating Toil - Site Reliability Engineering, Beyer, Jones, Petoff & Murphy (2016)
- Continuous Delivery - Humble & Farley (2010)
- Accelerate - Forsgren, Humble & Kim (2018)