OpenAI Dots vs Instinct: Two Ways to Build a Personal Agent

Within about a week, two companies shipped an agent that acts on your behalf while you are not watching, and they made almost opposite design choices about what that means.

OpenAI's Dots arrived at DevDay around September 29, 2026. A Dot is a persistent agent that keeps working after you close the chat, gets its own cloud computer and browser, and lives inside your workspace alongside your colleagues. Instinct, on October 5, announced that its personal agents can join group chats, and that they work even when the other people in the chat have no Instinct account at all.

The interesting part is not which is better. It is that both teams ran into the same wall and built the same kind of thing to get past it: a permission layer that sits outside the model and decides what the agent is allowed to do. OpenAI calls it Custom Rules. Instinct frames it as consent. Neither of them trusted the model to be the thing that decides.

That convergence is the subject of this post, because it is the part that generalises to anything you might build. We covered Instinct on its own in the Instinct AI guide; this is the comparison.

Side by side

What a Dot actually is

The framing OpenAI uses is "a new kind of persistent AI agent," and persistence is the load-bearing word. A Dot does not stop when the conversation does. It monitors projects, uses software, reacts to information that changed while you were asleep, and comes back with finished work for you to approve.

The examples in the launch coverage are telling: a developer's Dot building and testing a fix and returning a pull request; a sales Dot keeping a proposal current as the deal moves. Both are jobs with a long tail of small updates, which is exactly the work that does not survive contact with a human's attention span.

Each Dot gets its own cloud computer and browser, which is a bigger architectural statement than it sounds. It means the agent is not borrowing your session or your machine. It has its own environment, and the question of what it can reach becomes a question about that environment rather than about your laptop.

Three mechanisms handle oversight.

Background work is read-only. OpenAI's proactive research mode uses tools that, per the launch coverage, cannot send messages, modify content, or control your computer or browser. The agent can look while you are away. It cannot touch.

Custom Rules let you mark actions as allowed, requiring approval, or blocked outright.

An auto-review system sits over consequential actions, with an Activity View where you can go and read what the thing has been doing.

Availability is generous for a launch: the first Dot costs nothing extra on Pro and Business Premium, and Enterprise, Edu and Healthcare customers can try the beta once an administrator turns it on. What OpenAI has not disclosed is the usage allowance for heavy work, what additional Dots cost, or what the specialist Dots currently in enterprise pilots will be priced at.

There is also a shared layer called ChatGPT Space, where people, ChatGPT, Codex and Dots all work from the same context. It replaces the Library for Pro, Business and Enterprise users, holds pages and files and spreadsheets, and can keep pages synced with connected tools. Workspace sharing rules still apply, which is the quiet admission that an agent inside a company is subject to the same access control as a person.

One thing worth noting from the same week: OpenAI said it would not ship GPT-6.1 Astra after safety issues surfaced in internal testing. The coverage does not say how that bears on Dots, which run on GPT-6 Astra, so we are not going to speculate. It is context, not a conclusion.

What Instinct does differently

Instinct's agents represent a person rather than staffing a workspace, and the October 5 announcement is about what happens when two of those meet.

An Instinct agent can join a group chat. If other people in that chat have their own Instinct agents, the agents can coordinate. If they do not have Instinct at all, it still works, which is the detail that makes this a product rather than a demo: adoption does not require everyone in the thread to sign up.

The consent model is the part worth studying. A personal agent asks permission before connecting to a group's Instinct. Trust granted can be revoked at any time. And the group agent is siloed from personal accounts, so letting your agent participate in a group is not the same as letting the group reach into your calendar and your mail.

Those three properties describe a design where the boundary is between people, not between a person and a company. That is a different problem from the one Dots solves, and it produces a different answer.

The axis that actually separates them

Everything else follows from one question: who does the agent belong to?

A Dot belongs to a workspace. It collaborates with colleagues and with other AI in a shared Space, it inherits your organisation's sharing rules, and an administrator can turn it on or off. The natural trust question is "what is this agent allowed to do inside our company," and the natural answer is role-based: Custom Rules, approval gates, an audit view, governance through Microsoft Agent 365 for the specialist versions.

An Instinct agent belongs to you. It goes into rooms containing people who have no relationship with your employer and possibly no relationship with Instinct. The natural trust question is "what is this agent allowed to reveal to, or accept from, someone else's agent," and the natural answer is consent: ask before connecting, revoke whenever, keep the shared context away from the personal account.

Neither answer is portable to the other problem. Role-based access control does not help when the counterparty is a stranger's agent in a group chat. Pairwise consent does not help when the question is whether the sales Dot may email a customer.

Which is why we think the convergence matters more than the divergence.

Both built a permission layer, and that is the finding

Two teams, different problems, different company sizes, different distribution. Both concluded that the model cannot be the thing that decides what the agent may do, and both built a separate layer for it.

OpenAI's version is explicit to the point of being a feature list: allow, require approval, block. Read-only tools in the background. Auto-review for consequential actions. Instinct's version is a consent protocol with revocation and a silo.

Neither shipped "we prompt the model very carefully not to do bad things."

This is the thing we would want anyone building an agent to take from the two launches, and it is also, frankly, our whole argument. We wrote it up as a prompt is not a policy before either product existed, and the reasoning is simple: a prompt is a request, and a request is not an enforcement mechanism. If the consequence of an action is a refund going out or a message reaching a customer, the thing that permits it has to live somewhere the model cannot talk its way past.

Both products also landed on approval as a first-class state rather than a binary. Not "allowed" or "forbidden" but "allowed, blocked, or ask me." That middle state is where almost all of the interesting behaviour lives, and it is the same shape as the three-band confidence gate we keep recommending: act on the clear cases, escalate the middle, decline the rest. Confidence thresholds covers picking the bands, and human-in-the-loop approval covers wiring the middle one up.

What neither of them gives you

Here is the part that matters if you are reading this as a builder rather than a buyer.

Neither Dots nor Instinct publishes a developer API for letting an agent call your own internal systems.

Dots integrates through a plugin ecosystem of more than 4,000 applications, through connected apps managed in ChatGPT's settings, through its browser, and optionally through a direct connection to a device. Those are all routes to software that already exists and has already been integrated. None of the launch material describes a way to hand a Dot your own internal endpoint and have it call that. DevDay did include computer use in the Agents API and expanded plugins, but the coverage does not say either lets you extend Dots with your own tools.

Instinct publishes no developer surface at all that we can find, nor pricing.

So if what you want is the behaviour, inside your own product, for your own users, calling your own APIs, you cannot buy it from either of them today. You build it.

What you would have to build

The four things both vendors had to solve, which are also the four things people underestimate.

Per-user credentials the model never sees. An agent acting for Priya must use Priya's access, not a service account with everyone's. The model should never hold a token, because anything in the context window can leak into an output.

swy auth connect gmail    # per user, OAuth in a browser
swy auth status

Credentials land in Swytchcode's own local store at ~/.swytchcode/credentials.db, outside the project, and are injected when a call runs. There is no .env file and your handler never reads a key. Execution mode is answered once at swy init and lives in .swytchcode/tooling.json. The authentication docs cover both flows, and for the multi-tenant case the runtime exposes a Swytchcode class that takes a tenantId.

swy init asks for the execution mode once and writes it into .swytchcode/tooling.json, so sandbox versus production is never an environment variable the model could see.

Approval gates on consequential actions. This is Dots' Custom Rules and Instinct's consent, and it belongs outside your application logic so that a refactor cannot remove it:

{
  "id": "customer-facing-mail",
  "target": ["gmail.user.send.create1"],
  "when": { "field": "to", "operator": "not_in_domain", "value": "yourcompany.com" },
  "action": { "type": "REQUIRES_APPROVAL", "message": "Mail to an external address needs a human" },
  "approval_timeout": "4h"
}

swy policy add
swy audit policy

Note the shape matches what both products shipped: allow by default, require approval for the consequential subset, deny what should never happen. How to set up policy guardrails covers the rule syntax.

Idempotent execution. An agent that works while you are asleep will hit a timeout, and something will retry. The retry must not send the message twice. This is configured per integration rather than written into your handler:

{
  "execution_policy": {
    "idempotency": { "mode": "dynamic", "header_name": "Idempotency-Key" }
  }
}

Each exec call gets its own key and reuses it across that execution's own retries, so two deliberate actions stay two actions. Idempotency explained has the failure modes.

A per-user audit trail. Dots has an Activity View for exactly this reason. "What did the agent do for this user, and why" is a question you will be asked, by a user, by a colleague, and eventually by someone in compliance.

swy audit network   # what actually ran
swy audit policy    # what was blocked or escalated

An agent discovering a method and checking its inputs before running it. Only methods explicitly added to the project can execute, which is the floor underneath any policy you write.

Putting it together, the shape of a background agent that acts for a specific person:

import { exec } from "@swytchcode/runtime";

export async function actFor(user, decision) {
  if (decision.action !== "send") return { skipped: decision.reason };

  // credentials for this user, injected at call time, never in the model's context
  return await exec("gmail.user.drafts.create", {
    params: { userId: user.email },
    body: { message: { raw: encode(decision.draft) } }
  });
}

The decision of whether to send can come from wherever you like, including a decision model such as Jev, which is live at swytchcode.com/apis/jev. The point is that the permission to send does not come from the model at all. That separation is what both OpenAI and Instinct arrived at independently, and the model decides, the call layer executes is our longer version of the argument.

Things we got wrong

We assumed Dots would ship with a developer API. It is an OpenAI launch at DevDay, so we went looking for the endpoint. There is not one, at least not for extending a Dot with your own internal tools. The integration story is plugins, connected apps and the browser. We had planned a whole post about wiring Dots to your own APIs and had to abandon it, because the premise was not real.

We read the 4,000 app plugin ecosystem as developer extensibility. It is not the same thing. Connecting to software that already has an integration is different from handing the agent your own endpoint, and conflating them is how you end up promising something you cannot deliver.

We described both products as competitors. They barely overlap. One is a coworker inside a company, the other is a representative in a group chat with strangers. The interesting comparison is not market overlap, it is the fact that they independently built the same permission machinery.

We treated read-only background mode as a limitation. It reads like a restriction in a feature list and it is better understood as a design principle: the agent may observe unattended and may only act when someone is accountable. We would now recommend building that split deliberately rather than treating it as a constraint to work around.

FAQ

What is OpenAI Dots?

A persistent AI agent announced at DevDay 2026, around September 29. Dots keep working after you close the chat, run on GPT-6 Astra, and each gets its own cloud computer and browser. They monitor projects, use software, and return finished work for approval through ChatGPT, Slack and Microsoft Teams.

How is Instinct different from Dots?

Ownership. A Dot belongs to a workspace and behaves like a coworker subject to your organisation's rules. An Instinct agent represents one person and can join group chats, including with people who have no Instinct account, coordinating with other people's agents under a revocable consent model.

Is there a developer API for Dots?

Not a published one for letting a Dot call your own internal systems. Integration happens through the plugin ecosystem of more than 4,000 apps, connected apps, the agent's browser, and optionally a direct device connection. DevDay also announced computer use in the Agents API, but that is not documented as a way to extend Dots with your own tools.

Is there a developer API for Instinct?

None that is published, and no published pricing either.

What does Dots cost?

The first Dot is included at no additional charge for Pro and Business Premium. Enterprise, Edu and Healthcare customers can try the beta once an administrator enables it. OpenAI has not disclosed usage allowances for heavy work, the cost of additional Dots, or pricing for the specialist Dots currently in enterprise pilots.

What is ChatGPT Space?

A shared layer where employees, ChatGPT, Codex and Dots work from the same context. It replaces the Library for Pro, Business and Enterprise users and holds pages, files, presentations and spreadsheets, with pages able to stay synced to connected tools. Collaborative slides and spreadsheets were described as coming later.

How do Dots handle safety?

Three mechanisms. Background proactive research uses read-only tools that cannot send messages, modify content, or control your computer or browser. Custom Rules let you allow, require approval for, or block actions. An auto-review system covers consequential actions, with an Activity View for inspecting what happened.

Which should I use?

If you want an agent working on company projects alongside colleagues, Dots is built for that and is already available on Pro and Business Premium. If you want an agent representing you in conversations with other people, that is Instinct's design. If you want either behaviour inside your own product for your own users, neither is an option yet.

Can I build this myself?

Yes, and the four pieces are per-user credentials the model never sees, approval gates on consequential actions, idempotent execution so retries do not duplicate, and a per-user audit trail. Those are the same four things both vendors had to build.

Why did both products build a permission layer instead of just prompting carefully?

Because a prompt is a request, not an enforcement mechanism. When an action spends money or reaches a customer, the permission to take it has to live somewhere the model cannot argue with. Both teams reached that conclusion independently, which is reasonably strong evidence.

Wrapping up

Dots and Instinct answer different questions. One asks what an agent may do inside a company; the other asks what two strangers' agents may share. The answers look nothing alike, and both are defensible.

What they have in common is the thing worth copying. Both put the decision about what the agent may do somewhere other than the model, both made "ask a human" a first-class outcome rather than a failure, and both built a surface where a person can go and see what happened while they were not looking.

Neither will let you build on it today. So if you want a personal agent inside your own product, you are building the permission layer yourself, and the good news is that the two best-funded attempts at this problem have just shown you roughly what shape it should be.

npx swytchcode installs the CLI, and swytchcode.com/skills.md is the agent-readable setup file you can hand to a coding agent so it wires the project up correctly instead of guessing.