A Company Inside the Personal Computer

Multi-agent setups start to look less like tools and more like small organizations: shared substrates, replaceable engines, planners, implementers, reviewers, approvers, coordinators, operators, and a top-level agent. #AIAgents #PersonalComputing #AgenticWorkflows

1. The Shape Is Organizational

Once more than one agent is involved, the metaphor changes. At first the change looks like tooling. Then the roles, handoffs, approvals, and records begin to look like something older.

A single agent is a tool. A few agents with handoffs are a workflow. A durable set of agents with roles, review, approval, routing, memory, and escalation starts to look like an organization.

The earlier posts cover why multi-agent structure is useful, tmux as the surviving execution substrate, and the two state machines behind agent work. This final piece follows the consequence: once those responsibilities are split, the personal computer starts to contain an organization.

That organization does not have to be a company in the legal sense. It can live inside one person’s computer. But the operating shape is familiar:

• planners shape the work;
• implementers do task execution;
• reviewers check outputs;
• approvers guard risky actions;
• coordinators route work;
• operators handle status and trust boundaries;
• one top-level agent talks to the human.

The surprising part is not that AI can write code. The surprising part is that personal computing starts to borrow the structure of organizations because the same pressure appears: limited attention, risky boundaries, handoffs, and evidence.

2. The Human Stops Being the Operator

The old personal-computer story made the human the operator. The machine waited for commands. The user clicked, typed, dragged, copied, pasted, and watched progress.

Agent work changes the user’s job. The machine can keep doing terminal work, but that no longer means the human should supervise it at terminal granularity.

If terminal operation is increasingly handed to AI, the human should not spend attention on panes, process IDs, shell prompts, and routing commands. The human should spend attention on goals, priorities, exceptions, and approvals.

That moves the human up the org chart. The move is only useful if the system can carry enough state upward to make that higher position real.

The user becomes less like the person at the machine console and more like the company president speaking to an executive assistant. The top-level agent does not need to report every keystroke. It needs to report the decision surface:

• what is moving;
• what is blocked;
• what decision is needed;
• what risk changed;
• what artifact should be read;
• what can safely proceed without interruption.

This is why the visible UI can become narrower without becoming decorative. A CEO in a working company does not personally manage every handoff, queue, and small task. They need a briefing surface: goals, exceptions, approvals, evidence, and priority changes. A personal agent workstation should make the same move. It can expose the details, but the default human-facing surface should be built for executive review, not decorative reassurance or detailed task management.

3. Middle Managers Are Not a Joke Here

“Middle manager agent” sounds unflattering, but it is exactly the role that multi-agent systems need once execution fans out.

Someone has to aggregate work. Someone has to know that one implementer is waiting on review, another has failed verification, a third can proceed, and a fourth should not touch production data. Someone has to decide which details are worth escalating to the human. Without that role, the human gets either silence or a raw dump of every pane.

That is management.

In a small setup, this role is often a coordinator. In a larger setup, there may be several layers:

• a project coordinator;
• a review coordinator;
• a release coordinator;
• an approval coordinator;
• an operator.

The names are less useful than the flow. Execution fans out. Status rolls up. Decisions move to the level that can responsibly make them.

Human organizations invented this shape because attention is limited. Agent organizations will rediscover it for the same reason.

4. The Approver

The approver role exists because some actions should not run just because an implementer can run them. Capability is not authorization.

Deletion, deployment, credential changes, production data writes, external publication, irreversible migrations, public comments, and branch publication all have a different risk profile from editing a local draft. An implementer can be good at execution and still be the wrong actor to decide whether an irreversible action should proceed.

So the approver becomes a separate role. The system needs a place where momentum is allowed to stop.

This separation does not make the system safe by itself. Approval is not an OS sandbox, a permissions model, or a security proof. It is a recorded decision boundary. The point is to force a risky action through a different state transition:

1. request the action;
2. describe the reason and blast radius;
3. get approval or rejection;
4. record the decision;
5. proceed only if approved.

That looks bureaucratic when the work is small. It becomes essential when agents are fast, persistent, and capable of acting across many local resources.

5. The Operator

The operator role exists because state and boundaries multiply. A local agent workstation is not a single room once it touches phones, private networks, GitHub, credentials, and production-capable tools.

There is the boundary between private notes and a public repository. Between a local checkout and a remote server. Between a local terminal session and a phone or Telegram surface. Between a Tailnet viewer and the wider internet. Between GitHub publication and local notes. Between production data and test fixtures. Between credentials, logs, generated patches, and human approval.

An operator is not only a messenger. A messenger moves text. An operator carries context across a boundary where assumptions change: who can see the data, who can act, what is audited, what can be undone, and how large the blast radius is.

Private networking and local execution help, but they do not erase trust boundaries. A Tailnet can reduce exposure without making every phone action safe. A local terminal can keep work close to the user’s files while still holding secrets and production-capable credentials. A public GitHub comment is not the same kind of act as a local draft edit.

The same discipline applies to state. Runtime facts, project memory, and escalation policy should not collapse into one bucket. The runtime records what happened: message delivery, session state, approvals, and failures. Project memory stores slower-moving context: precedents, decisions, feedback, and review notes. The escalation layer decides when a phone, Telegram, GitHub, production system, or human approval boundary is being crossed. Mixing those layers makes the system harder to audit and easier to criticize.

That distinction has to survive as the workstation becomes networked. Telegram bridges, phone dashboards, SSH remote attach, Tailnet viewers, browser-based file review, GitHub publication, and local shell execution all have different trust assumptions.

The operator’s job is to keep those assumptions visible. It should name the boundary being crossed, the permission or audience that changes, the evidence that should travel with the handoff, and the action that still requires a human approval gate. That is an operational design rule, not a guarantee that the system is safe.

6. Why the Individual PC Still Matters

If the system starts to resemble an organization, it is tempting to put the whole organization in the cloud. The attraction is obvious: one hosted place, one account boundary, one interface.

Some of it will live there. Model calls already do. Team systems may centralize more of the runtime. But for individual work, the personal computer remains a natural headquarters. “Personal computer” here includes the user’s personally controlled machines: a laptop, desktop, home server, or remote host that stays close to the user’s own operating environment.

The reason is proximity to context. The valuable state is not only in the model conversation; it is already scattered through the user’s operating environment.

The user’s PC or personally controlled server already has the repositories, notes, dotfiles, SSH identities, local scripts, browser-adjacent artifacts, test environments, project checkouts, and half-written drafts. It is not just a device. It is an accumulated operating environment.

An AI subscription can provide intelligence. The personal computer provides the working memory of the user’s actual life.

This is also why the choice between Claude Code and Codex may become less central over time. If both can sit on the same tmux or herdr substrate, then the personal computer is not organized around one vendor’s command line. It is organized around the user’s durable workbench, with different agent engines available as interchangeable staff.

Provider constraints make that routing useful. Pricing models, subscription contracts, token budgets, rate limits, and service availability shape what the user can actually do. A small company inside the PC should be able to assign work to the engine that is affordable, available, and well matched to the task without moving the whole company-state with it.

That is why I expect a hybrid shape:

• models may be remote subscriptions;
• execution stays close to the user’s own machine or personally controlled server;
• state lives in local files and local services where possible;
• phone/browser/voice become the human interface, often over SSH or private networking;
• terminal processes remain the machine interface.

The AI organization lives where the work lives.

7. What herdr and postman Suggest

herdr and tmux-a2a-postman are not the same kind of tool, but together they make the organizational direction easier to see. One gives the office a runtime; the other gives it mail and obligations.

herdr makes the terminal workspace more agent-aware. Its official docs describe workspaces, tabs, panes, agent states, persistence, remote attach, integrations, plugins, and a socket API. That is a runtime surface for the organization: it lets agents and humans see, control, and recover real terminal work.

postman makes handoffs explicit. It gives roles names, routes messages through declared edges, stores archives, tracks reply obligations, and surfaces waiting or pending state. That is a coordination surface for the organization: it prevents work from depending entirely on one agent’s current context window or one human’s memory of a pane.

Together, they suggest the same future:

• terminal sessions become the office floor;
• panes become desks;
• agents become implementers or reviewers;
• message lanes become internal mail and obligation ledgers;
• task artifacts become case files;
• review and approval become gates;
• the human speaks to the front office.

The metaphor is imperfect, but it points at the operational structure.

8. The Top-Level Agent

In the mature version of this setup, the user should not talk to most of the agents. Talking to every role would recreate the terminal-pane problem at the conversation layer.

The user should talk to a top-level agent that behaves like the accountable representative of the whole local organization. That agent may delegate to Claude Code for one step, Codex for another, a reviewer for another, and an approver for a risky command. The user does not need to watch that routing by default.

In the stronger version of this forecast, the user also does not need to care which execution engine is active most of the time. Claude Code and Codex may keep different temperaments, integrations, and strengths, but they become replaceable implementers behind the same case files, panes, mail, checks, and approval gates. The organization owns continuity. The engine contributes labor. Provider limits then become scheduling inputs, not existential constraints on the whole workstation.

The top-level agent does not need to be omniscient. It needs to know when to delegate, when to summarize, when to ask, and when to stop. Those are routing judgments, not magical intelligence.

This is where the company-president metaphor becomes useful. The president is not less powerful because they do not operate the assembly line. They are more effective because the organization routes the right facts upward. The visible surface shrinks for the same reason: it should expose the state of the organization, not reproduce every implementer’s console. The question is whether the human can see what changed, where responsibility sits, and which boundary is being crossed.

For the human, the interface becomes smaller:

• speak the goal;
• read the summary;
• inspect the artifact;
• approve or reject the exception;
• adjust priorities.

For the machine, the system becomes larger:

• persistent terminal runtime;
• multi-agent coordination;
• mailbox and task state;
• review and approval records;
• memory and precedent;
• remote viewing and notification surfaces.

The visible UI can shrink because the hidden organization has enough structure to carry the work and enough trust-boundary discipline to know when the human must still decide.

9. The Forecast

The future personal AI setup is not just an assistant or a better terminal. It is a small organization inside the personal computer.

The human should not have to touch tmux, but tmux-like substrates will still run. The human should not have to stare at decorative dashboards, but the system still needs precise status. The human should not have to choose every implementer, but the system still needs roles, routing, approvals, and evidence.

The question shifts from “was that Claude Code or Codex?” to “which part of my local organization handled this, what evidence did it leave, and what decision do I still own?”

That is a different model of personal computing. The computer is no longer only a tool the user operates. It becomes a place where an organization works on the user’s behalf.