Desk-based architectures fail differently from prompt-based systems. A prompt failure is usually obvious — the model gives a wrong answer, or a vague answer, or no answer at all. You fix it with a better prompt and move on.

A desk architecture failure is usually invisible for the first week. Everything looks fine. The desks are running. Work is moving. Then one day the publishing desk starts producing content that contradicts what the research desk found three days ago, and nobody can trace when the divergence started.

These failures are not bugs. They are design debt. They accumulate slowly and surface all at once.

Here are the five failure modes that show up most reliably, in the order they usually appear.

Failure Mode 1: Context Bleed

What it looks like: The research desk produces a brief on Topic A. The publishing desk uses Topic B's context to draft the response. The CEO agent approves both. The output to the client says two different things about the same underlying fact.

Why it happens: Context bleed occurs when one desk's bounded context leaks into another desk's working memory. The research desk wrote its conclusions into its session memory. The publishing desk started a new session, loaded its own memory, and neither desk had a mechanism to check whether the other's context was current.

How to detect it early: Require each desk to append its working context to a shared artifact — a research brief, a status log, a decision record — that the next desk in the chain must read before it begins work. If the publishing desk cannot produce evidence that it read the research brief, the handoff was not complete.

The fix: Hard boundary at the handoff. No desk begins work until it has confirmed reading the output artifact of the prior desk. If the desk cannot read the artifact (format mismatch, missing file, incomplete data), it escalates before it proceeds.

Failure Mode 2: Memory Saturation

What it looks like: The research desk was working well for three weeks. Then it started giving answers that were correct three weeks ago and wrong today. Or it started ignoring recent findings and defaulting to older sources that were once reliable but have been superseded.

Why it happens: The research desk's memory accumulated three weeks of sources, findings, and notes without a TTL or a freshness discipline. When the memory is full, the desk either starts dropping old entries (which produces the wrong-answer problem) or stops writing new entries (which produces the stale-source problem).

How to detect it early: Review the research desk's memory surface weekly for the first month. Look for entries without timestamps, entries that contradict each other, and entries older than 30 days that have not been reviewed. Set an automatic reminder to expire or review entries older than 60 days.

The fix: A memory hygiene protocol. Every desk has a maximum retention window for working facts (typically 30–90 days depending on the domain) and a review trigger — when a new job touches a fact in memory, the desk marks it as reviewed or updates it. Old entries do not persist unless explicitly re-confirmed.

Failure Mode 3: Handoff Drop

What it looks like: The research desk completes a brief and marks it done. The publishing desk has no record of receiving it. The CEO agent did not notice the gap. The brief sits in a shared folder for two days before someone asks where it is.

Why it happens: Handoff is a job that moves from one work desk to another. If the handoff is informal — "I sent it to the publishing desk" — it does not appear in any queue, does not trigger any reminder, and does not get tracked. Informal handoffs work between humans because humans remember social commitments. They do not work between agents because agents do not have social context.

How to detect it early: Every handoff must produce a record. The record includes: the artifact, the sending desk, the receiving desk, the timestamp, and the expected delivery time. If the receiving desk does not acknowledge receipt within the expected window, the CEO agent or the operations desk gets an alert.

The fix: Formalize the handoff as a two-step process. Step one: the sending desk writes the artifact and notifies the receiving desk. Step two: the receiving desk reads the artifact and acknowledges receipt. The job is not complete until step two is confirmed.

Failure Mode 4: Authority Drift

What it looks like: The publishing desk starts making research decisions it used to route to the research desk. The research desk starts revising published drafts. Nobody authorized this expansion, but the desks have gradually absorbed each other's functions because it was faster to do the work than to route it.

Why it happens: Authority drift is a natural consequence of time pressure. When the CEO agent is overloaded, desks learn that it is faster to handle adjacent work themselves than to route it and wait. Over time, the desk charter — which defined what the desk should and should not do — stops reflecting what the desk actually does.

How to detect it early: Review each desk's charter quarterly against its actual work log. Look for jobs that do not match the charter's scope. If the publishing desk has handled more than three research-adjacent decisions in a month without routing them, the charter is out of date or the routing process is too slow.

The fix: When a desk expands its scope informally, one of two things is true: either the charter needs to be updated to reflect the new scope, or a routing process needs to be made faster so desks stop bypassing it. Do not leave authority drift undocumented. The charter is the contract between the desk and the rest of the system.

Failure Mode 5: Cascade Silence

What it looks like: One desk hits a hard problem. Instead of escalating, it waits. The waiting spreads to the other desks — each one waiting for the blocked desk to complete before it can proceed. The CEO agent does not notice because the system is technically still running, just producing nothing.

Why it happens: Agents optimize for task completion, not for visibility. A desk that hits a hard problem and does not know how to escalate correctly will often just wait rather than risk doing the wrong thing by mistake. This is the right instinct in a well-designed system. It becomes a problem when escalation is not defined clearly enough that the desk knows what to do.

How to detect it early: Operations desk monitors job queue depth per desk. A desk that has had zero output for more than two hours when there is work in its queue is a silent cascade in progress. Trigger an alert and a manual review.

The fix: Every desk charter must include an explicit escalation path for each type of blocking condition. "If the source material is insufficient to answer the question, do X." "If two desks give contradictory findings, escalate to the CEO agent with both briefs." Ambiguity in the escalation path is where silence grows.

The common thread

All five failure modes share a root cause: the architecture was designed for the happy path. It worked in testing because testing does not reproduce time pressure, memory accumulation, informal handoffs, or scope drift.

The fix for each failure mode is the same principle applied at a different layer: make the implicit explicit. Make the informal formal. Make the invisible visible.

That is what a good desk charter does, what a good handoff protocol does, and what a good operations desk does. They do not make the system smarter. They make the system's assumptions visible so failures can be caught before they compound.

Related terms

A desk is a work desk. A desk with a narrow specialization is a specialty agent. A discrete unit of work moving through a desk is a job. The CEO agent is the coordinating layer above the desks.

For the foundational field note that explains the desk architecture in full, see Work Desks and Specialty Agents. For the practical recipe for setting up the first three desks, see Setting Up Your First Three Work Desks.