Chat versus delegated work
In a chat, you are in the loop of every step: you ask, it answers, you steer. In an agentic workflow you delegate the whole job and review the output. That shift, from conversation to delegation, is what "agentic" means in practice. It changes both the payoff (work happens unattended, at any hour, at fleet scale) and the risk (errors compound across steps you did not watch). Managing that tradeoff is the core skill of agentic work.
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 practice ladder's harness section.
The loop, and the two things that make it governable
The cycle in the middle is what an agent does. The contract on the left and the exits below are what turn it from uncontrolled retrying into delegated work you can sign off.
The three shapes of agentic work
Nearly every agentic workflow in production is one of these shapes, or a combination of them. Learn to name the shape before you build or buy anything.
| Shape | What it is | When it wins | Insurance example |
|---|---|---|---|
| Sequential pipeline | Stages run in fixed order with checkpoints: extract, validate, summarize, draft | The default for document work; errors surface at the stage that caused 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 | Units do not depend on each other; volume or latency is the bottleneck; redundancy can buy quality | 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 | Longer-horizon work where the path varies and steps branch; highest oversight burden | "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
Fan-out is the highest-leverage agentic pattern and the most misused. Telling agents to work in parallel pays when:
- The units are independent. Forty submissions, ten state filings, three candidate wordings. If each unit stands alone, ten workers finish in the time of one, and a human reviews the merged queue instead of running forty chats.
- The queue is the bottleneck. CAT-event claim notices, renewal-season bordereaux: throughput is the win, and identical workers beat a heroic individual.
- Redundancy buys quality. Ask for three independent answers to a hard question, then a fourth pass that compares them and explains the disagreements. Cheap, and measurably better than one confident pass.
It fails when:
- Steps are coupled. If step two changes what step three should do, parallel workers diverge and the merge is mush.
- Workers share mutable state. Several agents editing one document or one shared context produce collisions, not collaboration.
- You wanted personas. Parallel agents pay because each gets isolated context, not because one of them plays "the skeptic." Role-playing subagents measurably underperform; quarantined context is the entire point (see Cognition and Anthropic's multi-agent research write-up).
Cost discipline: fan-out multiplies token spend roughly linearly, and orchestrated teams have been reported at around 15x the token cost of a single agent. Spend parallelism where volume or quality justifies it, and measure the merge quality, not just the speed.
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.
- Limits in code, not prompts. Authority caps, PII blocks, field validators, and loop budgets enforced by hooks. Instructions inform; hooks enforce.
- 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. Quotes, filings, and customer-facing messages get a named reviewer. The NAIC bulletin expects documented human oversight exactly here (see Governance).
- Log everything. Inputs, outputs, hook firings, overrides. Fan-out without logs is unaccountable slop at scale.
Use the simplest shape that closes the quality gap: a pipeline beats a fan-out, a fan-out beats an orchestrator, and one governed agent beats a fleet. Autonomy is a cost you spend, not a badge you earn. Most production wins in insurance so far come from boring pipelines and one well-supervised fan-out, not from agent societies.
Where to go from here
The practice ladder carries both next steps: levels 5 and 6 are the personal-practice version (agent boss, fleet orchestrator), and its harness section is the build manual (context specs, hooks, golden datasets, eval gates). The integration phases's Phase 3 is the organizational version. The governance section covers the expectations that apply to all of it.