The Skeleton: The Agent Is the Truth About Nothing at All

Dana Okafor's offboarding agent reassigns her fourteen CRM accounts, revokes six systems, and computes her final paycheck to the dollar. Ask Salesforce who owns those accounts now, and it agrees. Ask Workday whether she's still employed, and it agrees. Ask the equity system whether "D. Okafor" in its records is the same person as "Dana Okafor" on her badge, and nobody agrees, because nobody ever taught it that those two names belong to one person.

If you are picking this up mid-series, the premise fits in a paragraph. An agentic system is eleven layers grouped into seven organ systems, and the model is one of them. The series walks one ordinary event through all eleven: Dana, a senior engineer, resigns. Part 0 drew the map, Part 1 gave the agent a name of its own, Part 2 gave it a plan, Part 3 gave it hands that reach real systems, Part 4 gave it a full picture of what she owns, Part 5 gave it the rules for what it may do alone, and Part 6 gave it a way to prove what it did.

Fourteen days after Dana resigns, the agent has revoked her access, computed her paycheck, and reassigned her accounts. This layer, System of Record, decides whether any of that is real outside the agent's own head.

Think of Workday, the CRM, and payroll as the company's official books. They were the official record of who's employed, who owns which customer account, and who got paid, years before any agent existed. Earlier parts of this series cover the agent deciding what should happen to Dana. This layer is about the agent actually going into those official books and changing them, the same way an employee would open Workday and click "terminate," except nobody is standing there to catch it if the click lands on the wrong record.

That distinction, reading these systems versus writing into them, is the whole reason this layer is the hardest one in the series. An agent that only reads from Workday or the CRM, to summarize, to explain, to recommend, is fairly safe. If it gets something wrong, you notice, because nothing has actually changed yet. An agent that writes into those systems is a different kind of risk, because a bad write becomes a fact. The CRM has no way of knowing a reassignment was wrong. It just believes the new owner is correct until a person notices otherwise, and that person is usually an auditor, months later, not the agent itself.

The six systems Dana's offboarding touches

None of these systems were built with an agent in mind. They were built for people, years before anyone imagined software would be writing to them on its own, and Dana's offboarding runs through all six without any of it being contrived for the story.

• The CRM holds fourteen accounts, each with a named owner field. Knowing Dana had fourteen accounts was Part 4's job. This layer's job is changing the owner field on all fourteen and having the CRM accept the change as real.
• The finance system is where her final paycheck becomes an actual transaction, not just a number the agent calculated and believes.
• Workday holds the truth about her employment. Okta holds the truth about her access. Neither one asks the agent's opinion. They tell it what's true and expect a write-back that matches.
• ServiceNow owns the ticket proving the offboarding process itself happened, in order, with a timestamp on each step, independent of anything the agent says about itself.
• The data warehouse is where everything above eventually lands, and it's what Part 6's activity log gets checked against, nine months later, by someone who wasn't in the room for any of it.
• Master data management is the one piece that doesn't hold a fact about Dana at all. It holds the answer to whether the other five are even talking about the same Dana.

Reading from any one of those six systems is straightforward, and earlier layers in this series already do plenty of that. Writing back correctly is this layer's actual job, and it starts with a question that has to be answered before any of the six will accept a change: is the agent even touching the right person's record?

Are these records even about the same person?

The badge system has "Dana N. Okafor, Employee ID 40218." The equity platform, an application older than some of the people it affects, has "D. Okafor" with no employee ID at all, just an email address that stopped working the day IT rotated her account. The CRM's owner field says "D Okafor, Enterprise West." Slack has "dana.okafor."

A person looks at those four records and knows immediately they're the same woman. An agent doesn't, unless something has already done the work of saying so. That something is master data management, the least glamorous name in this whole series and one of the most consequential jobs in it.

Get the matching wrong one way, and the agent revokes the wrong Okafor's access, because the equity system's "D. Okafor" happened to be close enough to a different employee's name. Get it wrong the other way, and the agent treats "D. Okafor" as an unknown person, skips the equity write-back entirely, and leaves her forfeiture uncalculated on a system nobody thinks to check again until an auditor asks.

If you can't say whether "D. Okafor" in the equity system is the same person as "Dana Okafor" on the badge, you can't offboard her properly. You can only guess, and a wrong guess in either direction is a real problem, not a rounding error.

Why writing back is so much harder than reading

I made a version of this point before in "Just Build It in AI": the fast part of a project is rarely the expensive part. This layer is where that shows up most clearly in an agent program.

Pulling Dana's list of accounts out of the CRM, just reading it, is a few days of work for a decent engineer. Point an API at Salesforce and you have a working dashboard by Friday. That's never been the hard problem.

Writing back is a different kind of work, because the CRM doesn't just need the new value. It needs guarantees that reading never has to give.

• If the reassignment step accidentally runs twice, because a network call timed out and retried, an account can't end up assigned to two people or stuck in a state nobody can explain.
• If step nine of twelve fails, the first eight can't just sit half-finished forever. Something has to either finish the job or cleanly undo what already happened.
• A log line that says "wrote to payroll" isn't what a finance team signs off on. They want a record of who approved the change, when, and against what policy.

Now put that requirement on the one system in Dana's story with no way to connect to it programmatically at all: the equity platform from 2003. Part 3 covered the agent clicking through it in a browser like a person would. This layer covers what happens after the click. A change typed into a vendor application through the screen carries none of the safety guarantees a proper connection would, and finance still has to trust the number that comes out of it.

897 applications is the average enterprise's application count, and fewer than a third are connected to each other.

Source: MuleSoft, 2025 Connectivity Benchmark Report

Poor data quality from disconnected systems costs the average organization an estimated $12.9 million a year.

Source: Gartner, 2020, still the most-cited benchmark for this figure

Neither number is about agents. They're about how much of "write back to the system of record" was already, before any agent showed up, writing back to something nobody had finished properly connecting. An agent doesn't create that debt. It just runs into it faster than anyone before it did.

Why the payroll system has the final say, not the agent

Part 4 covered what happens when an agent loses track of what it's already done, like issuing Dana's paycheck twice. This is a related but different problem, worth separating out clearly.

Say the agent's own records show the paycheck went out. Say the finance system's actual transaction record disagrees, because the write failed quietly or landed on the wrong account. Nine months later, nobody looking into Dana's offboarding is going to ask the agent what it remembers doing. They're going to pull the Workday termination record, the payroll entry, and the CRM's ownership history, and whatever those three systems say happened is what the company is on the hook for, no matter what the agent's own memory believes.

The agent's memory is a claim about what happened. The finance system's record is the evidence, and when the two disagree, the evidence wins. That's the entire point of a system of record: it's the one place in the company where "what actually happened" gets decided, independent of how the agent was built, and it was already making that decision for the business long before there was an agent around to argue with it.

Why this is where projects stall

Every demo that impresses a room reads beautifully. Pull Dana's account list, summarize her equity position, draft the offboarding plan, all of that is the easy half of the work, and it looks like magic on a projector.

Production is the other half, and it isn't a smaller version of the same problem. It's making sure repeated steps don't corrupt anything, making sure a failure partway through can be cleaned up instead of ignored, and getting a finance team to trust the record, applied to systems that were never designed to be written to by anything other than a person filling out a form one field at a time.

The fast part was never the model. It was reading. The expensive part was always writing back to a system somebody will eventually audit. That's the gap between a working demo and a working platform, and it's why this layer sits last in the series rather than first. Everything the earlier six layers built, identity, a plan, reach, memory, judgment, proof, exists to get the agent to this exact moment: the point where it has to change a system of record and be believed.

What this layer decides

Each layer before this one gave Dana's agent something.

• The front door gave it a name.
• The brain stem gave it a plan.
• The bloodstream gave it reach.
• The memory gave it a full picture.
• The immune system decided what it could do alone.
• The nervous system gave it a way to prove what happened.

This layer decides whether any of that was real outside the agent's own head.

Eleven layers, seven organ systems, one ordinary event: a senior engineer gives two weeks' notice. The model shows up exactly once in that whole stack, behind the model gateway, one piece out of roughly fifty-six, which is close to the actual share of the engineering work that touches the model.

A simple flowchart would have handled the version of Dana's offboarding you could predict in advance. The agent existed for the exceptions nobody wrote into that flowchart: involuntary, on a visa, under a legal hold, managing six people whose reporting lines just broke. Everything this series built, identity, plan, reach, memory, judgment, proof, and now writing back to the record, exists to make those exceptions survivable instead of catastrophic.

The model will keep getting better. It won't, at any level of capability, decide what your company owes Dana Okafor, tell your payroll system it paid her, or figure out whether "D. Okafor" and "Dana Okafor" are the same person. Those are the parts you have to build. They were always the hardest part, and they were never going to be the model.

That closes the series: eleven layers, seven organ systems, one resignation followed end to end, from the front door that named the agent to the system of record that decides whether anything it did was real.

Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss the system of record underneath your agent program.

References

1. MuleSoft (Salesforce). "2025 Connectivity Benchmark Report." 2025.
2. Gartner. "Data Quality: Why It Matters and How to Achieve It." Cost estimate originally from Gartner's 2020 Magic Quadrant for Data Quality Solutions, still the most-cited benchmark for the figure.
3. Matthew Kruczek. "Just Build It in AI." matthewkruczek.ai, 2026.
4. Matthew Kruczek. "The Nervous System: You Cannot Debug an Agent by Reading Its Answer." matthewkruczek.ai, 2026.