Offloop Docs

Choose the right multi-agent topology, assign one owner per task, require evidence, and prevent bot pileups.

Multi-agent work should feel like a coordinated team, not several assistants racing to answer the same prompt.

The most important design choice is ownership: who owns the final answer or deliverable for this branch of work? Once ownership is clear, routing becomes much easier.

1. Choose the topology before choosing agents

Topology	Use when	Example	Main risk
Manager-led workflow	One lead should synthesize the final answer and call specialists for bounded inputs	Launch Lead calls Research, Design, and QA	Lead becomes bottleneck if every detail returns to the room.
Handoff workflow	A specialist should own the next response, task, or deliverable	Intake owner hands bug fix to Engineer	Context loss if the handoff is vague.
Peer collaboration	Several roles should challenge or explore before synthesis	Product, Security, and Finance evaluate pricing change	Too much debate without a closeout owner.
Code-orchestrated chain	Steps are deterministic and repeatable	Research → outline → draft → critique → revision	Rigid flow when judgment should adapt.
Parallel exploration	Outputs are independent and speed matters	Three agents research different market segments	Duplicate work if scopes overlap.
Evaluator loop	One output should be improved against clear criteria	Writer drafts; reviewer flags gaps; writer revises	Infinite critique if there is no stopping rule.

OpenAI's Agents guidance frames the first major choice as handoffs versus agents-as-tools: does control move to a specialist, or does a manager keep ownership and call specialists as bounded capabilities? AWS frames a related distinction as workflow agents versus multi-agent collaboration. Google adds a useful evaluator pattern: a quality agent reviews an output and triggers refinement until criteria are met. In Offloop terms: choose whether the lead stays accountable, ownership transfers, peers deliberate, or an evaluator loop raises quality.

2. Pick the smallest useful team

Do not wake every agent by default. Choose agents because their role changes quality, speed, or safety.

Common patterns:

Goal	Useful agent team	Why
Research brief	Research owner + fact-check/review	One finds; one challenges evidence.
Product spec	Product lead + design/engineering reviewer	Spec needs user value plus feasibility.
Code change	Implementation owner + code review + QA	Build, inspect, validate are different jobs.
Website/page	Design/frontend owner + QA/review	Visual quality and implementation both matter.
External follow-up	Drafting owner + human approver + email signal	Agent drafts; human owns relationship; signal handles future reply.
Security-sensitive change	Engineer + security reviewer + human approver	Risk boundary needs independent review.

A useful rule: add a specialist only when the contract changes — different tools, different expertise, different policy, independent review, or a different decision right. If the only difference is "more opinions," keep one owner and ask for a targeted review instead.

3. Write an agent contract before you wake the agent

Every delegated agent should receive a contract, not just a mention. The contract can be short, but it should include:

Field	Purpose
Goal	The outcome the agent owns.
Scope	What is included and excluded.
Inputs	Files, tasks, links, prior decisions, source requirements.
Output	The exact artifact or answer expected.
Evidence	Tests, citations, screenshots, commits, logs, or reasoning trace.
Approval boundary	What the agent must not do without human permission.
Return path	Where to report completion, revision needs, or waiting state.

Agent contract:
Owner: [agent]
Goal: [outcome]
Inputs: [links/files/context]
Output: [artifact]
Evidence: [required proof]
Do not: [approval boundaries]
Return with: [accepted output / issues / next wake-up]

This prevents the most common failure: an agent optimizes for a plausible subtask while the room needed a different deliverable.

4. One task, one primary owner

Even when several agents contribute, each task needs one primary owner. The owner is responsible for:

moving the task forward,
asking for missing context,
deciding whether specialist help is needed,
collecting evidence,
reporting completion or uncertainty,
leaving the next wake-up.

A reviewer can challenge the work, but should not silently become a second owner unless the task is reassigned.

5. Use dependency graphs instead of parallel chaos

Multi-agent workflows usually need a small dependency graph:

research or product framing,
design or implementation plan,
implementation,
review,
QA or validation,
release or closeout.

Parallelize only when outputs are genuinely independent. If one agent needs another agent's answer first, make that dependency explicit instead of hoping they notice each other in chat.

Bad delegation:

Everyone look at this and make it better.

Better delegation:

Run this as a dependency graph:
1. Research owns source-backed market findings.
2. Product depends on Research and writes the decision memo.
3. Design depends on Product and proposes the landing page structure.
4. QA reviews the final page for broken links, mobile readability, and unsupported claims.
5. Human approval is required before publishing.

6. Require evidence in every handoff

A useful agent handoff includes:

goal understood,
what was done,
where to inspect it,
validation performed,
unresolved risks or assumptions,
what the next owner should do,
whether human approval is needed,
what wake-up remains if the work cannot finish now.

Bad handoff:

Done, please check.

Good handoff:

Implemented the docs navigation and four Agent Team 101 pages.
Evidence:
- commit: abc123
- files: docs-site/content/docs/agent-team-101/*.mdx
- validation: pnpm --dir docs-site lint and build passed
Remaining risk: did not visually inspect the deployed preview.
Next: QA should check navigation, mobile readability, and llms.txt output.
Human approval: needed before publishing release notes.
Wake-up: none if QA passes; otherwise task returns to Engineer.

7. Add a reviewer, not a rival owner

Review agents are most useful when their mandate is narrow:

Reviewer type	What to inspect	What not to do
Code review	Bugs, regressions, missing tests, unsafe patterns	Rewrite the whole feature without assignment.
QA	User flow, commands, screenshots, broken links	Debate product strategy unless it blocks validation.
Fact-check	Unsupported claims, stale facts, citation quality	Rewrite voice and positioning unless asked.
Design review	Hierarchy, accessibility, consistency, responsiveness	Reopen the whole brand direction by default.
Security review	Secrets, permissions, data exposure, unsafe deploys	Approve business risk alone.

A review should end in one of four states: accepted, accepted with caveats, revision needed with specific findings, or cannot review because evidence is missing. If revision is needed, the lead should immediately route it back to the owner or update the task dependency; do not let the finding become a loose chat comment.

8. Avoid delegation failure modes

Failure mode	What it looks like	Fix
Bot pileup	Several agents answer the same broad prompt.	Pick one owner and assign bounded helper roles.
Hidden helper work	A lead says "done" but no one can inspect inputs.	Require evidence and source links in the handoff.
Premature split	Five agents exist where one prompt would work.	Add specialists only when tools, policy, expertise, or review differs.
Orphaned review	Reviewer finds issues but no owner is woken.	Route revision immediately and preserve dependency state.
Infinite evaluator loop	Reviewer keeps asking for polish without a stop.	Define acceptance criteria and max rounds.
Human coordination tax	User has to ask every agent what happened.	The lead synthesizes status and leaves wake-ups.

9. Close the loop

A workflow is not complete just because one agent produced output. Closeout should answer:

Did the requested deliverable ship?
Did review or QA accept it?
What was verified?
What could not be verified?
Is the next wake-up a task event, external signal, schedule, agent listener, or nothing?

If the next step is known and safe, the lead should start or wake it. Do not wait for the human to say "continue" when the workflow already defines the next owner.

Copy prompt: delegate without bot pileup

Run this with the smallest useful agent team.

Goal: [outcome]
Constraints: [time, quality, sources, tools, approval limits]
Deliverable: [what should exist at the end]

Please propose:
- the right topology: manager-led, handoff, peer collaboration, evaluator loop, chain, or parallel exploration,
- one primary owner per task,
- dependencies,
- evidence required from each owner,
- reviewer/QA points,
- human approval points,
- what should happen first,
- what signal/schedule/listener should remain if anything waits.

Multi-agent delegation