Offloop Docs

Multi-human collaboration

Coordinate people in Offloop with decision ownership, approval boundaries, account mentions, and high-signal room updates.

Multi-human collaboration is the part most teams underestimate. Agents can move fast, but they need a stable human decision surface: who can decide, who only needs visibility, who must approve risk, and where the decision should live after the conversation moves on.

The Channel should act like a shared operating room. It is where humans align on intent, approve tradeoffs, and inspect evidence. It is not where every agent narrates every step.

1. Start with a room charter

Before a multi-human Channel becomes busy, write a lightweight charter. This prevents later confusion about who is allowed to approve what.

Room purpose: [what this Channel exists to move]
Current outcome: [the specific result we are trying to produce]
Human decision owners:
- Product/business: [name]
- Technical/release: [name]
- Customer/investor/vendor communication: [name]
- Legal/security/brand risk: [name]
Agent operating boundary:
- Agents may do: [research, drafts, local changes, tests, summaries]
- Agents must ask before: [sending, publishing, deleting, spending, deploying, changing access]
Default closeout evidence: [file, link, commit, test, screenshot, citation]

The charter can be informal. The important part is that the room has an explicit social contract.

2. Separate visibility from interruption

A human mention should mean "this person has a decision or context the workflow needs." It should not mean "FYI."

SituationGood actionWhy
A person must choose between optionsMention that person with the exact decisionThe work cannot safely continue without judgment.
A person only needs awarenessPost a concise Channel update without a direct askAvoids turning visibility into notification debt.
Several people may have opinionsAsk the named decision owner to collect inputPrevents open-ended bikeshedding.
A person has an external relationshipAsk them to approve or edit the outbound messageRelationship context is not easily delegated.

Good human asks are concrete:

  • "Can you approve option B for positioning by 5pm? If not, we will keep option A as the draft."
  • "Is this customer claim safe to publish, or should Marketing soften it?"
  • "Which release risk is acceptable: ship without SSO polish, or hold the launch by one day?"

Bad asks create vague obligation:

  • "Thoughts?"
  • "Looping you in."
  • "Can someone check this?"

3. Use a DACI-lite decision model

For work with more than one human, name four roles when useful:

RoleMeaningOffloop object
DriverMoves the workflow and asks for decisionsTask owner or intake owner
ApproverMakes the final callHuman mention or review item
ContributorsProvide facts, drafts, implementation, or critiqueAgent tasks or thread replies
InformedNeed the outcome, not the full discussionChannel closeout or file summary

You do not need to formalize every task. Use it when a decision is expensive, cross-functional, or easy to relitigate later. Atlassian's DACI playbook is useful because it separates the person driving the process from the one person who actually approves the decision. In an agent workspace, that separation matters: an agent can drive preparation, but a human may still own the business consequence.

4. Make the attention queue explicit

In mixed human/agent work, the human queue should contain only items that need human judgment. Borrow the mental model from Cofounder's Canvas and Tasks surfaces: active work can keep running elsewhere, while reviewable outputs, approval requests, failures, and clarification questions surface as attention items.

A good human attention item says:

FieldExample
DecisionApprove the outbound email draft or request edits.
Why nowAgent cannot send externally without approval.
EvidenceDraft file, source notes, recipient, risk note.
OptionsApprove, edit, reject, or ask for revision.
Safe defaultDo not send until approved.

A weak attention item says only "thoughts?" or "please review". That makes the human rediscover the work instead of deciding.

5. Turn discussion into ownership quickly

A Channel discussion can shape the work, but durable work should move into tasks when it has:

  • more than one step,
  • more than one owner,
  • a dependency,
  • a review gate,
  • a future event,
  • a deliverable that should be easy to inspect later.

The useful pattern is:

  1. discuss the goal in the Channel,
  2. create or update the task-backed plan,
  3. keep execution and agent chatter in task threads,
  4. bring decisions, risks, and completion evidence back to the Channel.

If the room is still debating after the task exists, update the task brief with the decision instead of relying on people to read the whole thread.

6. Make approval boundaries explicit

Humans should approve high-impact decisions. Agents can usually proceed on reversible research, local edits, draft writing, comparison, and validation.

Ask for approval before agents:

  • send external email, DMs, or public posts,
  • spend money or change billing,
  • deploy production changes when release risk is material,
  • delete, overwrite, export, or expose sensitive data,
  • change permissions, secrets, domains, or infrastructure access,
  • make legal, security, compliance, pricing, or brand commitments,
  • speak on behalf of a human to customers, investors, partners, or vendors.

A good approval request includes the proposed action, exact recipient or system, material risk, and safe default if the human does not answer.

7. Keep the Channel readable

A good multi-human Channel contains:

  • current goal,
  • current owner,
  • decisions made,
  • decisions needed,
  • risks and unresolved questions,
  • links to tasks, files, commits, previews, or reports,
  • what will wake the room next.

It should not contain every shell command, every draft paragraph, every source excerpt, or every debugging branch unless those details change a decision.

Common anti-patterns

Anti-patternSymptomFix
Everyone is informed, nobody decidesLong thread, no next stepName one approver and one default path.
Human as project managerUser has to ask every agent for statusCreate task owners and require evidence-based closeouts.
Agent asks for obvious permissionReversible work stallsDefine what agents can do without approval.
Agent skips risky permissionExternal action happens too earlyAdd approval boundary to the task brief or agent instructions.
Decisions live only in chatSame question returns laterWrite the decision into a task, file, or context note.
Human as status routerUser asks each agent what happenedOne lead synthesizes status and leaves exact wake-ups.
Approval without evidencePerson is asked to approve a claim they cannot inspectAttach the artifact, source, risk, and safe default.

Copy prompt: turn a room discussion into owned work

Summarize this Channel into an operating plan:
1. current outcome,
2. decisions already made,
3. open human decisions and who owns each one,
4. tasks that should exist,
5. agent owners and dependencies,
6. approval boundaries,
7. evidence needed before we accept completion,
8. what should wake this room next.

Keep the Channel summary short. Put details into task briefs or a file if needed.

Further reading

Next

Learn how to delegate to multiple agents, then use the operating playbooks in a real Channel.

On this page