Agent Office
Earlier text, preserved before the 3 November 2026 revision. Read the current version.
I want agents to carry work across days without making me the system’s memory. I use a supervised office of specialist agents for my own projects, independent research and day-to-day planning.
The difficult part starts when a conversation ends with something still unfinished. Who owns the next move? What evidence supports it? Which decision needs my attention? Those questions shape the office more than the choice of model.
Start with the work that has to get done
The office supports independent research, personal follow-up, drafting, software review and my daily work list. I remain responsible for the commitments. Each piece of work needs a current owner, a next move and enough context to continue after an agent or session changes.
I call that continuing obligation a case. A desk supplies the methods and quality bar for a kind of work; specialists contribute analysis, action or review. Changing a model should leave ownership intact. A failed action leaves someone responsible for the repair.
Work can also start from a standing duty: something is due, overdue or has changed. Both paths need an owner. A quiet inbox tells me little about whether the commitments are moving.
Keep the work, its sources and its history distinct
The work record holds commitments and their current owners. Operating memory keeps context from earlier work; document retrieval finds the evidence that supports the next step. Keeping those roles distinct lets me ask where a statement came from and correct it at the source. An agent’s recollection and the underlying record serve different purposes.
The agents reach shared tools through an authenticated MCP portal. Model choice and permission to act remain separate. The reviewer is separate from the executor, and changes to reusable instructions go through review before becoming a signed release.
Daily review and background work
I use the calendar, work list and daily brief to decide what needs attention. Background work carries cases forward between those reviews. Both use the same work record; maintaining a second list would give me another reconciliation job.
There is a stricter rule for shared files: one writer per surface. Two agents can each make a valid edit to a synced note and still lose one another’s changes. The other agent contributes through the work record, where its suggestion can be picked up by the writer.
Failures changed the tests I trust
A reviewed upgrade failed at startup
On 2 October 2026, a runtime image change left an agent service offline for about 18 minutes. Code review and tests had passed. A configuration step failed during startup, preventing the dependent services from starting. Reverting the image restored service.
The replacement was tested against a copy of the existing state. A later task exposed a separate problem: the background runner and interactive gateway competed for the same state lock. Separating their execution state allowed the task to complete.
Stubbed command tests had checked the code’s expectations. The running service also depended on accumulated state and the caller’s environment. I now look for evidence at each of those boundaries before trusting an upgrade.
A reply test missed a broken command path
A command-line agent package was missing its command-host helper. A test that only asked for a reply passed. File and command work failed. The repair included the helper and verified it at launch; on 1 October 2026, the follow-up test ran a repository command and compared its answer with the actual repository.
These failures changed what I ask of a test. A code check, startup with representative state and a tool-using task answer different questions. An independent check of the result answers another. The added setup has a cost; I would rather spend it on the path the work actually needs.
Autonomy has to return attention
More review can make me the bottleneck. I want agents to earn autonomy on a defined class of work, with failures informing the next decision about what to delegate. Decisions should arrive together with their context, rather than as a stream of permission requests.
I use the Rule of Two as a design constraint: a session should never combine untrusted input, sensitive information and external action. Separating analysis, execution and verification gives each role a narrower responsibility. The division still needs testing: a verifier can repeat the executor’s assumptions, and every handoff adds time.
I care about takeover rate: how often I have to finish the work myself, divided by the cases in that class. I would consider it alongside errors, recovery, interruptions and cost per completed case. Fewer takeovers would mean little if failures went unnoticed.
A shared office also creates shared components to operate. Memory helps continuity but complicates correction. Review can catch mistakes but consume attention. Those costs belong in the comparison with a simpler assistant. My AI economics explorer examines the same tension through adoption and exception work.
The question I keep returning to is whether I can leave a class of work with the office and come back to a result I can trust. That is the standard I want delegation to meet.