Instinct AI: How It Works, How to Get Access, and What It Can't Do Yet

Instinct is an AI agent product founded by Noah Shinn. It got a lot of attention in the first week of October 2026 because of one feature: Instinct agents can now join group chats, and they work even when the other people in the chat have no Instinct account.

That is a short sentence with a lot packed into it. A personal agent that acts for one person, inside a conversation shared with several people who have not agreed to anything, is a harder design problem than a chatbot in a sidebar. Most of what is interesting about Instinct right now is how it handles that problem.

This post covers what is actually known about Instinct, how to get access, and what it cannot do yet. We are going to be blunt about the last part, because the gap matters: Instinct is a consumer product with no public developer API. If you want agent behaviour like this inside your own product, you build it. The second half of this post is about what that build actually involves.

What Instinct is, in plain terms

Instinct is a personal AI agent. You ask it to do things on your behalf and it goes and does them.

The company was valued at $10 billion as of its latest round. Reporting points to a $1 billion Series C at that valuation, dated September 28, 2026. We would treat those specific terms as reported rather than confirmed, because the coverage of the group chat launch does not restate them.

The reason Instinct is in the news now is the group chat feature, announced by Shinn on X on Monday, October 5, 2026, and reported by TechCrunch the same day.

Beyond that, a lot of the detail people want is simply not public. We cover the specific unknowns further down rather than guessing at them.

How the Instinct group chat feature works

This is the best documented part of the product, so it gets the most space here.

The headline behaviour: your Instinct agent can join a group chat and participate in it. The people in that chat do not need Instinct accounts of their own. That is a deliberate design choice and it is the thing that makes the feature spread, because the usual blocker for any shared agent feature is that everyone in the room has to sign up first.

The use cases given in the reporting are ordinary coordination tasks:

• Planning trips
• Getting event tickets
• Running fantasy leagues
• Organising carpools
• Coordinating who brings what to Thanksgiving

None of those are impressive as individual capabilities. What makes them hard is that each one involves acting for one person inside a conversation owned by several.

The consent and siloing model

Shinn described a privacy and control model with five parts. We are listing them separately because each one answers a different question a careful reader would ask.

A personal agent asks permission before connecting with the group's Instinct. There are two distinct agents here. Your personal agent, which knows your accounts and your context, and the group's Instinct, which lives in the chat. Your agent does not automatically plug into a group agent.

Users choose which groups to trust, and can revoke that trust at any time. Trust is per group, not global, and it is reversible. This matters because group chats drift. The people in a chat in March are not necessarily the people in it in November.

The group's Instinct is siloed from personal accounts and cannot access them. The group agent is not a window into your calendar or your inbox. It is a separate thing with its own boundary.

Personal agents ask permission before sharing information or taking action. Connecting to a group is one consent. Each act of sharing or doing is another.

When new members join, pending replies from a personal agent are held before being shared with the group. This is the detail we find most telling. It is a solution to a specific race condition: you asked your agent something, a new person joined before the answer landed, and now the answer would reach someone who was not in the room when you asked. Holding the reply is the conservative choice.

Taken together, that is a permission model, not a prompt. The difference matters, and we have written about why a prompt is not a policy for agents generally. Asking a model nicely to be careful is not the same as a system that cannot act without a check.

How to get access to Instinct today

As of the October 5 announcement, the rollout is staged:

1. Early access users first. The group chat feature went to early access users at launch.
2. Broader availability "soon". That is the word used in the announcement. No date was given.
3. The waitlist goes through your agent. Users can ask their Instinct agent to add them to the waitlist. That is the stated route, and it is a neat piece of product design: the signup flow is a sentence to the thing you already have.

If you do not already have an Instinct account, the reporting does not describe a separate signup path for the group chat waitlist. Assume you need the product first.

What Instinct can't do yet

Here is the honest accounting, because this is where most coverage stops short.

There is no public developer API. No published endpoints, no SDK, no documented way to build on Instinct. If you came here looking for one, that is the answer. We are not going to describe one that does not exist.

Group chats are early access only. Broader availability is promised but not dated.

Pricing is not public. We have seen no tiers, no free limits, no per-seat figures.

Rate limits are unknown. Which matters if you were hoping to lean on it for anything high volume.

Model details are not public. What runs underneath, whether it is a single model or a stack, is not described.

Platform availability specifics are unclear. Which messaging platforms the group chat feature reaches, and in what order, is not laid out in the reporting we have.

A few open questions a technical reader will have, which nobody has answered publicly:

• What happens to the group agent's context when the group is deleted, or when every member revokes trust?
• Is the held-reply behaviour on new member join time-bounded, or does the reply wait indefinitely?
• Can a group set rules for which actions its Instinct may take, or is control entirely per-user?
• When your agent buys event tickets in a group chat, whose payment method does it use, and who sees the confirmation?

We flag these because they are the questions you would have to answer yourself if you were building something similar. Which brings us to the rest of this post.

Instinct vs Meta Muse vs ChatGPT Dots

Three consumer agent products, three different shapes. The honest version of this table has a lot of unknowns in it.

Instinct and Muse both picked up phone calling in mid-September 2026, which suggests the category is converging on the same set of real-world actions. Group chats are the point of difference right now.

What you'd have to build to do this yourself

This is the part we can be concrete about.

Say you are not trying to compete with Instinct. You are building a product, and you want one piece of this: an agent that acts on a user's behalf, in a context shared with other people, where other people's requests can trigger actions against your user's accounts.

A booking tool where a client can ask the provider's agent to move an appointment. A team workspace where any member can ask the workspace agent to file something in the owner's tracker. A travel product where one person in a group plans and the others nudge.

The moment you write that down, four problems appear. Consumer products hide them. You cannot.

1. Per-user credentials that never reach the model

Your agent acts for Alice using Alice's Gmail, and for Bob using Bob's. The model generating the plan must never see either token, because anything in the context window can end up in a log, a trace, or an output.

This is the part most prototypes get wrong. The usual first version puts an API key in an environment variable and hands it to whatever makes the call. That works for one user and breaks the moment you have two, and it means the credential sits one prompt injection away from being quoted back.

With Swytchcode, credentials are never in your project. There is no .env file for them. Swytchcode keeps credentials in its own local store and reads them when a call runs. You connect a provider once, interactively:

npm install -g swytchcode
swy login
swy init --mode=sandbox
swy auth connect gmail
swy auth status

swy auth connect gmail opens a browser for the OAuth flow. An API-key provider prompts you to paste the key instead. Either way the credential lands in Swytchcode's store outside the project folder, not in your repo, not in your code, and not in an environment variable.

swy init is where the execution mode is decided. It writes .swytchcode/tooling.json with version, mode, integrations and tools. Mode is sandbox or production, it is set once, and your code never reads or sets it.

swy init asks which editor you are working in and which execution mode to use, then writes .swytchcode/tooling.json. Mode lives in that file, not in an environment variable, so there is no way for a prompt to talk your agent into switching to production.

You also decide which methods exist at all. Only methods you have explicitly allowed can run:

swy get gmail
swy add method gmail.user.drafts.create
swy add method gmail.user.send.create1

If a request, from your user or from somebody else in a shared chat, implies an action you never allowed, there is nothing to call. That is a smaller attack surface than a prompt that says "do not do anything destructive". Using your own OAuth app also keeps the consent screen and the revocation path under your control, which we go into in your API, your OAuth app, your rules.

Finding the right method is its own step, and it is worth doing before you write any execution code:

swy list methods and swy info let the agent look up the exact canonical method and its inputs before it executes anything. If you are not sure what a provider offers, swy discover "send an email" searches by description instead of making you guess an ID.

2. A permission model where some actions need a human

Instinct's model is consent at two levels: connecting to a group, and each share or action. You need the equivalent, and it cannot be advice in a system prompt.

Some actions are fine to run unattended. Reading a calendar. Drafting a reply. Others should stop and wait for a person: spending money, sending something irreversible, acting on a request that came from someone other than the account holder.

In Swytchcode that is a policy. The shape looks like this:

{
  "id": "big-refunds",
  "target": ["stripe.refund.create3"],
  "when": { "field": "amount", "operator": ">", "value": 50000 },
  "action": { "type": "REQUIRES_APPROVAL", "message": "Refunds over 500.00 need approval" },
  "approval_timeout": "2h"
}

target is the method the policy applies to, when is the condition, and REQUIRES_APPROVAL is what happens when it matches. Point target at whichever method matters for your product, for example gmail.user.send.create1, and condition on whichever input you care about. Run swy info <canonical_id> first so you are using that method's real field names rather than guessing.

The important property: the call does not run while approval is pending. The agent is blocked at the execution layer, not reminded at the prompt layer. We walk through the setup in how to set up policy guardrails for AI agents, and the approval flow itself in human in the loop approval for AI agents.

This is also where Instinct's held-reply-on-new-member behaviour maps onto something you can actually implement. A pending action that waits on a condition is a policy with a timeout, not a clever prompt.

3. Calls that cannot fire twice when retried

An agent in a group chat gets interrupted. The network drops. A model loop re-reads the conversation and decides the task is not done. Every one of those is a retry, and a retry on a non-idempotent call means two tickets bought, two emails sent, two carpool slots claimed.

Nobody notices this in a demo. Everybody notices it in production, usually because a customer got charged twice.

Swytchcode handles the retry itself. Each exec checks the method is allowed, runs policies, injects the credential, retries rate-limit errors with backoff, and returns parsed JSON:

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

const res = await exec("gmail.user.drafts.create", {
  body: { message: { raw: encoded } }
});

There is no retry loop in your code, no key handling, and no fetch. The retry logic lives in one place, where idempotency can be enforced consistently, instead of in whichever branch of agent code happened to need it. The full mechanics are in idempotency explained.

4. A log of what the agent did, and on whose behalf

When an agent acts for one person at the request of another, "what happened" is not a debugging nicety. It is the thing you will be asked for when something goes wrong, and the thing you need in order to answer a user who asks what their agent did last week.

Two commands:

swy audit network
swy audit policy

swy audit network is what ran. swy audit policy is what was blocked, and by which rule. The second one is the one people underestimate. A log of successful calls tells you what your agent did. A log of blocked calls tells you what it tried to do, which is how you find out that a shared chat has been talking your agent into something you did not design for.

Both together are the record that lets you say which call ran, against which account, under which policy. If you want the broader argument for why this belongs in a layer of its own rather than scattered through agent code, that is what an execution layer is and why AI agents need one.

Those four things are not features you add later. They are the shape of the problem. Instinct solved them for its own product and did not expose the solution. If you need the same behaviour, you are building that layer, and it is better to build it before the first duplicate charge than after.

If you are running an agent that should discover and call these methods for itself, point it at swytchcode.com/skills.md, which is the machine-readable version of the workflow above.

FAQ

Does Instinct have an API?

No public one. There is no documented developer API, no SDK and no published way to build on Instinct as of October 2026. If that changes, it will be announced. Anything you find claiming to document Instinct endpoints today is not coming from the company.

Who founded Instinct?

Noah Shinn. He announced the group chat feature on X on Monday, October 5, 2026.

How much is Instinct worth?

$10 billion as of its latest round. Reporting points to a $1 billion Series C at that valuation dated September 28, 2026, which we would treat as reported rather than confirmed.

Do other people in a group chat need Instinct accounts?

No. That is the specific thing that makes the feature notable. Your Instinct agent can join a group chat and work even when the other people in it have no Instinct account.

How do I join the Instinct group chat waitlist?

Ask your Instinct agent to add you to the waitlist. That is the route described at launch. The feature went to early access users first, with broader availability described as coming "soon" and no date given.

Can the group's agent see my personal accounts?

Per Shinn's description, no. The group's Instinct is siloed from personal accounts and cannot access them. Your personal agent asks permission before connecting with the group's Instinct, and again before sharing information or taking action.

Can I revoke a group's access later?

Yes. Users choose which groups to trust and can revoke that trust at any time, per the described model.

How much does Instinct cost?

Not public. No pricing, tiers or limits have been published.

How does Instinct compare to Meta Muse and ChatGPT Dots?

Instinct and Meta's Muse both added phone calling in mid-September 2026. Muse does not offer group chats yet, although Meta AI can be added to group chats on WhatsApp, Messenger, Instagram and Facebook. OpenAI launched ChatGPT Dots on September 29, 2026. Pricing and developer access for all three are either unpublished or unknown.

I want this behaviour in my own product. Where do I start?

Start with credentials and permissions, not with the model. Run swy init, connect the providers your agent needs with swy auth connect, allow only the methods you want with swy add method, and put a REQUIRES_APPROVAL policy on anything irreversible. The agent logic is the easy part. The layer underneath it is where the product either holds up or does not.

Wrap

Instinct is worth watching because of the consent model, not the capability list. Planning a trip and organising a carpool are not hard. Doing them for one person, inside a conversation several people share, without leaking that person's accounts into the room, is hard.

There is no public API, so you cannot build on it. What you can do is take the model seriously: per-group trust that can be revoked, an agent that asks before acting, a group context walled off from personal accounts, and replies held when the room changes. Those are design decisions worth copying.

The four things underneath them, per-user credentials, approval gates, idempotent calls and a per-user audit trail, are the parts that take real work. That is the layer we build.