For twenty years a CRM has had one job that everything else depended on: remember what happened. A rep logged the call, the field changed, the stage moved, and the history showed who did it. If you wanted to know why a deal looked the way it did, you could find a person to ask.
An agentic CRM changes the arrangement. Software now follows up the stale deal, updates the stage, merges the duplicate and rewrites the next step. It does this faster and more often than people did, and the result looks identical to a human edit in the field history: a value changed, by a user called "integration", at a time. The one question the CRM was built to answer, why does this record look like this, now has no answer inside the CRM.
That is the first thing that breaks, and it breaks quietly. Here is what the record has to hold to keep its job.
Field history records that a value changed. It does not record why, under whose rule, or what happened afterwards. For a person that was fine, because a person could be asked. A rule that fires on every record cannot be asked, and an agent's reasoning is not stored anywhere unless someone decides to store it.
Take a simple case. A deal has had no activity for twenty-one days, so an agent sends a short check-in to the contact and moves the next step to "awaiting reply". Three weeks later the rep opens the deal and sees an email they did not write, a next step they did not set, and a contact who is annoyed. Field history says the next step changed. Email history says a message went out. Nothing says that a stale-deal rule did it, which version of the rule, whether anyone approved it, or whether this is the first time it has fired on this account.
Multiply that by two hundred deals a week and you have a CRM whose data is increasingly correct and increasingly unexplained. People respond the way they always respond to unexplained data: they stop trusting it and keep their own notes. The system of record becomes a place the system writes to and nobody reads from.
The action. One row per thing an agent did: which agent, which verb, which record, the value before and the value after, the time. It is a module of its own, linked to the record it touched, not a note in the activity feed. A row exists even when the action changed nothing visible, such as a check that found the record already correct, because "the agent looked and left it alone" is information too.
The authority. One reference per action to the rule that allowed it and, for actions that need a person, to the approval. A rule has an identifier and a version; an approval has a name and a time. Without this, you can see what an agent did but not whether it was allowed to, and the first audit question will be exactly that. We argued in Your CRM Grew Agents. Who Runs Them? that every agent needs a named operator; the authority record is where that operator's decisions show up in the data.
The outcome. One stamp, written later, on the action: the contact replied, the email bounced, the stage moved on, the deal closed, or a person reversed it. This is the record kind most teams skip, and it is the one that tells you whether the rule is any good. A check-in that is reversed by the rep forty percent of the time is a rule to change, and without outcomes nobody will know.
A fourth field belongs on the action row and costs almost nothing: whether the action can be undone, and how. Merging two contacts can be undone if the originals are kept. Sending an email cannot. An agent should know the difference before it acts, and a person reading the log should see it afterwards.
The point of the three records is not a compliance file. It is that the people who work in the CRM can ask the system a question in their own words and get an answer from the data. Why did this next step change? Because the stale-deal rule, version three, fired on the twelfth. What else did that rule do this week? Forty-one actions, nine reversed. Who approved the change to version three? The sales manager, on the fifth.
Those questions have the same shape as the questions a manager used to ask a rep. The difference is that the answers come from rows, not from memory. That is what keeps the CRM in its role as the system of record while the work in it is done by software. We set out the wider shift in what changes when the system acts on the record: the demo shows an agent in one application, and the record is what holds when it works across three.
Leaving the three records out does not cause an incident on day one. It causes a slow loss. The history stops being trustworthy, so people trust their own notes. The agent's rules cannot be tuned, because no outcome is recorded. An approval cannot be shown, because it was never attached. And when something goes wrong, which it will, the investigation starts from an export of field changes and a guess.
The cost of putting them in is modest and most of it is up front. One module for actions, two reference fields, one outcome field, and a rule that no agent writes to a record without writing the action row first. The last part is the one that matters: the action row is written in the same step as the change, so an action with no row cannot happen.
If you already have agents running against your CRM, begin with the single most active one. List what it did last week from the audit trail you have, even if that is an export. Pick ten actions at random and try to answer, for each, why it happened, under which rule and what the outcome was. The number you can answer is the measure of how much of the record you have already lost.
Then build the three records for that agent only. Do not design them for every future agent; design them for the one in front of you, and extend them when the second one arrives.
We design the action, authority and outcome records as part of the agent layer we run for companies of 5 to 1,000 users, so the CRM stays the system of record while software works in it. Discovery is no-risk: we define the records for the one agent you would trust most, take the baseline from last week's actions, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.
A CRM that acts is only an improvement if it can still explain itself. Everything else about it is a feature.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
