What this workflow produces
By the end, the operator has three named desks running in parallel: one that gathers evidence, one that turns evidence into finished output, and one that watches the system. The desks share a wiki, hold private memory, queue jobs explicitly, and refuse out-of-scope work cleanly. The operator can inspect any desk's recent activity in under a minute. A fourth desk is added only when the work demands it.
This workflow assumes the operator has already reached the point where one generalist agent is failing — context overflow, role drift, or audit loss. The beginner bridge is in from prompts to desks; the full architecture theory is in work desks and specialty agents.
Step 1: Name the desks and write the charters
The first desk is the research desk. Its charter reads roughly:
Charter — Research Desk: Gathers evidence, compares sources, builds research briefs, flags uncertainty. Refuses writing, editing, or publishing work. Refuses recommendations outside its evidence base. Escalates ambiguous claims rather than guessing.
The second desk is the editorial desk (or production desk, if the output is not prose). Its charter reads roughly:
Charter — Editorial Desk: Turns research briefs and ideas into finished drafts in [organization] voice. Owns style, structure, internal linking, and editorial standards. Refuses new research. Refuses publication without passing the publishing desk. Escalates factual disputes to the research desk.
The third desk is the operations desk. Its charter reads roughly:
Charter — Operations Desk: Monitors job queues, watches scheduled runs, tracks system health, escalates anomalies. Does not produce creative or analytical output. Does not make policy decisions. Maintains the audit log.
Each charter is short — one paragraph for scope, one paragraph for refusal rules, one paragraph for escalation triggers. Anything longer means the operator has not yet decided what the desk is for. The piece on agent loops covers why bounded charters matter for system coherence.
The charters are written to a shared location. The desks read them on every session wake. The operator can change them, but the change is logged.
Step 2: Carve the workspace
The workspace has four zones:
Shared wiki. Stable facts, glossary, policies, SOPs, the charters. Every desk reads it; the owner edits it; the desks propose changes through a logged mechanism rather than editing directly. The wiki is the source of truth for anything an outsider would need to know.
Desk memory. Private working memory for each desk. The research desk's memory holds active investigations, known sources, and recurring question patterns. The editorial desk's memory holds voice conventions, style rules, and recurring structural templates. The operations desk's memory holds known failure modes, normal baselines, and tuning notes. Desks can read each other's memory when explicitly granted, but the default is private.
Job folder. A folder per active job, holding drafts, analyses, intermediate artifacts. The assigning desk and the reviewing desk can read it. The job folder gets archived when the job is complete.
Audit log. Immutable history of every job assignment, escalation, charter change, and policy decision. The owner, the operations desk, and the CEO agent can read it.
The workspace is not flat. The principle is: shared knowledge lives in the wiki; private context lives in desk memory; per-job artifacts live in job folders; durable records live in the audit log. The piece on why context explodes without bounding covers the cost of getting this wrong.
Step 3: Define the job queue pattern
A job has five fields: title, owner desk, inputs, definition of done, and deadline. A job without a definition of done is not a job; it is a wish. The operator refuses to queue any job that does not have all five fields filled in.
The job queue is visible to the CEO agent and to the owner desk. The flow is:
1. The owner or a trigger submits a job request to the CEO agent. 2. The CEO agent validates that the job has all five fields. If not, the job is bounced back to the requester with the missing fields called out. 3. The CEO agent assigns the job to the correct desk. 4. The desk picks up the job, executes against the definition of done, and reports back. 5. The CEO agent reviews the output. If it meets the definition of done, the job is closed. If not, the job returns to the desk with notes. 6. The audit log records the assignment, the review, and the close.
The five-field rule is the simplest refusal mechanism in the system. Most ambiguity, most conflict, most rework starts with a job that did not have a clear definition of done. The discipline of filling in the five fields is what keeps the rest of the system clean.
Step 4: Wire up the communication patterns
Three message types are enough:
Ask. A question or request for analysis. No deliverable expected. Example: "Research desk, what do we know about agent loop failures in production deployments?"
Job. An assignment with a deliverable and deadline. Example: "Editorial desk, draft a 1,500-word article on the work desks field note in Triadive voice by Friday."
Escalate. An upward message triggered by uncertainty, risk, or missing authority. Example: "Operations desk escalating: nightly health check has failed three nights in a row. Need human review."
The desks use the same three types when communicating with each other through the CEO agent. The peer-to-peer pattern is limited: a desk may request a bounded input from another desk through the CEO agent, but it does not initiate new work in another desk's queue.
This pattern is not chat. It is structured traffic. The header makes the intent explicit, and the explicit intent is what makes the system auditable.
Step 5: Run a 14-day pilot
The pilot runs for two weeks. The work is real work — not a contrived test. The desks handle real jobs with real deadlines and real review standards. The operator watches three things:
Throughput. Are jobs being completed at a reasonable rate? Are any desks consistently the bottleneck? A bottleneck is not a failure — it is information. It tells the operator which desk needs more capacity, better tools, or a sharper charter.
Quality. Are the outputs meeting the definition of done? Are reviews catching problems before they reach the owner? Is the editorial standard being applied consistently?
Audit. When the operator asks "what happened with X," can the answer be reconstructed from the audit log and the desk memory in under five minutes? If not, the workspace structure is wrong.
The operator does not change the charter during the pilot. The point of the pilot is to learn what the charter should say, and that is only visible if the charter is held constant. Charters are revised after the pilot based on what was learned.
Step 6: Add the publishing desk only if needed
The publishing desk is the fourth desk most operators add, and it should only be added when the release function genuinely needs its own permissions boundary. The signal is one of these:
- The output is going to a system where accidental overwrites cause visible damage (a production website, a public dataset, a customer-facing surface).
- The publishing step requires credentials that should not be held by the editorial desk.
- The publishing cadence is different from the editorial cadence — for example, drafts are written continuously but releases happen on a schedule.
- Post-publication checks need their own memory — what breaks, what redirects, what the search engines do.
If none of those are true, the editorial desk can publish directly. The publishing desk is a specialization, not a default.
The same logic applies to the automation desk. Add it when workflow changes are frequent enough to justify specialized control. Otherwise, the operations desk can handle scheduled jobs alongside its monitoring work.
Step 7: Decide what to keep and what to throw away
After the pilot, three things usually surface:
Some jobs were not worth doing. The desk did the work, but the output was not used. The fix is upstream — tighter intake, clearer definitions of done, more aggressive refusal.
Some jobs were the wrong desk's work. The research desk ended up doing editorial work, or the editorial desk ended up doing research. The fix is charter revision — sharper refusal rules, better escalation paths.
Some jobs were missing. The desks did what was assigned, but the owner did not assign the work that mattered most. The fix is operator discipline, not desk design.
The operator writes down what was learned. The charters are revised. The workspace structure is adjusted. The audit log is reviewed for patterns. Then the cycle repeats.
The minimum viable version
For operators who want the smallest workable version of this workflow, here it is:
1. Three charters — research, editorial, operations — written down in one paragraph each. 2. Three folders — wiki, desk memories, audit log. Job folders are optional until the volume justifies them. 3. A five-field job template — title, owner desk, inputs, definition of done, deadline. 4. Three message types — Ask, Job, Escalate. 5. A two-week pilot with real work and held charters. 6. A weekly review where the operator reads the audit log, checks the desk memories for drift, and decides whether the charters need revision.
That is the minimum. Anything more is appropriate for the operation's actual scale. Anything less is leaving the same problems the operator was trying to solve.
What to read next
The full desk architecture theory: work desks and specialty agents. The beginner bridge from one agent to three: from prompts to desks. The vocabulary foundation: work desk, specialty agent, job. The operator-grade failure patterns: desk architecture failure modes.