Department Making

Department Making

Overview

Turn real work into the smallest useful agent architecture. Organize around stages that create value, give every department a testable contract, and keep one integrator accountable for the whole outcome.

Treat a department as a stable responsibility boundary. It does not automatically require a persistent agent, separate chat, custom profile, or automation.

Workflow

1. Establish the operating reality

Identify:

• The outcome and the person or system receiving it.
• The real inputs, source of truth, and existing outputs.
• The decisions that require judgment.
• The recurring variants and costly failure modes.
• The authority boundary for external communication, money, deletion, publishing, or live-system writes.

Inspect available artifacts when applying the skill to a real role. Label facts, assumptions, and unknowns separately.

2. Trace the value flow

Start with this neutral skeleton and rename its stages to match the work:

intake -> transform -> verify -> close

Map what changes at each stage, which artifact proves the change, and what decision advances the case. Do not copy a human org chart or group work by tool.

3. Apply the complexity gate

Begin with one integrator. Add a department only when at least two of these are true, including either the first or second condition:

• It owns a distinct output that can be accepted or rejected.
• It needs a distinct authority, data, tool, policy, or security boundary.
• It has an independent acceptance test.
• It recurs often enough to deserve a reusable method.
• It can work independently without creating shared-write conflicts.

If a single agent can reliably complete the work, recommend a single agent with a verification step. For a first multi-agent version, use two to four departments. Require observed evidence before exceeding four.

4. Assign the integrator

The integrator is the control plane. It owns:

• The user outcome, active plan, and run ledger.
• Routing, budgets, fan-in, and conflict resolution.
• Approval requests and final decisions.
• Final synthesis, delivery, and closeout.

Keep the integrator in the main task or session by default. Workers return compact handoff artifacts instead of transcript dumps.

5. Write department contracts

Read department-contract.md. Define every department's trigger, inputs, owned output, acceptance test, authority, prohibitions, state access, handoff, escalation condition, and stop condition.

Give each canonical record one writer. Parallelize read-heavy or isolated work only when the runtime provides bounded workers and concurrency materially helps. If workers are unavailable, run the same department contracts as sequential role passes inside the integrator: keep their outputs distinct, validate each handoff, and preserve the same authority and stopping rules. Fan all results into the integrator before a consequential decision or shared write.

6. Map the design to the runtime

Read runtime-architecture.md when the user asks how the design should exist in Codex, Claude, or another agent runtime, or asks about skills, agents, chats, continuity, state, or automations. Use the runtime's lightest primitive that preserves the contract.

Default mapping:

• Repeatable operating method: skill.
• Project-wide rules: the runtime's repository instruction file.
• Bounded independent work: temporary subagent when parallel work materially helps.
• Bounded work without available workers: a labeled sequential role pass inside the integrator.
• Active ownership and synthesis: one main task or session.
• Durable facts and mutable records: an external canonical store.
• Scheduled recurrence: automation, after the workflow is proven.

Never create a separate user-owned task, chat, custom agent, goal, or automation unless the user explicitly authorizes that action. Temporary subagents remain bounded workers inside the current run.

7. Return an understandable architecture

Present:

1. Recommendation and why departments are or are not justified.
2. The value flow.
3. The integrator's role.
4. A department table with owned output and acceptance test.
5. The Codex, Claude, or other runtime implementation and invocation model.
6. One representative run showing the handoffs.
7. What belongs in version one and what remains deferred.
8. Assumptions and unknowns.

When the user wants to learn step by step, explain one layer at a time in this order: value flow, department boundaries, contracts, runtime mapping, pilot. Continue safe implementation work while explaining it.

8. Pilot before promotion

Read pilot.md when implementing or validating a design. Run five representative cases manually before adding persistent workers, separate department chats, dashboards, or recurring automation.

Guardrails

• Do not create departments named after tools, communication channels, or vague corporate functions unless they own a distinct accepted output.
• Keep default parallel fan-out at three workers or fewer.
• Do not treat worker unavailability as a blocker when the contracts can be executed safely as sequential role passes.
• Keep transcripts as audit material. Store operational state in explicit artifacts or systems of record.
• Require human approval for consequential external actions unless standing authority is explicit.
• Record cost and latency as unknown unless measured.
• Delete any department whose handoff adds more coordination than useful specialization.
• Prefer a reversible manual pilot over infrastructure built for imagined scale.