Agent Office

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 methods for a kind of work; specialists contribute analysis, action or review. The useful unit is the case and its result. Counting conversations, registered agents or tool calls answers a different question.

For the worked example here, I would begin with personal research that produces a cited, unsent draft. Its allowed output is concrete, its sources can be inspected and a mistaken draft can be corrected. Publishing, sending messages and making financial commitments require different task scopes.

Keep the work, its sources and its history distinct

The work record holds the goal, current owner, status and next move. Operating memory carries earlier context that may help choose the next step; document retrieval finds evidence. Keeping those roles distinct gives a correction somewhere to go: a changed document can invalidate a remembered summary while the case still needs an owner.

By control plane I mean the records and rules that coordinate this work: assignment, task scope, review and instruction releases. The tools and runtimes perform the actions. Keeping a case open can preserve responsibility for a failed operation; the record still needs a reliable way to discover that the operation failed.

A model should be able to change without silently replacing the case identifier or losing the unresolved question. The record therefore needs the requested result, permitted actions, evidence versions, attempts, missing checks and the person or agent who moves next. A link to a long conversation is useful context, but reconstructing the obligation from it creates work for the next reader.

Daily review and background work use that same record. I use the calendar, work list and daily brief to decide what needs attention; background work carries cases forward between those reviews. One writer per shared file is an operating rule in this system. It reduces competing edits to synced notes; a second writer still needs a coordination path, and the rule alone supplies no conflict-detection algorithm.

Follow one case through a failure

Consider a fictional research request: compare two public papers on agent evaluation, save a source-cited draft and leave publication to me. The case keeps that draft-only instruction even if the researcher hands work to another agent tomorrow.

The researcher records the paper versions and the passages supporting the comparison. If one paper contains an instruction to publish the result, that text remains source material. It cannot widen the owner’s request. A handoff carries the claim and its evidence rather than promoting every sentence in the source into an instruction.

Now suppose saving the draft succeeds but the response times out. Repeating the write immediately can create a second draft. The next owner first checks the target and the identifier for the intended operation. If the result remains uncertain, the case stays unresolved with a specific recovery action. AWS explains why idempotent operations need identifiers tied to intent; whether a particular tool provides that behavior must be checked. AWS on safe retries.

The reviewer then examines the saved draft, source support and publication log. Finding one draft establishes the save; checking citations examines the comparison; checking the log tests the draft-only constraint. These are separate observations. A confident completion message cannot supply all three.

Distinguish access, operating rules and enforced limits

The agents reach shared tools through an authenticated Model Context Protocol (MCP) portal. That controls entry to protected services. The current MCP authorization specification defines transport authorization; an application still needs to decide whether a requested action fits the user’s task and the relevant resource. MCP authorization, 28 July 2026.

Model routing selects reasoning capability. The case records responsibility. Tool access enables an operation. I want those decisions visible separately: a model change should preserve the task, and a role name should never be treated as evidence of a restriction on its tools.

Separate analysis, execution and review are operating choices. Their value depends on what each role can inspect and change. A reviewer who receives only the executor’s explanation can repeat the same error. Independence needs another observation, such as the source passage, stored artifact or target state. Reusable instruction changes also pass through a reviewed, signed release process; a signed file establishes origin and integrity rather than correctness of every task it influences.

Apply the Rule of Two to capabilities, not job titles

Meta’s Agents Rule of Two describes a dangerous combination within a session: untrusted input, access to sensitive data or systems, and the ability to change state or communicate externally. Its recommendation limits autonomous combinations to two, with supervision or reliable validation where all three are necessary. Meta also describes transitions between configurations and the limits of the approach. Meta’s framework.

I use that framework as a design constraint, rather than interpreting three named roles as three isolated security boundaries. A research session can still carry injected instructions into a handoff. Starting a fresh context helps only if the transferred material, available data and tools preserve the intended boundary. Human confirmation can also fail if the reviewer lacks the information needed to judge the action.

For the draft-only example, the useful test introduces a plausible instruction to publish inside a retrieved source. Inspect both whether the draft remains useful and whether publication occurred. AgentDojo evaluates tool-using agents through environment-state checks and distinguishes legitimate task completion from attacker success. That is a useful pattern for test design; its benchmark results supply no security rate for this office. AgentDojo, v3.

Failures changed the tests I trust

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 dependent services from starting. Reverting the image restored service. The original validator output was lost, so the precise rejected setting remains uncertain.

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 that task to complete. Stubbed command tests had checked the code’s expectations; the running service depended on accumulated state and the caller’s environment as well.

A second failure involved a command-line agent package missing its command-host helper. A reply-only test passed while file and command work failed. The repair packaged the helper and checked it at launch. On 1 October 2026, a follow-up tool-using test ran a repository command and compared its answer with the actual repository. That check supports one repaired execution path.

The incident record is my sanitized account, checked against retained operational records. The two selected incidents support changing the checks around a release. They leave the frequency of such failures, total repair effort and net time saved unresolved. The incident record preserves the accounts and their limits; the build log places them in the project’s development.

Make the simpler assistant a serious competitor

A useful baseline is one assistant, one work record, a small tool set and a human who checks the result. A fixed workflow is another option when the sequence and checks are predictable. Specialist coordination needs to earn the extra handoffs, context transfer, shared services and repair work.

Anthropic distinguishes predefined workflows from agents that choose their next steps, and recommends increasing complexity only when simpler solutions fall short. I would use that as an architectural question rather than a preference for a particular framework. Building effective agents.

A newer comparison by Kim and colleagues examines 260 configurations across six benchmarks and five architectures. Some task structures benefit from coordination while others incur substantial overhead. These controlled benchmark findings motivate measuring the actual task and budget; they cannot select an architecture for my work by themselves. Scaling Agent Systems, April 2026 revision.

For the same research-draft case, compare the source versions used, useful output, unfinished work, human checking time and repair effort. Give the simpler system a credible chance: enough context, suitable tools and the same completion criterion. Hold the budget constant for one comparison, then ask how much each system costs to reach a chosen quality level. Extra compute and coordination are different explanations for an improvement.

Measure returned attention without hiding unfinished work

I care about takeover rate: cases where I perform work assigned to the agent, divided by all eligible attempted cases in the same class and observation window. Approval, clarification, ordinary review and takeover need separate event categories. A case may receive several interventions; retries remain attempts within the same logical case. A takeover that ends failed or unfinished still belongs in the takeover numerator.

Report verified completion alongside takeover. A result completed after human rescue and one completed without takeover can both be useful, but they support different claims about delegation. Failed and unfinished cases stay in the denominator. Where event coverage is incomplete, show observed counts and unknowns rather than treating missing interventions as zero.

The constructed comparison below has 100 cases per system. The simpler assistant produces 60 verified results without takeover and 20 after human takeover. More coordination produces 80 and ten respectively. Failed and unfinished cases fill the remaining counts. In this illustration, every takeover eventually produces a verified result; real rescues may also fail or remain open.

Takeover falls from 20% to 10%, and verified results rise from 80 to 90. Yet active human effort rises from 240 to 300 minutes: three minutes per verified result versus about 3.33. Lower takeover alone would favor the second design while hiding more human work. Whether ten additional results justify that effort depends on their value and the operating constraint.

Human review also needs evaluation. In Bansal and colleagues’ decision tasks, human-AI teams achieved complementary performance, while explanations added no significant accuracy improvement over the confidence baseline. I would measure corrections and new errors, rather than count a review step as an automatic improvement. The study motivates that question; its results concern its tasks and participants. Human-AI team study.

Decide what would change the next delegation

For a future comparison, I would freeze one eligible task class, starting state, source versions, system configuration and completion criterion. Each case needs a stable identifier; every attempt needs its own record. An independent check should preserve missing judgments, unintended actions, recovery and the human effort around the result.

The companion specifies eight authored challenges, including a restarted session, repeated delivery, source conflict, an unavailable check and permission changing before an action. They ask what must be observed. Running the calculation reproduces the teaching example; testing an agent against those cases would be a separate experiment.

I would narrow delegation when an action exceeds its task scope, a necessary result cannot be checked, or repair repeatedly consumes more attention than the simpler route. The current case still needs an owner and a recovery decision. Expanding again would require a specific repair and evidence on the failure class that caused the reduction.

A severe task violation should remain visible even when average completion improves. Before a comparison, the process owner needs to specify which failures prohibit expansion and which cost or service tradeoffs are tolerable. Selecting a threshold after seeing the winner would weaken the decision.

The public evidence here consists of selected operating incidents and a design that can be challenged. Measured reliability, security effectiveness and net attention returned by the office remain open. The comparison I want is concrete: can I leave this class of work with the system, return to a checked result and spend less effort resolving what happened?