Which Onboarding Fits?
When you sign up for Primitive, you pick one of two paths:
- My Product Should Chat With Agents — you have a product and you want agents to be able to reach it over email.
- My Agents Want To Chat With The World — you are building an agent that needs its own email inbox to send and receive.
The infrastructure is the same underneath. The onboarding flows are different because the thing you are setting up first is different. Pick the path that matches the task you have in front of you. You can always do the other later from the dashboard.
My Product Should Chat With Agents
Pick this if you own a product and want it to be reachable by any agent over email.
You are this user if you say things like:
- "I run a SaaS and I want Claude or ChatGPT to be able to check order status by emailing my product."
- "I want to expose a few of my product's capabilities (lookups, scheduling, refunds) as actions an agent can take by sending a message."
- "I have a CRM / helpdesk / internal tool and I want agents to log activity or fetch data by emailing it."
- "I want my product to participate in agent-driven workflows without forcing my customers to integrate an MCP server."
The onboarding for this path explains how Functions work with a worked example — an inbound email triggers your code, which can parse it, call your own APIs or an LLM, and send a reply — then hands a prompt to your coding agent (Claude Code, Cursor, or Codex) to scaffold and deploy your first Function. There is nothing to deploy by hand and no key to copy: PRIMITIVE_API_KEY is injected into every Function automatically.
My Agents Want To Chat With The World
Pick this if you are the developer of an agent and the agent itself needs an email address.
You are this user if you say things like:
- "My autonomous agent needs to send transactional or follow-up email on behalf of users."
- "I want my agent to have an inbox other people can email it at, with the messages delivered to my code."
- "I am wiring email send and receive into a Claude / Cursor / custom-agent loop and I just need a working programmatic surface."
- "I want a CLI my agent can shell out to, or an SDK my agent can import, with no infrastructure to deploy."
The onboarding for this path provisions an inbox immediately and leads with one-click handoffs to Claude Code, Cursor, and Codex — your coding agent installs the CLI, signs in as you, and wires send + receive into your codebase. A live inbox panel displays incoming mail as it arrives, and a "Do it manually" section has the raw install + login + send commands if you would rather drive it yourself.
Can I Do Both?
Yes. They share the same primitives — a managed domain, an API key, the same send and receive pipeline. Once you finish either onboarding flow, the other is available from the dashboard.
The recommended sequence:
- Start with whichever maps to your immediate task. Don't pick the "bigger" one to be safe; the irrelevant one wastes your first session.
- Add the second when you actually need it. A product team often grows into needing their own internal agents; an agent developer often grows into wanting their agent to be reachable by other agents. Both transitions happen later, not on day one.
Still Not Sure?
If you are a developer evaluating the platform with no specific product in mind, take My Agents Want To Chat With The World. It is faster (the inbox is live in under a minute), the live inbox panel gives you something tangible to watch as real mail arrives, and the infrastructure you set up here is the same infrastructure the product-side flow uses later.
If you are evaluating Primitive on behalf of a business or product team, take My Product Should Chat With Agents. The Functions example makes the inbound-email-triggers-your-code model concrete, and the handoff prompt at the end is designed to drop into a coding agent and produce a working first Function without you writing it line by line.
If you are not a developer at all, take My Product Should Chat With Agents and pass the handoff prompt to your engineering team.