The most common early architecture failure looks like this: one agent, one session, a long system prompt listing everything it should know, and a task list that grows without bound. Six weeks in, the agent starts missing details it used to catch, produces outputs that contradict each other, and the system prompt has become a 4,000-word document that nobody trusts.
The fix is organizational, not prompt-level. Split the work into separate work desks — each with its own context, its own charter, and its own queue — before the single agent accumulates so much competing context that it cannot see what it is supposed to be doing.
This article is a practical recipe. It assumes you have run a single agent successfully for at least a week and have hit the ceiling where one agent is starting to show the strain.
What you need before you start
You need a way to run multiple sessions or agents with separate contexts. In OpenClaw, this means separate sessions with different agent profiles. In other systems, this might mean separate bots, separate API keys with separate system prompts, or separate thread instances with different personas.
You also need a coordinating layer — the CEO agent that routes work to the right desk and reviews outputs. If you are starting from a single agent, you become the CEO agent initially. That is fine. The desk architecture can be real before the CEO agent is automated.
Desk 1: The Research Desk
The research desk is the easiest to justify because its failure mode is obvious: a general-purpose agent asked to do research produces inconsistent source quality, no citation discipline, and hallucinated citations that nobody catches until the output is in front of a client.
What the research desk owns:
- Web searches and synthesis
- Source evaluation and citation
- Data gathering and verification against primary sources
- Research briefs for specific questions
What the research desk refuses:
- Publishing decisions
- Trading signals or financial advice
- Tasks that require real-time execution
Setup: Give the research desk a charter that specifies minimum source quality (primary sources preferred, no single-source claims, no Wikipedia as a primary source), a memory surface that holds recent research findings and source URLs, and a tool profile that includes web search and a read tool.
The research desk does not produce finished work. It produces research artifacts — compiled facts, source links, data tables — that flow to other desks for processing.
Desk 2: The Publishing Desk
The publishing desk handles everything that leaves the system: articles, reports, summaries, emails, status updates. Its failure mode is also obvious: a general-purpose agent told to "write something good" produces output that is grammatically correct and substantively wrong, because it has no separate memory of the publication standards it is supposed to enforce.
What the publishing desk owns:
- Drafting and revision of all outbound content
- Style and formatting enforcement
- Review against source material for factual accuracy
- SEO optimization and metadata
What the publishing desk refuses:
- Research assignments (those come from research desk)
- Financial or legal conclusions not already cleared by a specialist
Setup: Give the publishing desk a charter that references the publication standards document, a style guide, and a queue of content assignments. The publishing desk reads source material from the research desk's output and produces drafts, not original research.
Desk 3: The Operations Desk
The operations desk handles scheduling, coordination, reminders, and queue management. Its job is to keep the other desks honest — tracking what was promised, when it was due, and whether the output was delivered.
What the operations desk owns:
- Cron job monitoring and exception reporting
- Reminder and follow-up scheduling
- Queue management and status tracking
- Status reporting to the CEO layer
What the operations desk refuses:
- Content decisions
- Research methodology
- External communications
Setup: Give the operations desk access to the calendar or scheduling tool, the workboard, and the ability to send messages. Its output is operational — status summaries, reminder triggers, queue reports — not content.
The handoff protocol
The most important part of a desk architecture is not the desks. It is the handoff rules — what happens when one desk finishes a piece of work and hands it to the next.
A clean handoff needs three things: 1. The output artifact — what was produced, in what format, with what sources 2. The status — done, escalated, or needs-revision 3. The routing — which desk receives it next, or whether it exits the system
Write these rules down. Do not assume the desk will figure it out on the fly. The time to specify the handoff is when you set up the desk, not when the first piece of work is moving and nobody is sure where it should go.
What to expect in the first week
The first week will surface two problems.
Problem one: The desks will hand off work that is not ready. The research desk will send a draft instead of source material. The publishing desk will publish without checking facts. Set explicit handoff criteria — what state the artifact must be in before it can move to the next desk.
Problem two: You will discover a fourth type of work that does not fit any of the three desks. This is normal. Add a fourth desk, or route that work type through the CEO layer manually until it is frequent enough to warrant its own desk.
The architecture grows from the work, not from a master plan.
Related terms
A desk is a work desk. A desk tuned for a specific function is a specialty agent. A discrete assignment for a desk is a job. The layer above the desks that routes and reviews is the CEO agent.
For a fuller treatment of what desks are, what they contain, and what can go wrong, see the field note Work Desks and Specialty Agents.