Design Your Own OS

As agent systems grow, builders are tempted to expose every model, tool, worker, and mode. The result feels like a control room designed for the person who wired it. A useful operating system begins with one front door: one place where the user can state an outcome, recover context, review risk, and receive proof.

Your front door might be a chat, command palette, inbox, form, or voice interface. It should not perform every task itself. It owns the relationship: understand the person's intent, consult current truth, route the work, surface approvals, and return the result in language a person can act on.

A conversational surface without a truth layer becomes a charismatic guesser. The control layer holds durable knowledge, task state, runtime routing, and proof. It decides what the system knows, which worker fits the job, and what evidence is required before a result can be called complete.

This separation keeps the interface simple without making the system simplistic. The user's relationship can remain consistent while the worker underneath changes from a coding agent to a research agent, local operator, browser operator, or human.

The front door should accept outcomes in the user’s language: prepare this meeting, fix this build, reconcile these notes, or show what changed. Behind that simple request, the system can form a task packet with scope, context, constraints, owner, approval rules, and completion evidence.

Expose complexity when it helps the decision. Show the worker, sources, risk, and receipt—not every internal token or intermediate thought. The user needs control and legibility, not a stream of machinery.

A good front door knows when the path is unclear. It asks a narrow question when two choices materially change the result. It requests approval before a sensitive action. It reports a blocker with the attempts already made. These are not conversational niceties; they are navigation rules for the system.

The goal is not zero human involvement. The goal is to spend human judgment only where it changes the outcome.

Without a front door, every worker develops a separate memory, tone, task list, and definition of done. The user repeats context and becomes the router. The agents may be individually capable while the system remains exhausting.

Fix the relationship first. One intake path, one task identity, one truth layer, and one receipt format create coherence. Specialized workers can multiply behind that boundary without multiplying the user’s burden.

Natural language is an excellent intake format and a dangerous execution format. ‘Fix the dashboard’ carries intent, but it does not identify the repository, current branch, affected surface, user-visible defect, allowed changes, deployment target, or evidence of success. The front door should preserve the original request while translating it into a versioned request envelope that the rest of the system can inspect.

The envelope is the stable identity of the job. It links the conversation to task state, source material, worker runs, approval decisions, and final receipts. A follow-up such as ‘make it mobile too’ should amend that same job or deliberately create a dependent one; it should not vanish into a later chat turn with no relationship to the first run.

This is where conversational design becomes systems design. The interface can remain warm and natural, but every meaningful commitment becomes structured state. The user sees a coherent relationship while the system gains identifiers, schemas, timestamps, and deterministic transitions.

A front door does not imply one giant agent. Behind it, the system can use three different relationships. A manager keeps control and invokes specialists as tools. A handoff transfers control to a specialist that now speaks directly within the interaction. An agent-as-tool performs a bounded subtask and returns a result to the manager. These shapes have different failure modes and should be chosen intentionally.

Use a manager when one agent must preserve the user relationship, combine several outputs, or enforce a common policy. Use a handoff when the specialist needs an extended dialogue and the transition itself is meaningful to the user. Use an agent as a tool when the work has a crisp input and output, such as reviewing a diff, classifying a request, or preparing a source-backed brief.

The mistake is to confuse internal specialization with user-facing fragmentation. One front door can remain the manager of the relationship even when a coding worker repairs code, a research worker drafts a narrative, and a local operator runs a controlled machine task. The orchestration topology is an implementation decision; the front door is a product promise.

Chat history is useful evidence of what was said, but it is a poor database for what is currently true. It mixes requests, abandoned ideas, corrections, temporary observations, and final decisions in one chronological stream. If the system reconstructs state only by rereading chat, a minor ambiguity can change the task on every turn.

Instead, let conversation propose state transitions. The control layer records the accepted objective, current owner, approval status, blockers, decisions, and proof in structured records. The front door then renders those records conversationally. A sentence like ‘the site is live’ should be generated from a deployment receipt and a current public check—not from the fact that an earlier assistant said it deployed.

This separation also makes interfaces interchangeable. The same task can appear in chat, a dashboard, a mobile notification, or a command-line view without creating four versions of the truth. Each surface is a lens over the same request and event history.