Design a useful agent team
Start with one assistant. Add a specialist when a recurring kind of work needs clearer instructions, separate context, or persistent ownership.
A role is a definition of responsibility. It is not proof of continuous activity. This workspace has 16 configured roles; that does not mean 16 agents are continuously working. Agents execute bounded assignments when triggered, and their results still need verification.
Who owns what?
Adam is the human owner. Barack is the sole coordinating CEO. The team separates portfolio ownership from shared specialist work:
| Responsibility | Owner |
|---|---|
| Professional work | Olivia |
| Teaching and learning | Sage |
| Consulting and business operations | Sterling |
| Personal and family operations | Taylor |
| Software engineering | Dev |
| Research and analysis | Marcus |
| Communications and content | Riley |
| Infrastructure and the agent platform | Forge |
| Quality and validation | Quinn |
| OpenClaw intake and coordination | Inbox |
| Knowledge and continuity | Dewey |
| Contract concerns and review questions | Matlock |
| Finance planning and administration | Vega |
Two additional project lead roles report through Sterling. Project-specific details stay in their own workspaces.
OpenClaw's conversational Barack remains the channel persona. Paperclip's Barack coordinates persistent tasks. Inbox provides explicitly scoped coordination between those paths; the design does not assume every chat request is automatically delegated.
Give each assignment a finish line
A useful handoff names the owner, relevant sources, desired artifact, acceptance checks, and permission boundary. Keep it small enough to complete and review.
For example:
Prepare a one-page comparison from these three public sources. Include source links, the main tradeoffs, and open questions. Save a draft for review. Do not contact anyone or publish it.
The coordinator checks that the artifact answers the request and resolves duplicates before treating the work as complete. A successful run alone is not evidence of a useful deliverable.
Match capability to the work
The primary path uses Codex through the existing OpenAI subscription. Claude Code is a deliberate exception for selected coding and architecture work; Riley uses Claude Opus for communication drafting. See model routing. Local models are optional. Choose a model for the actual task rather than assigning a permanent “cheap” or “premium” identity to a role.
Use rules for change detection, optional bounded triage for routing, and stronger models for substantive drafting, reasoning, and draft assessment. Check current availability and limits. If the intended route fails, report it rather than silently switching to paid access.
A beginner design prompt
Use this to plan before configuring anything:
Help me design one assistant for this recurring task: [task]. My approved sources are [sources], and the output I need is [artifact]. My constraints are [privacy, usage, and technical limits]. Define its responsibilities, permission boundaries, and a simple acceptance check. Suggest one tool to add after the basic task works, then one bounded automation. Treat sending and publishing as separate permissions. Do not install, configure, or schedule anything. Suggest a specialist or Paperclip only if persistent ownership would solve a clear problem.
Build confidence in that small loop first. A larger roster is useful only when the extra roles make the work easier to own, inspect, and finish.