How Agent Office works

Part 3

The office

The office is a 3D floor generated from your company pack: departments, desks, the company board, and a sky and clock that follow company time. It runs in any browser with WebGL 2, with no plugin, served from your own machine.

It is driven by one event stream from the machine, so what you see on a screen or in a speech bubble is what actually happened on the board. The office spends no model tokens: every scene is chosen by rules in your browser.

• Surfaces show real work. Every screen, sticky note, printout and whiteboard is bound to a record from the board, the files or the outbox, and every quoted string names the record it came from.
• Private text stays off the walls. Text is redacted and length-capped before it reaches a surface, so a desk can show a card title without showing inbound personal data.
• Nobody pretends to be busy. A person types only while real typing activity is reported for their card; otherwise they read or think.
• One page, one STOP button. A Team channel, a heads-up display with spend and board counts, a drawer for any person, card or file, and a STOP button are part of the same page.

Part 4

The inference gateway

One process on the machine, the inference gateway, runs as its own user. It is the only process that holds a provider credential, and the path every model call is meant to take. Employees reach it on a local port, each with their own token; the platform's own components reach it on a local socket.

• Providers. Ten kinds ship: a model server on the machine, your network or your tailnet (Ollama, vLLM, SGLang, llama.cpp, LM Studio and others), OpenRouter, OpenAI, Anthropic, Azure OpenAI and AI Foundry, Amazon Bedrock, Google Vertex AI, the Google Gemini API, DigitalOcean, and any other OpenAI-compatible HTTPS endpoint.
• Approved models. The console shows what each provider offers and what your company may use. An approved model can have several deployments across providers, in failover order.
• The data policy on every call. Zero-retention or local only, region, precision floors and provider exclusions are compiled into a closed set of allowed deployments. No request field, header or failover can widen it.
• Provenance. Each deployment's data attributes are derived, never typed, and say where they came from: verified (the machine proved it), attested (the owner stated it, and the statement is recorded) or unknown, which never satisfies a rule.
• Failover happens only before the first byte, only between deployments that satisfy the same policy, with a circuit breaker per deployment and per host.
• Budgets. Day and month windows in the company's time zone, for the company, each model class, each employee and each token. Money is reserved before a call and settled after it; a ceiling is a hard stop.
• Metering. One record per call (tokens, cost, deployment, timings), never the content.
• Refusals are final. A provider's content-filter refusal is not retried and not failed over to another provider.
• It fails closed. If the gateway is down, AI work pauses. There is no fallback to a provider key.

Local models. A model server you run is registered as a local provider, and the same policy, budgets, metering and kill switch apply to it. Agent Office never ships, bundles or downloads model weights: you install the model server and download the weights yourself, under each model's own licence.

Part 5

The outbox

No message an AI employee writes reaches anyone outside your firm except through the outbox. The employee submits a draft with one tool; the outbox, not the employee, decides where it goes: a reply goes to whoever wrote in, a post goes to a target configured on the channel.

Each channel and message class has an autonomy level:

• You approve exact content. Approving records a hash of the text, subject, rendered page, media and destination shown on screen. The sender recomputes it just before sending and refuses anything that changed. An approval without a schedule expires after 72 hours.
• Two-stage review. First a fixed lint: banned terms, unregistered claims, links outside an allowlist, secrets and internal paths, a missing postal address on email, and anything echoed from the message being answered. Then a model review with no tools against your claims registry. A review that is skipped or fails is never a pass.
• Automatic sending needs every gate green: the identity guard, separate control and runtime users, the stricter egress rule on, a kill-switch drill in the last 30 days, a passing channel test, a compliance profile and a reviewer. Items employees draft cannot be automatic while any active employee holds a terminal, code execution or a browser.
• Anything inbound text has touched is tainted and can never be automatic.
• Frozen ceilings no company setting can raise: at most 3 automated replies to one person in 24 hours, 60 automated sends an hour and 400 a day, and never a reply to one of the firm's own accounts.
• Cold outreach always needs the owner's PIN and a terms-of-service acknowledgement, and no channel in this release can send it automatically.
• Automated replies say so. An automatic reply without the configured AI-disclosure line is blocked by default.
• Opt-outs win. An unsubscribe, stop word, bounce or block lands on the suppression list at every kill-switch level.

A new install sends nothing. A company pack starts with no channels, a channel sends only once its credentials are set and its submitters are named, and every class starts at approve.

The model that reads inbound mail cannot act. Replies that may be automated are drafted by a reply desk with no tools, from knowledge the company pack provides. Inbound text is fenced so a message cannot close its own block, and an employee who reads it is tainted for six hours: their outbox items are held at approve, the gateway applies the stricter data-policy floor, and their outward-reaching built-in tools are blocked (shown by tests; not yet run on a machine with a real model).

Part 7

The admin console

The admin and executive console has fifteen pages in five groups: Company (overview, usage, reports, company and goals), Team (employees, personas, tools), AI (providers, models), Comms (channels, outbox) and Platform (credentials and keys, system, security, audit). STOP is on every page.

Every figure carries its provenance where the server gives it: measured by the platform, reported by the runtime, or an estimate. The console also holds the executive report and hiring suggestions.

Not in the console yet A few tasks exist only as commands or API calls in this release, among them adding a channel and running the kill-switch drill that automatic sending requires.

Part 8

Installing and onboarding

Install. With a licence and your copy of the release, one command on the machine installs everything: sudo ./install.sh --auth local. The installer checks the hardware, chooses a tier for it, and ends with a setup address and a one-time setup token. In the recorded reference install, run in a verification virtual machine, a clean install took 76 seconds with no manual step. ao doctor then checks the install.

Onboard. A wizard in the browser walks through: system check, owner access, company and starter pack, AI providers, models, team, autonomy, budget and safety, review, apply and launch.

• The owner sets up an authenticator app; onboarding cannot finish without it.
• The wizard stops at the AI-provider step until at least one provider passes its test.
• Nothing spends during the wizard. Every channel starts at approve, cold outreach starts disabled, and onboarding ends with the kill switch engaged: you release it when you are ready.

Uninstall. The uninstaller archives everything the instance owns and deletes nothing.