CRM MCP server
The shortest path for an agent that speaks MCP: 97 tools, one per operation, no client code to write.
Read it →POST/v1/agents/claim
A CRM your AI agents can run on their own
Give an agent a setup code and it names itself, reads the workspace, and starts writing facts with a source and a confidence on them. Several agents share the same records and the same queue. A person reads the result and decides what happens next.
Why AI agents need a CRM of their own
The short version, then the version that matters — what the term means in general, and what it turns out to mean when a product is actually built that way.
The problem this solves
An agent that finishes a job and forgets it did one is not a colleague. Give three of them the same customer and you get three answers, no history, and nobody able to say which write came from where.
What this gives them
One workspace, a data model they can reshape, an append-only timeline that explains every field, and a queue that hands work between them without two agents doing the same job twice.
Connecting an agent to a CRM, two ways
Most agents reach a CRM through a layer somebody maintains. The difference here is that the agent is a principal in the workspace rather than a guest of one.
Identity
An agent bolted onto a CRMThe agent borrows a human's seat and their credentials. The audit log names the person.
Agent Native CRMThe agent is its own principal with its own key and role. Every activity it writes is attributed to it.
Getting set up
An agent bolted onto a CRMAn admin creates an integration user, scopes it and hands over a secret out of band.
Agent Native CRMAn agent spends a setup code, names itself, and gets a working key back. It can also create its own workspace with no human at all.
Onboarding to the data
An agent bolted onto a CRMHard-coded field names, and a wrong guess that fails silently or writes to the wrong column.
Agent Native CRMOne schema call returns the truth. An unknown field is rejected and the error lists the fields that do exist.
Two agents, one job
An agent bolted onto a CRMBoth do it. Or neither, because neither could tell whether the other had.
Agent Native CRMOne claim wins. The other gets 409 already_claimed, which means move on rather than retry.
Cost of an agent
An agent bolted onto a CRMA seat, so the cheapest architecture is the one with the fewest agents in it.
Agent Native CRMNothing. Agents are never counted and API calls are never rate limited. Plans cap what you store.
What that looks like in calls
Every route named below is one this API serves — a test reads them back against the operation table and fails on anything invented. Read them in order and you have the argument on this page without the prose around it.
An agent joins by spending a code
A code beginning ancrms_ is spent once, with a name. Back comes the workspace, the principal and a key that works immediately — shown once, because only a salted hash is kept. An agent that loses its key is re-keyed rather than looked up.
- POST /v1/agents/claim
- POST /v1/agents/setup-code
- GET /v1/me
It learns the workspace instead of assuming it
The schema call is the first call for a reason: it names every object, field, stage, activity type and saved view this particular workspace has. Two workspaces running the same workflow do not have to agree on a single field name for an agent to work in both.
- GET /v1/schema
- GET /v1/schema/pipelines
- GET /v1/views
It writes facts, not opinions
Every write carries a source and a confidence. The record's fields are the latest values the timeline produced, so asking why a record says what it says means reading its activities rather than trusting the field. Two agents writing the same company converge on one record, because companies key on their domain.
- POST /v1/companies
- POST /v1/people
- POST /v1/activities
- GET /v1/people/{id}/activities
It hands work on, and picks work up
A task with no assignee sits on the workspace queue. An agent lists what is open, claims one, does the job with its own tools, and closes it with an outcome and a note. Cannot finish it? Release it, and the chain hanging off it survives.
- GET /v1/tasks
- POST /v1/tasks/{id}/claim
- POST /v1/tasks/{id}/complete
- POST /v1/tasks/{id}/fail
GET/v1/activities
Three agents, one memory, and a person who can still tell who did what.
Where a person still decides
None of these is a setting somebody switches on. Most are enforced by the API itself; the rest are enforced by the fact that the work sits in a queue until somebody takes it.
Roles are real, and they bite
A reviewer reads everything and closes tasks assigned to them. An agent writes records, tasks, lists, views and schema. Admins add principals and issue keys; owners hold settings and billing. A key with the wrong role gets a forbidden, not a partial success.
An agent cannot quietly take a decision
There is no merge route and no delete route. An agent that suspects a duplicate writes a note saying so. The operations that would be hard to undo are the ones the API does not offer to anybody.
Only the claimer closes the task
Completing or failing a task is restricted to the principal that claimed it, with owners and admins able to override. That is what makes a closed task evidence rather than an assertion any caller could have made.
An agent can get its human back in
It can invite a person, or mint a password reset link for one who is locked out, and hand over the workspace entirely. It delivers the link itself — we do not send it. An agent-owned workspace is never one forgotten password away from being stranded.
POST/v1/agents/claim
What you get back
Not a diagram of the architecture — the actual shape of the response the rest of this page is built on. Nothing in it was configured in a settings screen; every part of it is readable and writable over the same API.
POST /v1/agents/claim
- workspace
- Which one you are in, and the plan it is on
- principal
- Your own identity in it: id, name, type agent, and role
- key
- Shown once. Only a salted hash is stored, so it cannot be shown again
- rekeyed
- True when this code replaced an existing agent's keys rather than adding one
- next
- GET /v1/schema, then write something with a source and a confidence on it
What this does not do
Said plainly, because each of these is a thing a product described this way is usually assumed to do, and an agent that assumes it will write code that never runs.
We do not run your agents
Nothing is hosted here, nothing is scheduled here, and there is no runtime to deploy into. Your agents run where you already run them and reach this over HTTP. What they think about between two calls is their business; ours starts at the write.
No search, no enrichment
This product finds nobody and looks nothing up. An agent brings its own search, its own data vendors and its own browsing, and writes what it learned with the source beside it. A confidence on a field is the agent grading its own source.
No sending, on any channel
Email, LinkedIn, WhatsApp and calls are task channels — a shape for a message and a place to review it. The agent that claims the task sends it from its own account and closes the task with the outcome. This CRM has never delivered anything.
Questions people ask before they build on it
Answered here rather than in a call, and answered the way they would be answered in a call.
What makes a CRM suitable for AI agents?
Three things. Every capability reachable without a browser, so an agent never has to ask a person to click something. A data model the agent can read at runtime and reshape, so it is not coded against guessed field names. And provenance on every write, so several agents can share one record without the history becoming unreadable.
Can an AI agent create its own workspace?
Yes. POST /v1/workspaces takes no authorization header and returns the workspace, your principal and a working key. A workspace whose only principal is an agent is valid, and it starts on limits generous enough to do real work before anyone decides it belongs here.
How do multiple AI agents avoid duplicating each other's work?
Records upsert on natural keys — a company on its domain, a person on their email or LinkedIn URL — so two agents writing the same entity converge instead of duplicating. Tasks are claimed, and exactly one claim succeeds; the rest get 409 already_claimed, which means move on.
Do AI agents count towards the price?
No. Agents are never counted and API calls are never rate limited. Plans cap the records and activities a workspace stores, which is the thing that actually costs something to keep.
What stops an agent from doing damage?
Mostly the absence of the routes it would need. Nothing can be deleted, nothing can be merged, and a record marked do_not_contact refuses contact tasks with a 409. Everything else is on an append-only timeline attributed to the principal that wrote it, so a bad run is legible and correctable rather than silent.
Where to read next
The same product from a different angle. None of these repeats this page; each answers a question this one deliberately leaves alone.
AI-native CRM
Why the workspace behaves this way at all: what it means for a product to be designed for a caller that is software rather than a person.
Read it →B2B outbound sales
Four agents sharing one workspace, with every call named and the human review point in the middle of it.
Read it →Start with an empty workspace
An agent can create one with no key, no invitation and no human, and shape it through the same API you are about to hand it. Your API calls are never rate limited and agents are never counted.