Chat versus delegated work
In a chat, a person typically directs each step. In delegated work, the system can take several permitted steps toward an outcome before returning for review. A fixed workflow follows predefined stages; an agent has more discretion over its next action. Anthropic's architecture guide distinguishes the two. The practical question is how much discretion the task needs and how its result will be checked.
Before approving a pilot: name the task owner, permitted actions, acceptance evidence, reviewer, spending limit, and stop conditions. Ask how failed or disputed results return to a person.
Goals make loops governable
An agent works in a loop: observe the current state, choose an action, call a tool, inspect the result, and continue. The loop should not begin until the owner has written a goal contract: the required outcome, evidence of completion, constraints, resource budget, human checkpoints, and stopping conditions.
Stop on verified success, a time/token/iteration limit, repeated lack of progress, low confidence, or a blocked or irreversible action. A loop without these conditions is uncontrolled retrying; a goal without evidence lets the agent declare victory early. Skills, goal contracts, loops, and stopping conditions are covered in the capability ladders' harness section.
Illustrative workflow · submission review
The agent loop: act, inspect, then choose the next step
Follow a fictional submission through a permitted tool call and a failed evidence check. The outcome is escalation, not an invented date.
- Brief the agentDefine the result and limits
- Call a toolRetrieve approved evidence
- Inspect the resultCompare it with the brief
- Review and routeContinue, finish, or escalate
Brief · define what counts as complete
Prepare a draft renewal brief from the approved submission files. Every reported figure needs a source and valuation date. Do not quote, bind, or contact the broker.
Set a tool-call and time budget, and name the underwriter who will review missing or conflicting evidence.
Tool call · obtain evidence
The agent asks the approved document tool for the loss run and its valuation date. The application checks that the requested files are within its permissions.
The tool returns document text and source locations. Its result becomes the evidence for the next decision.
Inspection · a returned result can still fail
- Returned file
- Loss run, source pages attached
- Valuation date
- Not stated in the supplied document
- Acceptance check
- Incomplete: date cannot be verified
A successful tool call has not completed the assignment. Check the result against the brief before choosing another action.
Route · stop at the boundary
No other approved source supplies the date. The agent returns the draft, source passages, and an explicit missing-date question to the underwriter.
The reviewer can supply further evidence or close the task as incomplete. The agent cannot fill the gap by guessing or silently expand its authority.
Return to the next tool call.
Send the artifact for review.
Return the blocker to a person.
The three shapes of agentic work
These three patterns are useful starting points for a design discussion. They can be combined; a sequential pipeline may use conventional code, model calls, or agents at different stages.
| Shape | What it is | When to consider it | Insurance example |
|---|---|---|---|
| Sequential pipeline | Stages run in fixed order with checkpoints: extract, validate, summarize, draft | Document work with known stages and acceptance checks between them | Submission intake: extraction agent, code reconciliation, appetite scoring, underwriter brief |
| Parallel fan-out | Independent units processed at the same time by identical workers, then merged | Independent units where processing time is a bottleneck and outputs can be reconciled | Forty submissions extracted concurrently; rate-filing research across ten states at once |
| Orchestrator with workers | A supervisor agent decomposes the job, dispatches workers, checks, and retries | Work where the path varies; requires explicit limits on delegation, retries, and permissions | "Benchmark our cyber exclusions against five filed competitors": one worker per competitor, orchestrator merges and flags conflicts |
Fan-out: when parallel agents pay, and when they don't
Figure
The anatomy of a fan-out
Every worker runs the same context spec on its own unit, in isolation. The merge reconciles; a named human closes the gate.
Consider parallel work when the time saved or the additional coverage justifies the coordination and review cost:
- The units are independent. For example, separate submissions or state filings can be assigned to separate workers. Measure actual throughput: provider limits, slow tasks, and the merge step can reduce the time saved.
- The queue is the bottleneck. During catastrophe response or renewal peaks, identify whether processing, data access, or human review is limiting throughput before adding workers.
- Independent checks may help. Compare separate analyses against a source or known answer. Agreement alone is insufficient: workers using the same model and documents can repeat the same error.
It fails when:
- Steps are coupled. If one step changes what another should do, sequence them or define an explicit exchange of state before continuing.
- Workers share mutable state. Assign separate files, records, or workspaces to each editor and control how changes are integrated.
- The split has no operational purpose. Giving workers different job titles does not establish independence or improve evidence. Cognition describes failures from incomplete shared context and conflicting decisions; Anthropic describes benefits for research tasks with separable directions. Test the proposed split on your own workflow.
Cost discipline: Anthropic reported that its agents used about 4× as many tokens as chat interactions, and its multi-agent systems about 15× as many as chats. Those are observations from its system, not a universal cost multiplier (Anthropic, June 2025). Compare total processing and review cost per accepted result.
Supervision rules that keep fan-out honest
- Write the goal contract first. Define required artifacts, evidence, constraints, budgets, approval points, and stopping conditions.
- One context spec for every worker. Same guidelines, same exemplars, same constraints. Divergence in output should reflect the work, not the briefing.
- Enforce permissions outside the prompt. Restrict credentials and tool access, validate fields, cap budgets, and require approval for consequential actions. Test that the application rejects unauthorized actions even when the model requests them.
- Verify at the merge. Reconcile counts, check that citations resolve, and route worker disagreements to a human instead of silently averaging them.
- Human gate on consequential outputs. Assign a reviewer for quotes, filings, and customer-facing messages, with clear authority and escalation rules. Align the workflow with the applicable requirements described in Governance.
- Keep a proportionate audit record. Record source references, model and workflow versions, actions, validation results, approvals, and overrides under approved access and retention rules.
Start with a fixed workflow or one supervised agent when it meets the task's requirements. Add parallel workers or dynamic orchestration only when evaluation shows a useful improvement after coordination, failure handling, and review costs are included.
Where to go from here
For a team rollout, use Phase 3 of the integration phases to define operating responsibilities and exit gates. Builders can continue to the harness section for context specifications and evaluation gates, or the technical deep dive for actuarial implementation and validation.