the work cannot live in the chat

Today, I barely typed into my computer. I still directed a mobile release, investigated product defects, shaped a testing tool, prepared for an interview, revised a public site, and managed the machines doing the work.

Most of it happened through voice. I did not dictate polished prompts or narrate a project plan. I spoke in fragments, changed subjects, remembered constraints halfway through a sentence, and returned later with new evidence. The useful part of the system was not transcription. It was the structure underneath: recognizing the project, resolving the owner, preserving priority, routing the work, and bringing the result back to one place.

I now think of that place as an executive cockpit above several project Chiefs of Staff. I can pour intent into it without first translating myself into tickets. The cockpit turns that intent into ownership, sequence, bounded authority, and proof. Direction flows down. Evidence, conflict, and uncertainty flow back up.

That experience sharpened the doctrine in this essay. The work still cannot live in the chat—even when chat becomes the most natural way to direct it. Conversation can be the intent layer. It cannot be the database, the repository, the acceptance test, or the final judge of what is true.

At small scale, I can hold all of this myself. That stops working once several projects have long-running work, shared machines, changing branches, and agents operating in parallel. Conversations fork. Context gets compressed. A status update begins ageing as soon as it is written. One agent says “done” while another is still proving the premise.

The response I have been developing separates four responsibilities: I retain intent and risk; each project gets one visible Chief-of-Staff lane; durable concerns have stewards; and workers receive bounded authority. Proof controls acceptance. Durable records preserve what the next agent needs without chat archaeology.

Voice is the intent layer, not faster typing

Most voice interfaces stop at transcription: speech becomes text, and the user still has to organize the work. The workflow I want is different. I should be able to think aloud at the level where the decisions actually exist. “Check the feed freeze next, but do not derail the release lane.” “This tool gap belongs to the tool team, not the product team.” “The runtime passed on Android; send only the accepted slice to my iPhone.” Those are not prompts. They are operating instructions with scope, priority, and authority inside them.

The cockpit has to recover that structure. It identifies which project owns the thought, finds the current control lane, separates a new request from a status question, and decides whether to act, delegate, wait, or ask me for authority. When the work returns, it reconciles the result with the exact candidate and proof tier before presenting it as something I can trust.

This is a top-down and bottom-up system. Intent, priority, and risk move downward. Runtime observations, repository facts, conflicts, and asks move upward. The middle layers carry structure so I do not have to continuously reformat my own thinking for the machinery.

Codex is the harness in which I have been able to make this concrete. Its tasks, subagents, filesystem access, tools, long-running execution, and evidence surfaces let the doctrine operate as more than a diagram. The underlying idea is portable: another harness could provide the same ownership, routing, and proof mechanics. I am careful not to confuse the general operating model with the product that currently supports it best for me.

Four responsibilities, deliberately separated

I remain responsible for what the work is for. I decide priority, taste, acceptable risk, and whether a technically valid result is actually the result I want. Agents can give me options, surface evidence, challenge a premise, and execute large parts of the work. I do not want them quietly inheriting product judgment because I stopped paying attention.

Below that sits the Chief of Staff, or COS. I use that name functionally. It is the visible control-plane lane for a project: the place where requests arrive, current work is sequenced, dependencies are noticed, workers are created, and results are accepted or sent back. There is one owning COS per project because two control planes with overlapping authority eventually produce two versions of the project.

The COS maintains an operational picture, but it must not become the project’s source of truth. I think of its view as a materialised view over the repository, decision records, stewarded doctrine, open work, and current evidence. It should be possible to rebuild that view. If the COS summary conflicts with the repository or a current proof artifact, the summary loses. Otherwise a persuasive coordinator can accidentally turn its memory into reality.

A steward has a different kind of responsibility. A steward is the durable custodian of a concern: mobile performance, release integrity, authentication, a public contract, or the project’s operating doctrine. It knows where that concern’s authoritative records live and is accountable for their freshness, governing rules, unresolved state, and invalidation conditions.

The useful questions for a steward are concrete:

• What do we currently know?
• Which artifact supports it?
• When was it last checked?
• What rule constrains the next change?
• What remains unresolved?
• What event would make the current view stale?

A steward is not an immortal agent with perfect memory, and it is not a roaming maintainer allowed to “helpfully” mutate every part of the system it watches. In practice it may be a dedicated agent lane, a named recurring responsibility, or a human-backed set of records. Its durability comes from its jurisdiction and artifacts, not from keeping one conversation alive forever. It observes, records, reconciles, and escalates. Any implementation authority beyond that should be granted explicitly.

Workers are intentionally more temporary. A worker receives one bounded outcome and enough authority to reach it. Its packet identifies the repository and relevant paths, the source material it should trust, what it may edit, what it must leave alone, the proof expected, and how often it should report meaningful state changes. A heartbeat is not constant narration. I need to know when the worker has started, crossed an assumption boundary, become blocked, or entered proof.

The packet matters because delegation transfers execution authority without transferring project ownership. A worker that discovers the task requires an architectural change outside its authority has found something useful. It has not acquired permission to make that change.

At closeout, I ask for the same five fields:

• State: what state the task is actually in, including partial or blocked work.
• Evidence: the revision, tests, scenarios, screenshots, traces, or artifacts that support that state.
• Next: the next known action if the work is not closed.
• Risk / Blocker: uncertainty, environmental failure, scope collision, or anything that weakens the verdict.
• Ask: the decision or authority needed from the COS or me.

This format makes it harder for a long, fluent summary to conceal an unproved result. “Implemented” describes activity. It does not tell me whether the project can safely accept the change.

Proof is a transition guard

I choose the expected proof before execution because proof selected after the fact tends to certify whatever the worker happened to produce.

The lowest tier is narrow proof. It answers whether the specific change behaves as intended in its immediate boundary: a focused test, a type check, a targeted build, a reproducible interaction, or a small piece of runtime evidence.

Standard proof checks the change in the surrounding system. That can mean an integration path, a named app journey, repeated cycles, relevant platform coverage, or comparison against an accepted baseline. It is the normal level for work that can disturb neighbouring behaviour.

Release proof is reserved for claims that affect shipping confidence. It includes the release gates, environments, devices, migration conditions, and stored evidence appropriate to the risk. Calling every task release-critical would make the system unusable, so the tier has to remain proportional.

The distinction that matters is between a worker’s claim and an accepted state transition. A summary can say the interaction is fixed. Healthy evidence from the agreed scenario allows the COS to accept that claim. A failed run, missing event, wrong platform, incomplete cycle, or stale build cannot support the transition even when the visible output looks encouraging.

Agent Scenario Loop formalizes part of this for my mobile work by keeping scenario contracts and evidence stable across different runners and instruments. It is useful here because it separates execution health from the product verdict. The wider doctrine does not depend on ASL, though. A test report, build output, screenshot sequence, profiler trace, network capture, or deployed observation can all be valid evidence when each one is tied to the claim it is meant to support.

More evidence is not automatically better. An enormous artifact directory with no declared question is evidence theatre. The proof needs a target, provenance, health, and enough context for somebody else to interpret it later.

Even accepted work remains falsifiable. Production can expose a condition that the chosen proof did not cover. Acceptance means the claim survived the evidence we deliberately required; it does not mean the system has become incapable of surprising us.

The work needs memory that can outlive the model

Chat history is useful context. It is a poor canonical store.

I separate several kinds of memory because each answers a different question. A conversation summary helps a new agent orient itself. A decision record explains why a constraint or direction was chosen. The repository says what currently exists. Scenario and test artifacts show what was demonstrated at a particular revision. Runtime evidence says what actually happened in a named environment. Open-state records preserve unresolved work and ownership.

The COS uses these records to maintain its current view. Stewards keep the relevant records fresh and connect them when a concern spans more than one artifact. Workers read them before acting and return new evidence when their work changes the state.

Durable memory also needs decay semantics. A memo that was correct three months ago can be more dangerous than no memo if everyone treats it as current. I want a record to carry its scope, date or revision, owner, and the condition under which it must be revalidated or superseded. The record should point back to authority rather than asking future agents to trust the quality of its prose.

This changes what happens after compaction or a week away from a project. I do not need a model to reconstruct the mood of the old conversation. It can recover the operating picture from current sources, see which decisions still govern the work, inspect the evidence behind accepted states, and locate uncertainty without inventing closure.

Ownership becomes visible when work crosses a boundary

The doctrine matters most when one project exposes work that belongs to another.

HelpBnk and Agent Scenario Loop are a useful example. HelpBnk owns its product journeys, app events, scenario definitions, configuration, and the truth of what a successful mobile interaction means. ASL owns its runner contracts, schemas, comparison behaviour, and proof mechanics.

Suppose a HelpBnk performance worker discovers that proving a composer interaction requires a runner capability ASL does not yet expose. The convenient move would be to let that worker patch ASL directly, validate the patch against HelpBnk’s immediate need, and continue. It might even work. It would also let a consumer quietly reshape a producer’s contract without the producer’s control plane accounting for compatibility, its own proof, or other consumers.

Instead, the HelpBnk COS sends a contract-shaped request to the ASL COS: the missing capability, the consumer scenario, the evidence of the gap, and the acceptance need. The ASL COS decides how the request fits its project, creates a bounded ASL worker, and owns validation in the ASL repository. The HelpBnk COS can collaborate with that worker after the owning COS has created it because consumer context is valuable. It does not edit or certify ASL directly.

Once ASL accepts and exposes the capability, HelpBnk consumes it and proves its own journey. Each project retains authority over its source of truth and acceptance boundary. The cross-project request remains visible instead of becoming an unexplained mutation somebody discovers later.

This is intentionally stricter than “all agents can work everywhere.” The restriction does not prevent collaboration. It makes collaboration legible.

Where the doctrine can fail

The obvious danger is turning useful coordination into ceremony. A typo does not need a steward consultation, a worker packet, three heartbeats, and release proof. For a small and reversible change, the COS can execute directly or create a lightweight worker with narrow proof. The system should expand with concurrency, ambiguity, blast radius, and duration. If the coordination costs more than the uncertainty it removes, I have chosen the wrong level.

The COS can also become a bottleneck. When it insists on mediating every implementation detail, workers wait and the control plane becomes one overloaded queue. When it starts doing most of the execution itself, its operational view degrades because the same context is trying to coordinate, implement, remember, and verify. I want the COS involved at authority boundaries, state transitions, collisions, and acceptance, with workers free inside the scope they were given.

Stewards can become ceremonial too. A steward with no freshness signal, review condition, or escalation rule is just an old document with a title. Worse, a steward can turn into a second invisible control plane by observing drift and then mutating several projects without permission. Custody needs explicit jurisdiction. Observation and escalation should remain distinct from edit authority.

Automation can create the same problem at machine speed. I had a workflow review running every three hours. Its job was sensible: catch durable decisions, scope drift, stale truth, and ownership conflicts. In practice it could create eight new tasks a day even when nothing deserved intervention. The instrumentation was working; the admission policy was not. The better design is thresholded and quiet: synthesize periodically, emit one routed memo only when a durable condition is met, and archive the routine run. Observability without a noise budget becomes another source of operational debt.

Proof can become performance. Unit tests may be green while the mobile interaction is broken. A screenshot may look correct while the underlying lifecycle is invalid. A long run can be incomplete, on the wrong platform, or attached to the wrong revision. Choosing the tier and claim in advance, preserving artifact health, and reviewing the relation between evidence and outcome are what keep “evidence-first” from becoming a slogan.

Parallelism has its own fiction. Two workers may appear isolated while sharing a simulator, branch, generated file, database, or mutable service. They can each report success and still corrupt the combined result. I only gain useful concurrency when authority and mutable state are actually separated, or when the interaction between them has been made explicit.

Routing can fail too. A conversational cockpit makes it easy to move between projects, but an ambiguous name or stale reference can send work to the wrong owner. The remedy is not to make me speak like a form. The cockpit should resolve the named project against current ownership, state its assumption when ambiguity matters, and keep the resulting work inside that project’s authority boundary.

Finally, the model can encourage overconfidence because every lane can produce a clean account of itself. The five closeout fields help, but they do not remove my responsibility to inspect the important seams. Delegation does not absolve the person defining the system.

What this gives me

The practical benefit is continuity I can interrogate.

When I return to a project, I want to know which source governs the work, who is responsible for keeping it current, what is executing, what revision changed, what evidence supports acceptance, what remains uncertain, and which project owns the next move. I should be able to answer those questions without reading every conversation in order or trusting whichever summary sounds most complete.

There is an emotional benefit too. Long-running agent work can become a fog of half-remembered promises and fragmented unfinished tasks. I used to carry more of that state in my head, repeatedly checking threads because I did not trust that silence meant progress or that “done” meant accepted. A visible control lane, bounded authority, explicit proof, and durable custody make the system calmer to operate. I can leave work alone for longer because I know how it must return.

The names may change as the workflow evolves. I do not expect every project to need the same topology, and I do not regard the components as novel inventions. The durable requirement is that increased execution capacity cannot be allowed to dissolve ownership, evidence, and memory.

As agents become capable of operating for longer and across more of a system, I am less interested in autonomy as spectacle. I want to be able to leave the work running, return later, and recover a defensible account of what happened, why it happened, what proved it, and where uncertainty remains. That is the kind of autonomy I can actually build on.