How agents run

This page is for the reader who wants to know what is actually happening when an agent “is working”. It stays at concept level — enough to reason about safety, cost, and behaviour; nothing you would need to operate the machinery.

The shape

flowchart TB
  APP["WilsonOS app<br/>chat · Workbench · schedules"]
  BR["Agent bridge<br/>one always-on process per agent"]
  RT1["Runtime for conversation A<br/>own session · own home · own user"]
  RT2["Runtime for conversation B"]
  ENG["Model engine<br/>a swappable external harness"]
  GW["Gateways<br/>memory · media · providers"]
  APP --> BR
  BR --> RT1
  BR --> RT2
  RT1 --> ENG
  RT2 --> ENG
  RT1 --> GW
  RT2 --> GW

Each agent is an always-on process — a bridge the app talks to. When you send a message, the bridge routes it to a runtime for that conversation: its own model session, its own working directory, its own operating-system user, and its own short-lived credential. Two conversations with the same agent are two runtimes; a message in one is answered while work in the other continues, and stopping one leaves the other running.

Runtimes start lazily — nothing is spawned until a conversation’s first turn — and are put away when idle, keeping their session so the next message resumes where it left off. A small cap on concurrent runtimes protects the machine; if every slot is busy, the app holds your message and retries rather than dropping it.

Borrowed, bounded authority

A runtime works as you, for this conversation, in this brand — and no wider. Before a turn is queued the bridge checks that you own the private conversation or are a live participant of the room; if not, the turn is refused before anything runs. The runtime then sees:

• the brand’s documents it is allowed to read, and its own working area;
• a read-only copy of the shared toolkit (skills, flows, tools);
• not other people’s conversations, other brands, the owner’s private profile in a shared room, or any secret.

Provider keys — for image generation, publishing platforms, and the like — are never handed to a runtime. A runtime calls a gateway with its short-lived credential; the gateway checks the credential’s scope, injects the real key, makes the call, and logs it against the run in flight. The same is true of memory: every read and write carries the scope of the person and conversation, checked by trusted code rather than by a prompt instruction.

Why isolation per conversation and not per person

Two private conversations of one person, or a shared room running under one participant’s identity, must not be able to read each other’s transcripts and summaries. A per-person boundary cannot express that; a per-conversation boundary can. If isolation cannot be verified at startup, non-admin turns are refused rather than served “shared for now”.

The model is an engine, not the system

WilsonOS is deliberately a thin business control plane: it owns the brands, the records, the review path, the memory, and the guardrails, and treats the model runtime as a replaceable external harness. Today that harness is Claude and its coding-agent tooling; the runtime boundary is drawn so that a different engine could sit behind it without the brands, records, or memory changing. A model session is an execution detail, not a conversation’s identity.

Three ways a run starts

Trigger	What happens
Chat	Your message → the conversation’s runtime → the agent picks a skill or flow and runs it, streaming progress back
Schedule	A registered automation fires → a run record is written first → the work runs under a scoped credential → the result is delivered to a conversation you named
Terminal	An operator opens an interactive session with an agent’s identity loaded — for maintenance and platform work

All three boot the same context bundle and obey the same rules: announce the capability being used, quote and wait before spending, write memory through the sanctioned writers. See Schedules & triggers.

What “the agent went quiet” means

A turn stays open for as long as the agent is working — many minutes for a real deliverable. Output produced outside an open turn is discarded, which is why agents are required to finish synchronous work inside the turn and never hand a deliverable to a background helper that reports back later. The system treats silence as a defect to surface, not as calm: watchdogs check bridge health, and failed scheduled runs appear in the agent’s boot bundle for two days.

live Always-on bridges, per-conversation runtimes, the scoped credential and provider gateway, and the refusal rule are live; per-conversation operating-system isolation is deployed with live acceptance in progress. direction Per-tenant runtimes for a multi-customer launch are designed, not scheduled.

Related

Access & permissionsThe rules the runtime boundary enforces.

Schedules & triggersUnattended runs through the same path.

Session startWhat a runtime loads when it wakes.

Compared to other toolsWhy a thin control plane over a swappable engine.