When an agent changes a record, the honest audit line has five parts. Most companies have designed none of them, and the system's own log covers only the last.
A person's change leaves one audit line. An agent's change needs five parts, and most companies have designed none of them.
Each chapter starts the video at that point.
When a person changes a record in a business system, the system writes one line in its audit log: who, when, what changed. Nobody designed that line. It came with the product, and on the day something goes wrong it is the first thing anyone reads. When an agent changes a record, the honest audit line has five parts, and in most companies that have switched an agent on, nobody has designed any of them. This video is those five parts, the two ways companies build them, and why one of the two loses the line on exactly the day it is needed.
Everything on screen is a mock demo with sample data: a mock sales system, a mock agent, invented records. Here is the line as it stands for a person. Priya changed the amount on the Harbor Dental deal from forty thousand to thirty-six thousand eight hundred, on Tuesday at two-fourteen. Three facts, one row, written by the system itself, under Priya's login. If the discount is questioned in March, the row answers who and when, and Priya answers why. That line works because of one assumption built into every business system: the login that made the change is the person who decided it.
The system never had to record the reason, because the reason lived in the person, and the person could be asked. An agent breaks that assumption in the first second it runs. Now the same change made by an agent. Part one: who asked. Sometimes a person typed a request; often nobody did, and a schedule ran the agent at six in the morning. Part two: what it read. The agent decided after reading the deal, the customer's payment history and a rule somebody wrote; those three are the reason, and they are not in the person any more.
Part three: what it proposed, which may differ from what was finally written. Part four: who approved, if the action was one that waits. Part five: the write itself, under whose identity, which is the only part the old one-line log was built for. Five parts, and notice that four of them exist nowhere unless somebody decided they should. The audit log will faithfully record the fifth. The reason, the proposal and the approval are gone the moment the run ends, unless the design kept them. The first way companies build this, usually by accident, is to run the agent under a person's login.
It is the fast way: the agent inherits Priya's permissions, reaches every screen she can, and the audit log says Priya changed the amount at six in the morning. On a quiet month that looks fine. On the day it matters it is worse than no log. The log names a person who did not decide. The agent's reading, its proposal and the rule it followed are in a vendor's console somewhere, or in nothing, because the run finished. The approval, if there was one, was a message in a chat channel.
Reconstructing what happened means asking the person who did not do it, reading a console that was not designed to be evidence, and searching a channel. That is the line lost, and it is lost precisely because the agent used a door built for a person. The second way takes one decision and two small records. The decision: the agent reaches each system through that system's own door, the interface a connector would use, under its own identity, a user called what it is. Now the audit log says the order-release agent changed the amount, and that line is true, and it is written by the system of record, not by the agent's vendor.
The two records: a request record, written when the run starts, with who or what asked and what the agent read; and a proposal record, written before anything changes, with what it proposed and why, which becomes the approval record when a person says yes. In a sales system those two are a note and an approval process, both standard; in a help-desk system they are a ticket. The five-part line is then three rows in systems the company already backs up, searches and trusts, and nothing is in a console that belongs to somebody else.
Here is the day. A customer disputes the discount in March. Under design one, the manager finds Priya's name on a change she never made, a console the vendor has since reorganised, and a chat thread. Under design two, she opens the deal, reads the approval record with the reason, reads the request note with the three things the agent read, and sees the rule that produced the proposal. Ten minutes, three rows, no reconstruction. The same three rows are what a buyer should ask any agent vendor to show.
Not a dashboard of what the agent did, which is a report, but the line in the system of record, under the agent's own identity, with the reason and the approval beside it. If the vendor's answer is a console, the line is theirs, not yours. We design the record before we design the agent, which is why the first screen we show a client is often an audit log and not a demo. An agent's audit line has five parts, and only one of them is written for free.
Give the agent its own door and its own identity, write the request and the proposal as records in the system that already keeps everything else, and the line exists on the day it is needed. Run it under a person's login and the line names the wrong person and keeps the reason nowhere. We are CodeStringers. We design, build and run business systems and the agent layer over them, and we design the record before the agent. The approval video and the audit-log article are linked below.
We design, build, integrate and operate AI-driven, platform-agnostic integrated business solutions for operationally complex companies. Start with a conversation; we will tell you if we are a fit.
