Start with the laughable comparison, because it is load-bearing. You can spend serious money and serious engineering taste on the chair, the desk, the Thunderbolt chain, the continuity setup, the extra panels — and then discover that an M1 MacBook on your lap on the couch is, for agent work, basically as good. That should offend the multi-monitor religion. It should also make you curious.

The old developer workload genuinely benefited from acreage. Code on one surface, docs on another, terminal and browser in the corners: you were personally operating all four streams and correlating them in working memory. Extra glass held state you were actively using. That was working-memory extension, and it was rational.

Agents change the topology. They are not four surfaces you juggle. They are independent workers — ten, twenty, more — each with their own plan, tools, failures, and definition of done. You are not correlating their pixels. You are managing attention across autonomous execution. And human interactive bandwidth does not scale with their count.

Visibility doesn't scale. Triage does.

You do not have twenty-agent vision

You cannot do this:

Agent 1   Agent 2   Agent 3   Agent 4
   ↓         ↓         ↓         ↓
 read      read      read      read

No matter how many panels you buy. What you actually do is serial: read one, think, respond or decide, then re-enter another. Psychology has been blunt about the scale of that channel for decades. The focus of attention is small — on the order of a handful of chunks, not a trading-floor wall of feeds.¹ Interfaces that pretend otherwise are cosplay.

So the Bloomberg-terminal fantasy of multi-agent work — a grid of equal panes, each an agent, all "visible" — is the wrong inheritance. It assumes that manageability is a function of simultaneous visibility. Under autonomous execution, manageability is a function of what deserves your next unit of attention, how fast you can re-enter a job when you choose it, and whether the rest of the system can keep working without you staring at it.

An attention hierarchy, not more equal glass

What the couch experiment quietly demonstrates is an attention hierarchy people already build by accident:

That hierarchy is the hardware shadow of the doctrine this ebook is about. The factory — the box with the GPUs or the big RAM, the shells, the browsers, the databases — can expand. The agents can multiply. Your focal attention does not. So the human surface should collapse toward one excellent focal viewport and cheap ambient context, with everything else represented as state, not as more rectangles demanding eye contact.

Managers do not stare at twenty CCTV feeds

Once computation and autonomous work live elsewhere, the laptop is not the factory floor. It is the manager's desk. Good managers do not make themselves effective by tiling every camera feed on every wall and attempting continuous parallel surveillance. They need the right exception brought to the desk at the right moment — and a fast way to re-enter a job when they choose to care again.

That is why terminal-tab sprawl feels terrible even when the work is going well. Tabs are a spatial metaphor for process lists. They are awful at re-entry latency: recovering what this was doing, why, where it is up to, and what it needs from you. Twenty monitors would not fix that. A better attention topology might.

Cognitive load research has been making a related point in plainer language for years: working memory is limited, and interfaces that force you to hold too much at once degrade performance.² Agent UIs that treat "more simultaneous panes" as "more control" fight that fact.

The rest of this ebook is what follows if you take the discontinuity seriously. If human attention stays roughly one, and agents run for hours without you, then the scarce resources are not visibility and not even raw compute. They are attention and dispatch latency — how fast a fresh thought becomes a clean, independently owned goal without contaminating the goals already in flight. That missing interface is the Delegation Plane.

Attention topology (Chapter 1) explains why more glass fails. It does not yet name the metric that should replace "how many agents can I see?" Once you are past chat tourism — once agents are long-running, goal-bound, and mostly left alone — your day stops looking like continuous supervision and starts looking like this:

IDEA OCCURS
     ↓
externalise it (before it decays)
     ↓
find or create a clean owner
     ↓
dump intent as a goal
     ↓
LEAVE

Hours later, curiosity or an exception pulls you back. That loop has a nameable bottleneck. It is not token price. It is not the DPI of your panel. It is how long it takes to turn a thought into an independently owned goal without losing the thought, without polluting a goal already in flight, and without forcing you through a form that kills the spark.

Idea-to-agent latency is the UX metric. Everything else is secondary.

Agent-push versus human-pull

A lot of multi-agent product thinking still inherits from chat and from ops dashboards. The imagined primary problem is notification routing: Claude made a noise; which Claude was it? That is an agent-push model. The agent needs a human; it pokes the human; the human context-switches into the agent's frame.

That model is not always wrong. Exceptions matter. Distrust matters. A stuck recovery deserves a ping. But operators who have moved to strong goal patterns deliberately engineer the human out of the middle of the loop. The instruction is roughly: you are responsible for completeness, quality, and accuracy; test; review; continue until done. Interaction is not the product every three minutes. Interaction is the rare event.

Human-pull sounds passive until you notice what it protects. Every unsolicited ding is a tax on focal attention. Twenty agents that each "helpfully" narrate progress will destroy the manager's desk faster than twenty silent workers that only surface real blockers. The point of the interface is not to increase the number of agents you can watch. It is to increase the rate at which you can turn human intent into independently owned goals without losing, contaminating, or interrupting the goals already running. Call that delegation bandwidth.

What "fast dispatch" actually feels like

The ideal path is almost boring:

• A capture surface that is always one gesture away
• A project or environment choice that can wait until after capture (see Chapter 5)
• Eight terse lines of intent, not a novel
• A send that allocates a new goal owner when the unit of intent is new (see Chapter 4)
• An exit — you leave while the world changes

What people actually do, because tools force them to, is worse: rummage for the right chat; interrupt a running goal with "while you're there…"; stash the idea in a consumer notes app; type into an agent window and refuse to press Enter so the text sits there as a hostage queue; open a second device so they can talk while another device is still speaking. Those hacks are not personality quirks. They are product requirements written in sweat.

The industry is building the other plane

None of this denies that agent-side orchestration is real and getting better. Anthropic's public agent guidance distinguishes workflows (predefined paths) from agents that dynamically direct tool use on open-ended problems, and describes orchestrator–worker patterns where a lead model delegates and synthesises.³ Their multi-agent research system write-up goes further: a lead agent coordinates specialised subagents operating in parallel.⁴

That is the execution and agent-to-agent plane improving. Cloud and platform vendors are racing the same vocabulary — planners, orchestrators, shared memory, agentic orchestration as a product category. Useful. Incomplete. Almost none of that language names the human capture buffer, the difference between capture and send, or idea-to-agent latency as a first-class metric. Canon on long-running agents and context engineering covers how workers stay coherent for hours; this ebook owns how one human feeds them without drowning.

If you only remember one number from your own practice after reading this chapter, make it a stopwatch on your last three ideas: how long from spark to durable externalisation, and how long from externalisation to a clean owner that was not already busy. That pair is more honest than a screenshot of your monitor layout.

If you have ever managed people, you already know the failure mode. Someone is six hours into a difficult migration. You walk up and say: "Oh, by the way — tomorrow also look at the invoices. Don't forget." Then you are surprised when invoices have mentally blended into the migration and both jobs are slightly ruined.

That is not a metaphor stretched for effect. It is what operators do to long-running agents every day, because the interface offers one text box and one conversation as the locus of all intent.

The three states

Current interfaces basically offer one transition:

thought
   ↓
TYPE INTO CURRENT AGENT

That transition is the bug. The current agent already has a job. Your new spark may be related, may share a repo, may even share a machine — and still be a different unit of intent. Shoving it into the active context is how you get semantic blend: the plan softens, the definition of done gets fuzzy, and the first goal quietly loses priority to whatever you just blurted.

Failure stories for each conflation

Thought dumped into active goal

You are mid-extract on a legacy database. You remember the mail archive. You paste a paragraph into the same session. The agent "helpfully" starts interleaving mail recovery with schema work. Two days later neither is clean. You did not save time. You created a hybrid failure that is harder to debug than two separate jobs.

Thought with nowhere to land

The associative ones are the expensive losses. "That means the wiki navigation trace is also a governance trace…" is an edge you just traversed cognitively. Five minutes later you retain "something about governance and the wiki." The actual connection is gone. There was no capture primitive that did not require stopping the world, choosing a project, and opening the right chat.

Backlog that only exists as unsent text

Operators invent the worst queueing system in software: type the next task into the agent window and do not press Enter. Or keep a private list in a notes app that has no relationship to goal owners. Or use two phones so one can speak while the other listens. These are not cute hacks. They are evidence that INTENT-BACKLOG is a real state and the product does not offer it.

Active goal treated as conversation turn

Chat UIs assume turn-taking: you speak, the AI speaks, you listen, you respond. Your brain generates interrupts. When the output channel (streaming text, text-to-speech) blocks the input channel, the only volatile object in the system — your emergent thought — is the one thing forced to wait. That design is backwards for dispatch-heavy work. Chapter 5 names the fix as CAPTURE ≠ SEND.

Intent should be buffered outside execution.

A backlog that is not a software backlog

Once you separate the states, the "laundry list" stops looking like a lazy Jira. A normal software backlog is historically: here are things humans might eventually work on. The list that operators need under agent concurrency is different: a reservoir of human intent awaiting autonomous capacity.

That reservoir can be cross-project. It can be half-formed. It can sit for a day while an overnight goal finishes. What it must not do is live only inside the mental context of an occupied worker. Humans learned the management lesson a long time ago: do not interrupt the engineer with every remembered errand; put it somewhere, then allocate work cleanly. We then built AI workers capable of multi-hour autonomous execution and gave the human manager a chat box wired directly into the worker's current train of thought.

Of course the next missing layer is management. Not "more dashboards." A state machine for intent that refuses to pretend a thought is a goal and a goal is a chat reply.

Suppose an agent is deep into this:

/goal
Extract the old CRM database.
Understand the schema.
Design the Postgres target.
Import one record. Review.
Import a few. Validate.
Import all. Audit completeness and accuracy.
Keep working until this is done.

That instance is now occupied. Not in the trivial sense that a process is running. In the sense that matters for management:

• current goal and plan
• current context and assumptions
• current subagents and shells
• current failures and recovery loop
• current definition of done

Then you think: also convert the old WordPress articles into wiki pages. The wrong interaction is "hey Claude, while you're there…" You have polluted the worker. The right interaction is a new owner for a new unit of intent — or a backlog entry until you deliberately promote it (Chapter 3).

Same machine, same repo, same branch does not mean same goal slot.

Semantic occupancy

Staff management made this obvious. Give a strong person two concurrent hard tasks and they often damage the first. Agents under long goals behave the same way because the "occupation" is semantic: the plan and the done-test structure the whole trajectory. A mid-flight second objective is not free concurrency. It is a context injection that competes for attention inside the worker — and agent attention, like human attention, is not magically infinite. Context engineering has been hammering a parallel point from the model side: cluttered context degrades output before you hit a hard token wall.⁵

The goal slot

Rename what many tools call a thread or session. In the operator's mental model it is a goal slot:

PROJECT: archive

GOAL SLOTS
● Extract Access database to Postgres     Agent 7
● Normalise historical contact records    Agent 9
● Recover document attachments            Agent 11
● Generate wiki pages                     Agent 14
✓ Audit row counts against source         done

Click a slot when you care again. You are not checking in because it dinged (Chapter 2). You are re-entering a managed unit of work. The mapping is:

Your work unit changed

This is why people who run serious agent fleets end up with many sessions and feel vaguely guilty about it. The guilt is misplaced. The work unit evolved:

• Old: terminal = process
• Then: terminal = Claude conversation
• Now: Claude session = goal owner

Twenty sessions are not necessarily twenty things demanding attention. They are twenty occupied goal slots. That is a cleaner description of the job — and it only becomes load-bearing when agents actually run long enough for occupancy to matter. Long-running agent architecture exists precisely so a goal can own hours of progress without resetting; the human interface has to respect that ownership rather than treating every session as a disposable chat.

Subagent trees and shell observability are secondary escape hatches for when something is wrong or interesting. The primary UI is still delegation: idea → slot → owner → leave. If your tooling makes "new goal" expensive and "interrupt current chat" cheap, it is training you to contaminate.

What "unit of intent" means in practice

People stall here because relatedness feels like a licence to reuse the open agent. Related is not the same as same. A useful test: if the definition of done would change, or if failure of the new work should not block the first outcome, it is a new unit of intent. Recovering mail is related to recovering Notes; it is still a second done-test, a second failure mode, and a second plan. Put it in the backlog or open a slot. Do not launder it into the first goal because the project folder is shared.

The same test protects you from the opposite error — slot explosion for trivial follow-ups that truly are mid-goal course corrections. "Search the VMDKs too" inside an active recovery is often a boundary expansion on the same outcome, not a second goal. Pidgin helps: say whether you are amending the current done-test or filing a new intent. Ambiguity is how slots and chats get confused again.

Picture a common scene. An agent or a chat model is reading a long answer aloud. You are half-listening — ambient cognition, actually useful for ethereal work — and mid-stream a sharp thought arrives. You cannot dictate into the same audio medium without collision. You cannot open the "right" project without dropping the thread. You hold the thought in working memory, keep listening, and watch it degrade into "what was I going to say?"

Some people solve this with two phones. That is not a lifestyle brand. That is a missing product feature wearing a carrier plan.

The only volatile object

Inventory what is durable in a modern agent stack:

• transcripts and logs are stored
• agent state can be checkpointed
• databases and filesystems persist
• tool outputs can be re-run or re-fetched

The emergent human thought is the exception. It has a decay curve. Some thoughts survive. Many do not — especially the associative ones that are valuable precisely because they are an edge you just traversed: "the wiki navigation trace is also a governance trace…" Minutes later you have residue without the connection.

Yet the UI typically gives priority to the model's output, the current conversation's turn-taking, and the requirement to classify before you may speak. That is backwards. The scarce, perishable object should get the sacred path.

Capture pressure

Write it as a product formula, not a vibe:

Agent concurrency tends to raise idea-arrival rate. More surface area for association; more outcomes to react to; more backlog time that itself spawns further goals. Decay rate is partly human and partly situational — fatigue, interruption, audio contention. Time-to-externalise is almost entirely an interface choice: how many gates stand between spark and durable text (or audio) outside your skull.

When arrival climbs and externalisation is slow, capture pressure spikes. People experience it as "I'm getting forgetful" or "I'm drowning." Sometimes age is in the story. Often the story is simpler: you are generating more high-value thoughts per hour than your tools can absorb, and the tools were designed for turn-taking chat, not interrupt-driven intent.

Working memory research is the unglamorous ally here. Capacity is limited; overload drops performance.¹ Every second you force a thought to stay only in mind — while you finish listening, choose a project, find a free agent, fill a form — you are spending the same scarce resource Chapter 1 said does not scale.

CAPTURE and SEND are different verbs

Enterprise software usually does the opposite of capture-first:

Choose project
Choose category
Choose task type
Choose priority
Give it a title
Now type description

By then the idea is dead. The AI-native version is almost rude in its simplicity: speak or type the spark; mark captured; let classification be a later, possibly automated step. Audio playing? Capture over it. Agent working? Queue beside it. Another thought half-typed? Fork a new capture. Wrong project? Do not make me choose yet.

Capture first. Classify later.

Why chat UIs fight you

Most chat interfaces assume conversation is the user's locus of intent. Therefore the AI's answer occupies the interface; the user is expected to consume and respond. Your cognition is generating interrupts. The mismatch is structural: the output channel blocks the input channel. When the scarce thing is fresh human intent, that is a catastrophic design priority.

Field workarounds write the requirements document for free:

• Apple Notes as the global cross-project inbox
• half-typed messages sitting unsent in agent windows
• two devices so listen and speak do not share one air medium

If a consumer notes app is the highest-level orchestrator in a stack that includes agent SDKs, subagents, browsers, and databases, laugh — then take the hint. The top of the Delegation Plane is missing, so people invent it with whatever is one swipe away.

By now the pieces are named. Attention does not scale with agent count (Chapter 1). Dispatch latency is the metric (Chapter 2). Thoughts, backlog intents, and active goals are different states (Chapter 3). Active goals live in slots with one owner each (Chapter 4). Capture is not send (Chapter 5). This chapter is the integrated artefact — the sketch you should be able to draw on a whiteboard after one reading.

The plane

                 DELEGATION PLANE

┌─────────────────────────────────────────────────────┐
│ INBOX / INTENT BUFFER                               │
│                                                     │
│ ○ index old mail files                              │
│ ○ recover dev conversation provenance               │
│ ○ inspect concept chronology                        │
│ ○ map treatment-plan leakage                        │
│ ○ compare wiki edge trace with agent governance     │
│                                                     │
├─────────────────────────────────────────────────────┤
│ ACTIVE GOALS                                        │
│                                                     │
│ ● Lotus Notes recovery              Agent 3         │
│ ● Archive CRM → Postgres            Agent 7         │
│ ● Wiki provenance model             Agent 11        │
│ ● Tenant isolation audit            Agent 16        │
│                                                     │
├─────────────────────────────────────────────────────┤
│ DONE / RESULTS                                      │
│                                                     │
│ ✓ old CRM imported                  review later    │
│ ✓ mail archive decoded              review later    │
└─────────────────────────────────────────────────────┘

The crucial operation is not "monitor agent." It is:

1. Capture intent into the buffer (CAPTURE, not SEND)
2. Promote intent to goal when you are ready to own the outcome language
3. Allocate a goal owner — a free slot, a new session, a clean semantic occupancy
4. Leave — and re-enter later by human-pull

That is delegation. Not supervision theatre. Not a prettier terminal multiplexer. Delegation.

Your Notes app is doing the highest-level orchestration job in the entire agent stack.

Why Notes keeps winning

Look at a serious stack with clear eyes: agent SDK, subagents, MCP tools, browser automation, Postgres, background shells, goal persistence, a large execution host. Then look at the global scheduler many operators actually use: a free-form list on a phone — do old emails, check wiki thing, recover Notes DB. That is funny. It is also completely rational. None of the agent interfaces have properly moved one abstraction level up. They still think they are the locus of intention. The human brain disagrees and votes with the nearest capture surface.

The full hierarchy

                 HUMAN
                   │
           generates volatile intent
                   │
                   ▼
            INTENT BUFFER
        capture without interruption
                   │
                   ▼
          DELEGATION PLANE
   classify / relate / prioritise / queue
                   │
                   ▼
             GOAL COMPILER
   North Star + done test + quality gates
                   │
                   ▼
             GOAL OWNER
        one occupied agent/session
                   │
                   ▼
          EXECUTION HIERARCHY
    subagents / tools / shells / processes
                   │
                   ▼
            WORLD-LOOP CLOSURE
                   │
              did it work?

Read the stack as a product map. Terminal multiplexers, agent control rooms, and tool trees attack the bottom half — execution legibility. Goal harnesses improve the middle — owned outcomes with persistence. The unsolved product, for operators who have already outgrown "how do I watch twenty Claudes?", is the top band: volatile intent, intent buffer, delegation plane, goal compiler.

What "goal compiler" means here

Promotion is not "paste the backlog line into a chat." Promotion is a small act of management: turn a rough intent into an owned outcome with a done test. Instruction says "import these records." Goal says "the historical database is fully migrated into Postgres, accurately, completely, with provenance preserved — sample first, expand, reconcile counts, keep working until done." That compiler step can be human, assisted, or eventually automated. It belongs on the plane, not inside a random occupied worker's context window.

Industry multi-agent systems already know how to fan work out once a lead agent has a mission.⁴ The hole is how a human with a noisy brain feeds that machinery without becoming the chaos injector. Human-over-the-loop research language is catching up to the supervisory posture — AI on routine path, human on judgment and exceptions — but still rarely names the capture buffer as infrastructure.⁶

Draw it, then place every tool

A practical test: list every surface you use in a week of agent work — notes, chats, terminal sessions, dashboards, voice memos — and place each on the hierarchy. If three different tools are pretending to be the inbox, you will drop intents between them. If nothing is the inbox except your working memory, capture pressure (Chapter 5) will punish you. If promotion always means "interrupt whoever is open," semantic occupancy (Chapter 4) will punish you.

The Delegation Plane is the name for the layer that makes those punishments unnecessary. You do not need a perfect product to start: you need an explicit buffer, an explicit promotion step, and an explicit rule that active slots are single-intent. Everything else is implementation detail.

The Delegation Plane (Chapter 6) is the structure. This chapter is posture — two habits that raise delegation bandwidth without buying a new product.

Variant A: agent pidgin

When you typed to humans, you paid social overhead: tone, politics, patience, fear of offence, the need to explain context the other person might not share. The message got long because the recipient was human.

When you type to a capable agent, a different protocol wins:

check old db
extract all customer/contact data
preserve ids + provenance
postgres
sample 1 first → review → 10 → review → all
audit counts
fix failures
responsible complete/accurate
/goal

That is not worse communication. For this recipient, it is a more efficient protocol. The agent expands operational detail. You provide shape, constraints, and a done test. Typing feels faster not because your fingers changed, but because you stopped serialising every step into prose designed for social animals.

That is why Chapter 5 still matters after pidgin: the scarce move is externalising the spark, not polishing the paragraph. Pidgin helps SEND and PROMOTE. Capture still needs its own sacred path.

Variant B: stop being the meat adapter

Old loop:

website fails
  → human observes
  → human screenshots
  → human finds the right chat
  → human pastes
  → agent interprets

Better loop:

website fails
  → agent has browser / logs / shell
  → agent observes
  → agent screenshots if useful
  → agent investigates

If you are the one taking screenshots, pasting stack traces, and copying rows out of a database "for" the agent, you are not managing. You are a tool. The rude but accurate phrase is: an MCP server made of meat.

Screenshotting the error is not a UI failure. It is you volunteering to be the tool loop.

The whole maturity trajectory of multi-agent work is removing yourself from that loop. Shell access. Browser access. Database access. Then your remaining human loop shrinks toward what the plane is for:

• idea → goal → delegate
• later: curiosity → inspect outcome

Human-over-the-loop language from the research literature points the same direction: do not ask humans to do what the system should do, and do not ask models to do what humans uniquely own.⁶ Being a flesh-and-blood screenshot relay is exactly the wrong half of that split.

Goals, not path police

Pidgin and tool autonomy only work if the unit of work is a goal, not a micromanaged script. An instruction says "import these records." A goal says the historical database is fully migrated, accurately, completely, with provenance — sample first, expand, reconcile, keep going until done.

Then the agent may choose a path that offends your taste: extract everything into a thirteen-gigabyte intermediate file, load from that, delete the monster. Your gut says "ridiculous." The management questions are different: did it work, was it accurate, was the intermediate disposable, was there disk, did validation pass, did it finish? If yes — fine. Disposable labour produced a disposable harness. Optimising elegance as if a human must maintain that harness forever is often the stupid optimisation.

That is the same doctrine from another angle. Protect the goal slot. Give tools so the human does not re-enter as a USB cable. Use compressed language so dispatch is fast. Measure success as world-loop closure. The plane stays clean because you stopped injecting yourself into the middle of every tool call — and stopped injecting second jobs into the middle of every goal.

Where the variants meet the plane

Pidgin without a buffer still loses sparks while you hunt for the right window. Tools without slots still invite "paste the screenshot into whoever is open." The plane is what keeps both habits from collapsing back into chat cosplay. Capture stays sacred and separate. Promotion uses compressed North Star language. Owners receive tool autonomy so you do not reappear as the adapter three times an hour. When you do re-enter, you re-enter as a manager changing search topology or accepting a closed world loop — not as a meat modem between the agent and its environment.

If a week of work still has you copying errors by hand, treat that as a tooling debt ticket, not a personal failing you must forever compensate for. The doctrine is blunt on purpose: every time you volunteer to be the tool loop, you tax dispatch latency and train yourself to stay inside execution instead of above it.

The twenty-agent future should not look like a grid of live chats. It should look more like this:

            CURRENT FOCUS
      (one decision / one dispatch)

         ATTENTION / STATE QUEUE
  1. approval needed — OpenClaw
  2. 3 failures — dental scan
  3. completed — reshape
  4. still working — wiki research

              BACKGROUND
     ● 11 agents  ● shells  ● tests

One fat focal surface. The rest represented by state, not pixels. When you select an item, re-entry should be fast: what was this doing, why, where is it up to, what does it need from you? That re-entry latency is the real multi-agent UX problem Chapter 1 started with. More monitors do not buy it. A plane that keeps goals clean and capture instant does.

Attention hierarchy, operationalised

Security operations writing has started describing the same human role shift in other domains: at higher autonomy, the analyst stops reviewing every alert as a personal task and starts managing a team of agents.⁷ Different industry, same topology: manager's desk, not factory floor.

Operating checklist

Stop asking how many agents you can see. Start asking how fast a thought becomes a clean goal.

What this ebook is not

Scope discipline matters because the temptation to braid is strong. This piece does not own goal-formation economics or the long-horizon "intent steward" that thinks in big blocks over weeks — that is a different article. It does not own which machine the fleet runs on. It does not own discovery posture or collision harvesting — why you watch the world for surprise. Those are real problems. They are not this problem.

This ebook owns the human-side interface: goal slots, CAPTURE ≠ SEND, attention topology, dispatch latency as the metric. Sibling work on long-running agents, context engineering, and compressing a month of work into a day covers adjacent planes; cite them when you need depth, do not collapse them into this one.

A week on the desk

Monday you open three goal slots before lunch because the capture buffer finally got a promotion pass — not because three chats dinged. Tuesday an agent finishes early via a shortcut you would not have designed; you check the done-test, not the aesthetics, and pull the next backlog item. Wednesday a thought arrives during ambient audio; you capture it without stopping playback, classify it later, and never type it into the migration still running. Thursday you notice you screenshot something; you fix browser access instead of building a paste habit. Friday you look at idea-to-agent times, not at how impressive the session list looks in a screenshot.

That week is boring on purpose. The plane is not theatre. It is how one human stays the bottleneck of dispatch — which is scarce and improvable — rather than the bottleneck of execution, which agents already outrun.

Close

Multi-agent industry energy is pouring into execution and agent-to-agent orchestration. That work is necessary. It is not sufficient. The operator who can spin ten goals and still lose the eleventh idea to a turn-taking UI has not failed at ambition. They have hit a missing layer.

Name it. The Delegation Plane captures volatile intent instantly, buffers it outside any execution context, and promotes it to independently owned goals without contaminating goals already in flight. Your scarce resources are attention and dispatch latency — not visibility. If Apple Notes is still the top of your stack, you already believe this. Now you have the vocabulary, the three-state model, the capture-pressure formula, and the sketch.

Build or improvise the plane. Protect the slots. Capture before you classify. Pull when you care. Let the factory run.