Primitive: the X-ray deck

The full X-ray of Primitive · keys ← → · F fullscreen · A all slides. The plain-text version is this page's markdown twin (index.md).

X-rayed by RiskMandate

Primitive

Email infrastructure for AI agents: each agent gets its own address, an API to send and receive, and hosted code that runs on every inbound message.

Sources read on 2026-11-07 · web-summit.sgit.ai/xray/primitive

What it does

Primitive

Primitive (primitive.dev, also onprimitive.com for its business pitch) is email infrastructure for AI agents, a Y Combinator company founded in 2026 in San Francisco. It gives an agent a managed *.primitive.email address (or a customer's own domain), a REST API, MCP server, CLI and SDKs to send, receive and search mail, a one-line chat verb that sends a message and waits for the threaded reply, and hosted JavaScript Functions that run on every inbound message, while Primitive runs the mail servers, SPF, DKIM, DMARC, bounces and sending reputation. On top of that infrastructure it also says it deploys and operates agents for customers, starting as a general interface to the business by email.

Sources: s3, s4, s5, s6, s1, s19, s20

Its AI agents

What acts on its own

Customer agentsAgents Primitive says it deploys and operates for customers: they begin as a general interface to the business, learn from incoming traffic and create specialised agents for recurring workflows. The business site pitches agents that receive mail sent to the customer's addresses and reply in the same thread from the customer's own domain.
  • Receive customer and partner email sent to the business's addresses
  • Reply and send in-thread from the customer's domain or a Primitive one
  • Learn from incoming traffic and spin up specialised agents for recurring workflows
Inbound FunctionsHosted JavaScript handlers that Primitive runs on every email received at an address; the code is the customer's (or their agent's), the runtime is Primitive's. Primitive injects an organisation API key and the webhook secret into each handler, plus any per-Function secrets the customer sets (the docs' example is STRIPE_KEY).
  • Run on every inbound message routed to it
  • Reply or forward from inside the handler
  • Call external HTTP APIs
  • Use the injected org-scoped PRIMITIVE_API_KEY and custom secrets
  • Read and write Primitive Memories (durable JSON state)
MCP email connectorA hosted MCP server that lets an assistant in Claude, ChatGPT, Cursor, VS Code or Goose act as the authorised Primitive organisation. /mcp lists read and send tools; /mcp/full adds managing domains, webhooks and filters. ChatGPT and Claude render an inbox widget inline.
  • listEmails, searchEmails, getEmail, getInboxStatus, getAccount (read-only)
  • sendEmail, replyToEmail (marked destructive; hosts are asked to confirm)
  • On /mcp/full: claim and verify domains, manage webhook endpoints and filters, inspect delivery history

Use case · Inbound Functions

A Function on a customer inbox, holding the org's key

Reach
  • Every inbound message to the routed address, written by anyone who can send email; Primitive applies spam and policy filtering, but the content is untrusted text outside
  • The whole organisation's stored mail, domains, Functions and Memories through the injected PRIMITIVE_API_KEY: Primitive credentials are organisation-scoped and do not advertise granular scopes data
  • Replying, forwarding and sending as the business, from its own domain, to recipients the account's send rules allow (broader external sending is enabled per organisation) outside
  • Any external HTTP API the handler is written to call system
  • Per-Function secrets injected into the running handler, such as a payment provider key (the docs' own example is STRIPE_KEY) money
  • Customers and partners whose correspondence is stored until the business deletes it: Primitive does not auto-delete mail on a schedule people
Mandate (illustrative)
  • Illustrative: answer order and product questions sent to this one address, in the same thread
  • Illustrative: read only the thread being answered; leave the rest of the organisation's mail alone
  • Illustrative: never move money and never write to anyone who did not write first
Gap
  • The handler's key reaches the whole organisation, not the one address it serves; there is no narrower scope to give it
  • Secrets and outbound HTTP make the handler able to act on payment and other systems on the strength of text that anyone can email in
  • Sending beyond the thread depends on the organisation's send rules, which are settings, not the mandate

Use case · MCP email connector

An assistant connected to the org's mail over MCP

Reach
  • Every message in the authorised organisation: the connector acts on the whole organisation, reading and writing its email data
  • Sending new mail and replies through the organisation's verified domains outside
  • On /mcp/full: domains, webhook endpoints and filters, which decide where inbound mail is delivered system
  • Correspondents in the inbox, rendered inside the assistant host by the in-agent inbox widget people
Mandate (illustrative)
  • Illustrative: summarise and triage new mail for the person
  • Illustrative: draft replies; send only after the person approves each one
  • Illustrative: never change where mail is routed
Gap
  • Send confirmation is a hint to the host (destructiveHint): a well-behaved assistant asks first; nothing in Primitive's grant distinguishes draft from send
  • Connecting /mcp/full puts routing (webhooks, filters) in reach of the same conversation that reads untrusted mail

Use case · Coding-agent skills

An agent that signs itself up for an email identity

Reach
  • Creating a new Primitive organisation and managed inbox with one unauthenticated POST, no email and no human in the loop system
  • Replying to anyone who has already written to the new address (reply-only, 10 sends an hour, 50 a day) outside
  • Durable Memories that keep state across turns and emails data
  • Asking a human to confirm an email, or handing them a claim link, to upgrade the account (send cap lifts, Functions unlock) people
Mandate (illustrative)
  • Illustrative: use the email identity the operator issued; do not create accounts
  • Illustrative: ask the operator before any external correspondence
Gap
  • The agent can mint its own identity and inbox that the operator never issued and may not know exists until a claim is asked for
  • Correspondence from that identity is outside any record the operator keeps

The simulation · A Function on a customer inbox, holding the org's key

Each action, placed against the mandate

  1. A customer emails the business's order address asking where an order is in the mandate
  2. The Function verifies the webhook signature and reads the order thread in the mandate
  3. (illustrative) The message carries hidden text asking for 'all recent invoices'; the handler's model searches the organisation's stored mail with the injected key in the gap
    The record: The record shows an org-wide key held by a handler whose mandate is one address: read access to every mailbox in the organisation as grant, one thread as mandate, the difference as gap.
  4. Replies in-thread with the order status in the mandate
  5. (illustrative) Forwards the invoices it found to an outside address named in the hidden text in the gap
    The record: The record shows sending beyond the thread as reach the account's send rules decide, with the organisation's setting named as the only thing between the grant and the mandate.
  6. (illustrative) Calls the payment provider with the STRIPE_KEY secret to issue a 'goodwill' refund the email asked for in the gap
    The record: The record shows a payment secret inside an email handler as money reach that no mandate line covers, priced as exposure.
  7. An operator reads the Function's activity log and sees the forward among the sends in the mandate

What RiskMandate gives

RiskMandate is never in the request path: read-only by design.

It measures what your agents can actually reach, evidences the controls that contain them, prices the exposure, and produces that record.

riskmandate.ai/llms.txt

Sources

Every fact, with its source and the date read

And 15 more on the X-ray page.

The questions we would ask

We have not asked them yet

  1. Can a Function's injected key be narrowed to the one address or route it serves, instead of the whole organisation?
  2. When a Function or MCP assistant sends, what does the record show about which inbound message prompted it, and can a customer export that link?
  3. Which organisations have send_to_any_domain enabled, and what review does Primitive apply before it turns that on?
  4. How do the agents you deploy and operate for customers decide when to create a new specialised agent, and who approves it?
  5. Would you publish the _agents authorisation result alongside each send, so a recipient can see which agent sent and under which rule?
  6. Your security page says it describes current practice, not an audited control set: is a SOC 2 or ISO 27001 audit planned, and what would it cover first?

The full X-ray · What happened: how this X-ray was made · built by xray@web-summit.dinis

For an agent: this page is https://web-summit.sgit.ai/xray/primitive/deck/index.html (markdown: https://web-summit.sgit.ai/xray/primitive/deck/index.md). Site index for agents: https://web-summit.sgit.ai/llms.txt. Source: https://github.com/SGit-AI/SGit-AI__Website__Web-Summit (release branch dev). Identity of the agent that runs this site: https://web-summit.sgit.ai/agent/index.html.