Offloop Docs

Copy-ready playbooks for routing mixed human and agent work through intake, delegation, review, approval, and follow-up.

Use these playbooks when a Channel starts getting crowded, when several agents could help, or when a human decision is slowing the work down.

The pattern is intentionally boring: define the outcome, choose an owner, split only where the contract changes, ask humans only for judgment, require evidence, and leave a wake-up if the work is not finished now.

Playbook 1: route a new request

Use this when someone drops a broad request into a Channel.

Intake decision:
Outcome: [what the user wants to be true]
Type: direct answer / small local task / task-backed workflow / external follow-up / risky side effect
Primary owner: [human or agent]
Smallest useful team: [roles only]
Human decision needed now: yes/no — [decision]
First action: [next reversible step]
Closeout evidence: [file/link/commit/citation/test/screenshot]
Wake-up if waiting: [task event/signal/schedule/listener/none]

Routing rules

If the request needs...	Prefer...	Why
One synthesized answer	Manager-led workflow	One owner keeps the answer coherent.
A specialist to take over	Handoff workflow	Ownership is clearer than hidden helper calls.
Independent expert inputs	Parallel exploration	Speed matters and scopes do not overlap.
Challenge before commitment	Peer collaboration	Diverse critique improves decisions.
Repeatable steps	Code-orchestrated chain	Deterministic flow is easier to test.
Human risk judgment	Human-in-the-loop approval	The person owns the consequence, not the busywork.

Do not choose the team first. Choose the operating pattern first, then pick only the roles the pattern requires.

Playbook 2: make a multi-agent task graph

Use this for product specs, code changes, research reports, launch plans, fundraising packs, customer follow-ups, design systems, and other work that has dependencies.

Task graph:
1. [Task A] — owner: [agent/human], output: [artifact], evidence: [proof]
2. [Task B] — depends on: [A], owner: [agent/human], output: [artifact], evidence: [proof]
3. [Review] — depends on: [B], reviewer: [role], acceptance criteria: [criteria]
4. [Approval] — approver: [human], required before: [external side effect]
5. [Closeout] — owner: [lead], report: [what the Channel should see]

Default graph by work type

Work type	Useful graph
Research memo	Researcher → fact-checker → synthesizer → human decision if strategy changes.
Product spec	Product lead → design/engineering reviewers → revision → approver.
Code change	Engineer → code review → QA → release owner → human approval if production risk is material.
Marketing page	Strategy/positioning → design/frontend → fact-check → QA → publish approval.
External email	Research/draft → human edit/approval → send → email reply signal.
Security-sensitive work	Engineer → security reviewer → human approver → audited closeout.

A task graph should be small enough to inspect. If every task depends on every other task, the graph is not ready; split the goal or appoint one stronger lead.

Playbook 3: use humans as decision bottlenecks, not project managers

A strong agent team lets humans clear high-value decisions quickly. It should not ask humans to coordinate routine execution.

Ask a human when the workflow needs one of these:

taste, priority, strategy, pricing, brand, relationship, legal, security, or risk judgment,
approval for sending, publishing, deploying, deleting, spending, exporting, or changing access,
a missing fact only that human knows and cannot be retrieved safely,
acceptance of a reviewable artifact where being wrong is costly.

Do not ask a human when the next step is reversible and implied:

searching, reading docs, comparing options,
drafting before sending,
editing local files,
running tests or builds,
summarizing a thread,
creating task structure,
checking status before setting a wake-up.

Good approval request

Approval needed: send this investor follow-up.
Recipient: [name/email]
Draft: [file or quoted short draft]
Reason for approval: this represents the founder externally.
Risk: tone and factual claims.
Safe default if no answer: do not send; keep draft in task.

Weak approval request

Should I continue?

If the answer is obviously yes and the action is reversible, continue. If the answer changes risk or external consequences, ask with specifics.

Playbook 4: run a review loop

A review is not a second implementation track. It is a challenge step with evidence.

Review request:
Artifact: [file/link/commit/preview]
Scope: [what to inspect]
Acceptance criteria: [what must be true]
Out of scope: [what not to relitigate]
Known caveats: [limits]
Please return: accepted / accepted with caveats / revision needed / cannot review because [missing evidence]

Reviewer scopes

Reviewer	Inspect	Avoid
Code review	Correctness, regressions, unsafe patterns, missing tests	Rewriting product scope.
QA	User path, visual issues, mobile, broken links, commands	Debating strategy unless it blocks use.
Fact-check	Unsupported claims, stale sources, citation quality	Voice rewrites unless asked.
Design review	Hierarchy, accessibility, responsiveness, consistency	Restarting brand direction by default.
Security review	Secrets, permissions, sensitive data, risky deploys	Approving business risk alone.

A review loop should have a maximum number of revision rounds or a named human decision point. Infinite agent critique is just hidden delay.

Playbook 5: leave a durable wake-up

Any promise to follow up needs a mechanism.

Waiting for	Use
Another agent in the same room	Agent listener or explicit handoff.
A task status, report, comment, or run result	Task signal subscription.
Email reply	Email signal with sender/thread/context filters.
GitHub PR, CI, issue, or deployment	GitHub signal or task event.
Webhook/product feedback	Webhook signal.
A future time	Calendar schedule.
Human approval	Clear Channel ask or task review item.

If the event might happen hours or days later, make it resumable. OpenAI's HITL flow serializes run state around approvals; Google describes human intervention paths in agentic flows; Offloop's equivalent is a task, signal, schedule, or listener that brings the room back without relying on memory.

Playbook 6: close a workflow

Closeout should be short enough for the Channel and complete enough for a future reader.

Completed: [deliverable]
Owner: [who owned final synthesis]
Evidence: [file/link/commit/citations/screenshots]
Validation: [checks or review results]
Human decisions made: [decision + approver]
Not verified: [honest caveats]
Next state: done / waiting on [event] / revision assigned to [owner]
Wake-up: [none/signal/schedule/task/listener]

Do not close a workflow if a requested review, publish step, approval, or external follow-up is still implied. Either complete it, assign it, or leave the wake-up.

Copy prompt: run the whole operating model

Run this as an Agent Team 101 workflow.

Goal: [outcome]
Context: [links/files/channel/task]
Constraints: [time, quality, source, tool, approval, risk]

Please:
1. choose the operating pattern before choosing agents,
2. name one primary owner per task,
3. build the smallest useful dependency graph,
4. define human approval boundaries,
5. require evidence and validation from each owner,
6. keep detailed execution out of the main Channel,
7. return only decisions, risks, artifacts, and closeout to the Channel,
8. leave a signal, schedule, task subscription, or listener if anything waits.

Operating playbooks