AI-native CRM
The wider category word, and the distinction that decides it: built for agents from the schema up, or built for people and given a chat panel.
Read it →GET/v1/schema
An agentic CRM that keeps the receipts
Agents run the operational work and write what they did. The CRM holds the record, names who wrote each value and on what basis, and stops for a person at the points that matter. You bring the agents; this is the memory they share.
What an agentic CRM is
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 definition everyone uses
A CRM built to be operated by software rather than clicked through by a person. Agents read the data model, write records, open deals, claim work off a queue and close it with an outcome — through the same API the dashboard calls, under the same permissions.
What it means here
This one ships no model, no agent and no judgement. It is the workspace your agents share and the record they leave behind, built so that a person reading it a month later can tell what happened, who did it and what it was based on.
Agentic CRM against the CRM you have
The difference is not that one has AI in it. It is who the software expects to be holding the keyboard, and what it does when that turns out to be a machine.
Primary user
A CRM built for peopleA person in a browser. The API exists so other software can sync with what the people did.
Agent Native CRMSoftware. The dashboard is one client of the API, and there is no capability behind the screen that the API does not have.
Where a value comes from
A CRM built for peopleA field holds a value. Who set it and why is a note somebody may or may not have written.
Agent Native CRMEvery write carries a source and a confidence, and lands on an append-only timeline. The field is the latest value that timeline produced.
Changing the data model
A CRM built for peopleAn admin opens settings. An agent that needs a new field waits for a human to add it.
Agent Native CRMAn agent adds the field, the stage, the activity type or the whole object through the API. The change is logged with its diff.
Work between actors
A CRM built for peopleAssignment, plus a sequence engine that fires on rules somebody configured.
Agent Native CRMA task queue. Leave the assignee off and the first principal to claim it wins; everyone else gets a 409 and moves on.
Repeating a call
A CRM built for peopleA second import makes a second record, and somebody dedupes it later.
Agent Native CRMRecords upsert on a natural key. The same payload twice writes nothing the second time and answers created: false.
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.
The agent reads the workspace before it writes to it
One call returns every object, field, stage, activity type, status list and saved view this workspace has. Nothing is guessed: an unknown field is rejected and the error names the ones that exist, which is cheaper than a silently dropped write nobody notices for a week.
- GET /v1/schema
- GET /v1/me
It shapes the model to the work, and the change is on the record
A field added through the API is a real column and behaves like a standard one. So is a stage, an activity type, or an entire custom object with its own natural key. Every change emits a schema_changed activity carrying the diff and the principal who made it.
- POST /v1/schema/fields
- PUT /v1/schema/stages
- POST /v1/schema/activity-types
- POST /v1/schema/objects
It writes what it learned with the reason attached
A confidence here is the agent's judgement of its own source, not a score this product computed. That is the point of carrying it: a later reader — human or agent — has to be able to weigh the work rather than inherit it.
- POST /v1/companies
- PATCH /v1/people/{id}
- POST /v1/activities
Work moves between agents and people through one queue
A task with no assignee belongs to whoever claims it first, which is the whole scheduler: one conditional update, exactly one winner, a 409 already_claimed for the rest. Completing writes task_closed on the linked record with the outcome, so what happened has a time on it rather than a memory.
- POST /v1/tasks
- POST /v1/tasks/{id}/claim
- POST /v1/tasks/{id}/complete
- POST /v1/tasks/{id}/release
GET/v1/activities
Autonomy you cannot audit is not autonomy. It is just nobody watching.
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.
Agents propose, humans correct
An agent that thinks two records are the same says so with a note and leaves them alone. There is no merge route to call. A person decides, which keeps the one irreversible operation on this data in human hands.
Nothing is deleted
There is no destructive route on a record. Something that no longer applies gets a status and a reason, and stays readable — so a campaign does not pay twice for research that was already done and thrown away.
Contact refusal is enforced, not remembered
A record marked do_not_contact cannot be given a task on email, LinkedIn, WhatsApp or a call. The API answers 409 do_not_contact rather than trusting every agent that will ever touch this workspace to check first.
Review happens where the work is
A drafted message sits in the task queue as the message it is, with every follow-up chained behind it. Edit the payload, cancel the task, or leave it for the agent to claim. Doing nothing is a decision the system understands.
GET/v1/schema
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.
GET /v1/schema
- objects
- company, person, deal, task, list, principal, and any object an agent adds
- fields
- Every field on every object, with its type, and whether it is required
- pipelines
- Each pipeline and its ordered stages. A deal only moves inside its own
- activity_types
- The vocabulary the timeline accepts, including the ones agents registered
- status_lists
- Record, deal, task and list-member statuses, as this workspace defines them
- views
- The saved queries the dashboard renders, readable and writable through the API
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 supply the agents
There is no model here, no prompt library and no marketplace. The agents are yours, running wherever you run them, holding their own keys. This product is the shared memory and the task queue between them, and it makes no decisions of its own.
There is no rules engine
No triggers, no sequences, no cadences, no workflow builder. If something should happen after something else, an agent chains a task to it with parent_task_id. That is deliberate: a rules engine is a second place for behaviour to live and a second thing to debug.
Nothing is sent from here
This CRM has never delivered a message to anyone. Outreach is written into a task payload, reviewed, and executed by an agent using its own mailbox or account, which then closes the task with the outcome. Delivery is somebody else's job on purpose.
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 is an agentic CRM?
A CRM whose primary user is software rather than a person. Agents read the data model, write records and move work through it using the same API the dashboard uses, and every write records who made it and on what basis. The distinguishing feature is not that it contains AI — it is that the whole surface is reachable without a browser.
How is an agentic CRM different from a traditional CRM with AI features?
A traditional CRM adds an assistant beside a screen built for people, so anything the assistant cannot reach still needs somebody to click it. Here the API came first and the dashboard is one of its clients, which means there is no capability an agent has to ask a human to perform for it.
Does this CRM act autonomously?
No. It is a system of record, not an actor. Your agents act; this holds what they did. Approvals, corrections, merges and exceptions belong to a person, and several of them are enforced by the API rather than left to convention.
Can an agent change the data model?
Yes. Fields, stages, activity types and whole custom objects are all created through the API, and a field added that way is a real column that behaves like a standard one. Every change is logged as a schema_changed activity with its diff.
How do several agents work in the same workspace without colliding?
Records upsert on natural keys, so two agents writing the same company converge instead of duplicating. Tasks are claimed, and exactly one claim wins — the rest get 409 already_claimed and move on. Every activity is attributed to the principal that wrote it.
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.
Headless CRM
The architecture underneath. Why the API being the product is a different claim from having a good API.
Read it →Use cases
Three workflows run end to end, with every call named and every point a person steps in.
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.