Web4Guru AI Operations
Docs · Core Concepts · Delegation

Delegation

Delegation is what the CEO spends most of its time on — picking a specialist, passing a brief, and synthesising the result. If Black Box feels like a team, it is because the CEO really does hand work off.

TL;DR

To delegate, the CEO: (1) decides which specialist fits the sub-task, (2) writes a scoped brief with only the relevant context, (3) opens a per-task sub-session with a tight tool belt, (4) waits for results, (5) sends the deliverable through the Evaluator, (6) synthesises a short report for you. Parallel delegation fans out independent sub-tasks.

Why delegation matters

You could shove everything into one giant prompt, but single agents degrade fast. Context bloats, attention drifts, the model forgets what tools it has. Delegation keeps each specialist on a short leash: small prompt, small cwd, small tool belt, small job. That is how you get consistent quality on the hundredth landing page, not just the first.

The CEO's decision procedure

  1. Decompose. Break the owner's goal into sub-tasks. "Ship a landing page" becomes: research the market, draft the copy, design the layout, write the code, deploy it, and announce it.
  2. Match. For each sub-task, pick the specialist whose role fits best. Ambiguous sub-tasks default to the generalist (Content for most writing; Business Ops for most logistics).
  3. Shape. Decide: run serially (one after another, each depending on the last) or spawn in parallel (independent sub-tasks that can race).
  4. Brief. Write a short instruction that includes the goal, the context the specialist actually needs (from company memory), and any prior specialist outputs that feed this step.
  5. Call. Invoke the matching tool: delegate_to_coding, delegate_to_content, delegate_to_research, delegate_to_browser, delegate_to_business_ops, or spawn_parallel_specialists for a fan-out.

What goes into a brief

The CEO does not dump its whole context window on a specialist. That would be wasteful and leak private information across roles. A brief contains exactly what the specialist needs:

  • The specific sub-task, as a sentence or two.
  • Relevant facts from company memory — the owner's brand voice for a Content Specialist, the repo URL for a Coding Specialist, the ICP profile for a Sales Specialist.
  • Any prior specialist output that this step depends on (the research summary the Content Specialist needs, the draft the Browser Specialist needs to publish).
  • A deadline or credit budget if the CEO has decided to bound this one.

Parallel delegation

When sub-tasks are genuinely independent, the CEO spawns them in parallel. Each parallel branch runs in its own sub-session, in its own cwd, with its own credits counter. Branches do not see each other; they only see the CEO's join when they return.

The obvious win: a "launch my landing page" job that would take ten minutes serially takes ninety seconds with three specialists running at once. The less obvious win: parallel branches give the Evaluator independent samples to compare against each other. If two drafts agree and one disagrees, the CEO knows which one to probe.

Results and re-delegation

When a specialist returns, the CEO does not immediately accept the work. Every deliverable passes through the Evaluator gate first. If the Evaluator rejects it with a critique, the CEO can: re-delegate to the same specialist with the critique as new context, re-delegate to a different specialist entirely, or surface an approval card to the owner if the issue is outside the CEO's scope.

Accepted work gets synthesised into a short report — the report_ready card you see in the Action Feed. The specialist's raw trace stays in the Pulse view for audit.

How it works in Black Box

The CEO's delegation tools are MCP servers exposed by apps/engine/src/ceo/tools.ts. Each one wraps the Claude Agent SDK's query() call with the specialist's system prompt, its allowed-tool whitelist, and a scoped cwd. The SDK handles prompt caching, streaming, and result assembly; the CEO just reads the final result and decides what to do next.

Parallel delegation goes through spawn_parallel_specialists, which opens N query() calls concurrently and awaits Promise.all on their results. The circuit breaker watches each branch independently, with a known limitation on attribution for tool-call and token counters (see circuit breaker).

When the CEO will ask you first

The CEO will pause and emit an approval_needed card before delegating if:

  • The sub-task spends more than the remaining per-task credit cap in one call.
  • The sub-task is externally visible (publishing, sending, charging) and has not been pre-approved.
  • The sub-task touches a connection that has not been authorised.
  • The CEO has tried two specialists already and both rejected the work.

Frequently asked

What does the CEO pass?
A scoped brief — the sub-task, the relevant memory, and any prior outputs. Never the whole context window.
What if the wrong specialist was picked?
The Evaluator catches most of it. The CEO re-plans and re-delegates, or asks you.
Can I override?
Yes. Tell the CEO which specialist to use — or to not use one at all.
When is parallel a good idea?
Genuinely independent sub-tasks that can race. Ten-minute jobs become ninety-second jobs.

Related concepts

Next: skill packs

Specialization beats generality. Skill packs make your specialists vertical.