Every walk, meeting and alarm in Bot Office is generated from a real event. Nothing is invented.

The rule

1. No animation without an event. A bot walks, types, stamps, carries, phones, alarms or joins a meeting only because an event with that meaning arrived. An event name we don't know renders the labelled generic "working" animation — never an invented specific one.
2. Decoration is never counted. Blinking server lights and the sweep on the map screen are decoration (the chart and terminal screens show your real events). Bots do not move without an event: an idle bot sits still in the lounge. Decoration adds nothing to any counter and never appears as a meeting, a handoff or a fix.
3. Synthetic data is labelled. Wherever demo bots run on synthesized events — the landing page, the sandbox, a prospect demo — a DEMO · sample data marker is always visible in the office corner. Demo bots inside a real office carry the marker too.
4. Counters are sums of events. Runs, tasks done, handoffs, errors caught and minutes saved are computed from logged events with the assumptions shown; nothing is estimated upward.
5. The log is always one click away. Clicking a bot opens the raw events behind what you just watched: the schema fields, the timestamp, the animation chosen and the run it belongs to.

What the chip means

Every office shows one chip in the corner. It says what you are watching, and it is never blank.

LIVE

An event from your platform arrived in the last 60 seconds. What moves now is what happened now.

IDLE

No event for more than a minute. Bots sit; nothing is animated to fill the gap.

REPLAY

A meeting replay is playing: a finished run with three or more bots on one correlation id that did not meet live, re-enacted in the conference room from its logged events, in order.

DEMO

Synthetic data from our demo synthesizer. The bots, their names and every event are made up to show the product, and the office corner says so.

What we store

One event contract, and only its fields. Free text is limited to two short fields and scrubbed at ingest.

• agent_id, agent_name, event, status, tier, source (the platform)
• run_id and correlation_id, opaque ids that join events into a run; personal data inside an id is replaced by a keyed pseudonym
• task_title (80 characters) and message (140 characters), the speech-bubble text; emails, phone numbers, social security numbers and 13–19 digit numbers are removed before storage
• step_name, step_index, step_total, minutes_saved, cost_usd, count, severity
• approval_required, approved_by, to_agent_id
• timestamp from the sender, received_at and a sequence number from us
• meta with allow-listed keys only: platform, model, cost, tokens, tags, kind

Brand previews read one public homepage per URL, cache the result per host for 24 hours, and never log in to anything. Keys, bot URLs and approver keys are stored as hashes. If you let bots act in tools you connected, each action also gets a record: who asked, what for, who approved and what happened.

What we never store

• Conversation content, prompts, transcripts or model outputs
• Customer records, leads, invoices, tickets or any event payload beyond the schema fields above. If you connect your tools and let bots act, an action's own parameters (an SMS text, a contact's email) are kept in its audit record and sent to that tool; see the privacy policy
• Request bodies — anything outside the schema is dropped at the door, not kept "just in case"
• Screens, keystrokes or location of any person, ever
• Credentials you did not give us. The office holds credentials only for the connections and n8n/Make pull connectors you add, encrypted at rest, and never shows them again

When people appear in an office (today: a human in a roster; later: the workforce mirror), the three privacy rules apply: status, not content; zone, not dot; and worker-visible — every person can see exactly what is shown about them, and to whom.

How approvals, meetings and replays are labelled

Approvals

A waiting event with approval_required walks the bot to the lead's office, where it waits with a "?" bubble. It stays there until a real approved or rejected event arrives from your platform. The office never resolves an approval on its own, and the approver's name appears only if your event carried approved_by.

When a bot asks to act in a tool you connected, the same walk happens on action_requested. The decision comes from a named person in Mission Control or on the connections page, never from the office, and the record keeps who decided and when.

Meetings and replays

When three or more bots send events on the same task (the same correlation_id, or runs joined by a handoff) within two minutes, or a bot sends meeting_started, they walk to the conference room and sit. Up to eight sit at the table and the rest stand. Their reports show as bubbles in order, and the wall screen shows the task. The meeting ends when the task finishes, on meeting_ended, or after two minutes with no event on it. In a live office the chip stays LIVE.

A finished run with three or more bots that did not meet live is replayed in the conference room under the REPLAY chip. A meeting or a replay adds nothing to any counter.

Escalations and failures

handoff and escalated make the bot carry a folder to the lead's office for the next bot to pick up. run_failed stops the bot at its desk with a red "!" and turns its monitor red. The failure stays shown until a real retry or run_finished event arrives. The client sees the failure, not a fix that hasn't happened.

Bursts and budgets

An event with a count shows the number on its bubble (×N). Each bot shows at most one bubble every two seconds; identical events in a row collapse into one with a count rather than being dropped or invented.

How to report a violation

If you see an animation, a number or a label in any Bot Office that this page does not justify — a meeting with no run behind it, a counter that moved without an event, a demo without its DEMO marker — tell us.

• Email honesty@aibotoffice.ai with the office link, the time you saw it and what you saw.
• We reply to every report, and we fix the rule or the code — never the wording — when the report is right.
• Material fixes are listed on this page with a date, so the standard carries its own history.

This standard is published so it can be held against us, and so any vendor that adds sprites to a dashboard can be asked whether it meets the same rule.