Boring AI vs OpenAI's dots

OpenAI's admin guide puts it plainly: "A dot is a personal agent in ChatGPT with its own cloud computer." Everything about it is built around one person. It keeps notes on your preferences and decisions, carries the same memory across ChatGPT, Slack, and calls, and checks that you've allowed it before sharing something from a private conversation. It takes direction from you: in Slack, only the owner can direct a dot, and messages from other people do not start work. For a personal agent, that is the right design.

A company workflow has a different shape. The refund queue, vendor onboarding, and the Monday customer report each have several people who edit them, review what they did, and answer for the result, and the person who should approve a step is often not the person who set the work up. Boring puts agents in a workspace, with roles, private or workspace visibility, live co-editing, and one shared record per run. Every change to a definition is a versioned diff you can roll back.

Dots check before consequential actions, and the design is careful. An automatic review compares each action that could affect your accounts or share information against your instructions, permissions, custom rules, and built-in safety requirements, then lets it proceed, asks for your approval, or hands the step to you. Some steps you must do yourself; OpenAI's example is changing a password. When a request is waiting, you open it in Activity and respond.

Boring starts stricter and routes the decision. New agents start with every connected action waiting for approval; owners loosen that to writes only, or auto-approve eligible actions they trust, such as reads. Each request leads with the exact tool call and its scrubbed arguments and goes to the reviewer you assign. It can carry a due date with reminders, and an overdue outcome you configure: reject or skip. The reviewer can approve, reject, reassign, or modify the exact arguments before the call runs. OpenAI's public docs don't specify editing a dot's proposed action before approving it, or routing a request to anyone other than the owner.

OpenAI gives dots real hard boundaries. App permissions can allow a dot to read email without allowing it to send, and workspace admins can limit a connection to read-only actions or an approved set. On top of those sit custom rules, with four choices from "Take action without asking" to "Hand off to you". OpenAI describes them candidly: "They are instructions your dot tries to follow, and it can make mistakes."

Boring moves more of the policy into code. Exact-action grants decide what an agent can call at all, so a send action can be withheld entirely rather than prompted against. Numbered instructions run as an enforced plan: one step at a time, no skipping ahead, each step marked complete. A step can require evidence before the plan moves on, such as a saved artifact or a successful tool receipt for an exact target. The model still uses judgment inside a step; which actions it may call, and the order of the steps, are not left to it.

A dot starts from conversation, from saved schedules, and from event monitoring when a connected service supports it, including MCP Events from servers that publish them. That covers a great deal of personal work. A company's work also arrives as a webhook from another system, an email to a shared address, a form a customer submits, or an event in a SaaS app. Boring starts runs from all of those, plus schedules, the Chrome extension, the workspace API, MCP clients, and other agents. Beyond MCP Events, OpenAI's public docs don't specify a webhook URL, public form, API, or inbound email address that starts a dot.

When a Boring run breaks, its saved plan and progress stay, and eligible failed runs resume from the last completed step. In a numbered step plan, when a write's outcome is uncertain, Boring blocks automatic repetition instead of guessing. Provider throttling and outages are waited out within a bounded window; if the provider stays down, the run ends with its progress and a clear reason. Failure reasons are classified (billing, rate limit, context size, safety stop), with the provider's reference ID. A dot can be paused, resumed, and stopped, and OpenAI notes that stopping doesn't undo completed actions; retries and recovery from a failed step are not specified in its public docs.