The native agent inside your system of record is not the AI decision in front of you

Every technology leader running a system of record evaluation this year has heard some version of the same instruction from above: pause the new AI vendor conversation, our system of record just shipped its own agents, let's see what those do before we commit budget somewhere else. Workday built Illuminate agents into its own platform. SAP built Joule agents into SuccessFactors. Salesforce built Agentforce into its own stack. The instinct behind the pause reflects a real bet: that the lowest-risk AI purchase is the one that requires no new purchase at all, the vendor is already inside the security boundary, already paid for, already wired into every downstream system that depends on it. Adding an agent to a platform you already run reads like the safe version of adopting AI. That reasoning deserves a real answer.

Why the instinct is sound

Buyers who choose to wait are not confused about what agents do. They are applying a discipline that has served procurement well for two decades: fewer vendors means fewer integration points, fewer contracts to renegotiate, fewer support relationships to manage when something breaks at two in the morning. A system of record vendor shipping its own agent removes an entire evaluation cycle. No new data processing agreement. No new security review. No new login for the team to learn. The incumbent already passed procurement once, and asking it to do more with the access it already has looks like the path with the least friction.

There is a sharper version of the same instinct too. Whoever holds the data has the shortest path to acting on it. A system of record vendor does not need a connector, a sync job, or a permissions model built from scratch, because the agent runs inside the same database the record already lives in. Waiting to see what the incumbent ships is not passive. It is a reasonable guess that proximity to the data will translate into a better agent, and the guess is not obviously wrong.

The budget conversation reinforces the same instinct. A new vendor line item is visible right away: a contract, a security review, a line on next quarter's spend. A pause is invisible by comparison. Nobody puts the cost of an unmade cross-system decision on a slide, so the choice to wait looks free even when the decisions it postpones keep costing money every quarter nobody is tracking.

What the native agent can and cannot see

Workday's own announcement of its latest Illuminate agents makes the shape of the bet visible: a Case Agent, a Performance Agent, a Financial Close Agent, each one built to query Workday's own data and trigger Workday's own workflow approvals. SAP's Joule agents work the same way inside SuccessFactors, and Salesforce's Agentforce works the same way inside the Salesforce object model. Each vendor is doing exactly what its position in the stack allows: reasoning over the records it already owns, and acting on the workflows it already controls.

Workday has also built a separate product, the Agent System of Record, to register and monitor every agent touching the company, including third-party agents with no access to Workday data at all. That is a governance function. Logging that an outside agent exists and tracking what it touched tells a security team something useful. It does not mean the agent, or Workday, reasoned across that outside system's data to produce a recommendation. None of that is a shortcoming. It is the correct, honest scope of a system of record.

The scope is also the whole problem the pause misreads. A hiring decision, a retention risk, a claims escalation: none of these live inside one system. A candidate's interview history sits in the applicant tracking system. What that candidate does after being hired sits in the HRIS. What a producer says to a client sits in call transcripts inside the CRM. The System of Intelligence framing that a16z popularized names this precisely: the systems of record are the graph of who talked to whom and what happened where, and the layer that reasons across the whole graph is where the useful recommendation gets made. A native agent built by one system of record vendor can only see its own node. It was never built to read the other nine to fifteen systems an enterprise runs, because reading them was never inside that vendor's incentive or its data access.

This is not a speed problem a future release fixes. It is a structural one. A vendor whose product is the system of record has no reason to make its agent fluent in a competitor's schema, and every reason to keep the agent's value inside its own platform boundary, because that boundary is the product being sold. The question in front of a buyer pausing to wait is not whether the incumbent's agent will get better. It probably will. The question is whether a better single-system agent ever becomes a cross-system one, and nothing about how these products are built or sold suggests that it does.

None of this is a criticism of the systems of record themselves. Nodes treats every system of record as infrastructure, not competition: Workday stays Workday, SuccessFactors stays SuccessFactors, Salesforce stays Salesforce. An incumbent building agents inside its own walls is not the problem. An agent confined to one wall was never going to answer a question that spans every wall the enterprise has, and no amount of patience changes what a single system was built to see.

What this looks like in practice

Picture a retention risk workflow, the kind every large enterprise says it wants and few can run end to end. The signal that a specific employee is at elevated risk rarely lives in one place. A dip in the performance review inside the HRIS. A pattern in call transcripts inside the CRM that reads as disengagement before anyone files a formal complaint. A missed internal mobility application logged in a separate platform months earlier. Any one signal alone is thin. Together, read across systems and against what the company's own outcomes have looked like historically, they are the difference between a manager finding out in a scheduled one-on-one and a manager finding out from an exit interview.

A system of record's native agent can surface the performance dip, because that record lives where the agent runs. It cannot connect the dip to the call transcript pattern, because the transcript lives in a system the agent was never built to read. What a buyer gets from the native agent is a better version of a report that already existed: faster, maybe formatted better, still confined to one system's view of the employee. What an intelligence layer reading across every system of record produces instead is the workflow itself: the connected pattern, the evidence behind it, and a recommendation with the cost of acting weighed against the cost of waiting. A human approves, edits, or rejects that recommendation before anything executes; the agent proposes, the person decides. That approval step is what makes the recommendation something a manager can question and trust, rather than an output from a system nobody can interrogate.

The gap between those two outcomes will not close because the native agent gets a faster model underneath it next year. It will not close because the vendor adds a new module. It closes only when something is built specifically to read across systems that were never designed to talk to each other, and that something was never going to be built by the vendor whose business model depends on the value staying inside its own walls.

What to ask instead of waiting

A buyer who wants to test whether the wait is worth it does not need a technical evaluation. Three questions do the work.

Ask the system of record vendor directly whether its agent can read a system it does not own. Not integrate with. Read. A connector that pulls a field into a dashboard is not the same as reasoning across two systems at once. Most answers will describe the first and imply the second.

Ask what happens when the agent's recommendation is wrong. A vendor with a real approval architecture will describe who sees the recommendation before it acts, what gets logged, and what a person can change. A vendor without one will describe a settings toggle.

Ask for one recommendation the agent produced that required reading more than one system to generate. If the honest answer is that every recommendation so far has come from data already inside that one platform, the wait has already answered its own question, just not the one anyone meant to ask.

None of this makes the incumbent's agent a mistake to adopt. It is very likely worth turning on. It answers a real, narrower question about the system it lives inside. It does not answer the question that started the pause in the first place, which was never about that one system. It was about whether the enterprise's decisions, which never respect a single vendor's boundary, would finally get evidence and a workflow attached to them. Waiting for the native agent to answer that question is waiting for an answer it was not built to give.

The vendor that already has your data is not obligated to also have your context. Those are different assets, built by different incentives, and only one of them requires reading across every system the enterprise runs instead of the one that pays that vendor's bill. A pause is a legitimate procurement decision. Mistaking a single-system agent for the cross-system intelligence layer the pause was meant to wait for is not caution. It is choosing the easier evaluation over the one that was needed. The clock on that second evaluation does not pause while the first one waits. It just runs unwatched.

Sources

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.