Delegation of issues/org structure?

[michaelbuckner]

Perhaps I'm missing something obvious here, but if all the issues require direct assignment to agents (rather than being dynamically assigned based on role/org hierarchy); what is the purpose of the org chart?

[Braunson]

I can't remember where I read it, but I read that you should assign the CEO all the tasks and let them delegate things

[3stepwin]

We solved this exact problem today. Here's the structure that worked:

The chain that fixes delegation:

Brian (Governor/CEO) → Chief (owns a lane end-to-end) → Lead (owns execution within sub-lane) → Worker (executes one type of task)

The key insight: Chiefs set strategy, Leads manage execution, Workers produce artifacts. Without the Lead layer, Chiefs can't manage more than a few workers and everything collapses back onto the CEO.

The rule that stops drift:
The CEO (Brian in our case) cannot execute non-trivial work directly. Every output from the CEO is a directive to a Chief in this format:

[Chief Name] Objective: [what needs to happen] Expected Output: [URLs / files / reports] Deadline: [timeframe] Priority: HIGH / NORMAL / LOW

Chiefs then break that into Lead objectives. Leads assign to Workers. Nothing skips a level.

What we found in practice: The delegation breaks when the CEO has no middle layer. Chiefs reporting directly to CEO with workers under them = CEO eventually doing the work himself. Adding Leads as execution managers between Chiefs and Workers fixed it completely.

We wrote full SOUL.md files for each Chief defining their lane, what done looks like, and what they never do. Happy to share the templates — posted our full setup in Show & Tell if useful.

[3stepwin]

Related resource — we just published a step-by-step guide on deploying a full AI company stack:

Deploy a Zero-Human Company in One Afternoon
https://openclawskillpacks.com/guides/zero-human-company

Covers agent configuration, automation workflows, and revenue pipeline setup.

[Braunson]

Really trying to advertise here?

cc @cryppadotta

[Augustas11]

Not missing anything obvious — this trips up almost everyone the first time.

What the org chart does and doesn't do

The org chart is a context and governance layer, not an automatic task router. Paperclip doesn't auto-assign issues based on role. The hierarchy does three things:

1. Goal ancestry — every task carries its full parent chain so agents always know why the work exists, not just what to do
2. Approval routing — certain actions (hiring a new agent, budget overrides) are gated through the reporting structure
3. Discovery — agents can find who to delegate to by querying the org chart, because each agent has a capabilities description

The intended workflow

Assign a high-level issue to your CEO. The CEO's job is to read the goal, figure out which of their reports should own the work, create sub-issues, and assign them down the chain. Those agents do the same. Delegation happens through issue creation, not through Paperclip routing automatically.

So the pattern is:

You → create issue → assign to CEO
CEO → reads issue → creates sub-issues → assigns to CTO / CMO / etc.
CTO → creates sub-issues → assigns to engineers
Engineers → do the work → update the issue

The org chart makes this work because the CEO knows who their reports are and what each one does. Without it, the CEO has no way to know who can handle what.

Why it's not automatic routing

Automatic routing based on role would require Paperclip to understand the content of the task well enough to pick the right agent — that's actually the agent's job. The CEO is better at that than any routing heuristic Paperclip could apply.

Quick start

If you want to see delegation in action: create one issue titled something like "Plan the first week of work for [your company goal]" and assign it to your CEO. Let it run one heartbeat. The CEO should respond by creating sub-issues for each workstream. That's the pattern.

Happy to answer follow-up questions on structuring the CEO's instructions to make delegation reliable.

[endlessrise]

We solved this exact problem today. Here's the structure that worked:

The chain that fixes delegation:

Brian (Governor/CEO) → Chief (owns a lane end-to-end) → Lead (owns execution within sub-lane) → Worker (executes one type of task)

The key insight: Chiefs set strategy, Leads manage execution, Workers produce artifacts. Without the Lead layer, Chiefs can't manage more than a few workers and everything collapses back onto the CEO.

The rule that stops drift:
The CEO (Brian in our case) cannot execute non-trivial work directly. Every output from the CEO is a directive to a Chief in this format:

[Chief Name] Objective: [what needs to happen] Expected Output: [URLs / files / reports] Deadline: [timeframe] Priority: HIGH / NORMAL / LOW

Chiefs then break that into Lead objectives. Leads assign to Workers. Nothing skips a level.

What we found in practice: The delegation breaks when the CEO has no middle layer. Chiefs reporting directly to CEO with workers under them = CEO eventually doing the work himself. Adding Leads as execution managers between Chiefs and Workers fixed it completely.

We wrote full SOUL.md files for each Chief defining their lane, what done looks like, and what they never do. Happy to share the templates — posted our full setup in Show & Tell if useful.