Who it is for
Some people read one line about Indraft and know. Everybody else is already living the problem it solves and has not filed it under "CRM" yet. This page is for both of you.
If you already know
It drafts your follow-ups, it reads your inbox, it knows more about last week than your CRM does. The one place it cannot reach is the system of record, so you keep being the integration between them.
Indraft is a CRM your agent operates directly: every object, every write, every read, through the same tools a person uses. Not an integration bolted to the side of one, which is why the whole product can assume a machine is doing most of the writing.
If you do not know it yet
None of these sound like a CRM problem, which is exactly why they have gone unfixed. They are all the same problem.
Where did it look? Not your CRM, because it cannot get in. It read your inbox, or your notes, or it guessed. The answer was decent and nothing about it got written down anywhere the rest of the company can see.
Candidates, campaigns, units, matters, shipments. Whatever your business is actually about, no CRM has a place for it, so it sits in a sheet that nobody links and everybody edits.
Not their whole job, but an hour a week that produces nothing and stops the moment they are busy. The data decays from that day and the reports keep coming out anyway.
Somebody enriched this account, or an integration did, or a colleague did in a hurry. You cannot tell which, so you check it yourself before you use it, every time.
Each of those is a record that should exist and does not, or one that exists and cannot be trusted. That is the whole subject: not storing customer data, which every CRM does, but keeping it true while something other than a person is writing it.
What changes
The reason CRM data rots is that keeping it correct is a chore assigned to the people with the least time. Give that job to the thing that does not mind doing it, and the question stops being whether anybody updated the record and becomes whether you can trust what they wrote.
Which is why the interesting half of this product is not the writing. It is that every value carries how it was come by, every change can be undone, and identity is never guessed. An agent that writes a thousand records a day is only useful if you can still believe the thousandth.
The cookbook is the honest version of this: real jobs, run against the real product, including what it refuses to do.
The human side
Your agent writes through the API and the tool set. You read, correct, and undo here. These are captures of the running application, not drawings: the same pages the product serves, rendered by the same code.
The one that matters most is the first. Every change carries who made it, whether they observed it or inferred it, which surface it came through, and an Undo where the change can be safely compensated. That is the difference between a CRM an agent writes to and a CRM you can still trust afterwards.
Next
The free plan is enough. Connect the agent you already run, point it at whatever list you already have, and judge the CRM it builds in twenty minutes.
If your agent runs on Claude, the connection path is the shortest one. If you are wiring your own service, start with the REST API or the MCP tool set. If your business is about something a CRM has never heard of, define it.