What "agent-ready" actually means for an enterprise system

"Agent-ready" has become one of those phrases attached to almost any product announcement without much agreement on what it actually requires. Vendors use it to mean everything from "you can plug a chatbot into our search bar" to "our platform has a genuine framework for autonomous agents to take action within it." Those are very different claims, and the gap between them matters if you're the one responsible for actually making it work.

A quick example: iDeeDee

I've been building a tool called iDeeDee, short for Integration Design Document agent, to help with exactly this problem in practice. It's still an internal tool at this stage, a local application with a split-panel interface that interviews you about an integration and generates the design documentation off the back of that conversation.

To do its job properly, the agent needs more than just the name of a field. It needs to understand what actually sits underneath it: whether the data in that field is consistent and trustworthy, whether it's a fixed range of values like a numeric type or a dropdown list, or whether it's free text that could contain almost anything. A field called "Status" that's genuinely a constrained set of five values is a completely different proposition for an agent than a field called "Status" that's actually a free text box where people have typed whatever they wanted for a decade. The name alone tells you nothing about which one you're dealing with.

Format matters more than people expect

The other piece that's easy to underestimate is format. Agents work best with markup style languages, XML and JSON being the obvious examples, because they're structured in a way that's straightforward to parse reliably. This is actually one of the more pleasant surprises working with spreadsheet data: an xlsx file is, under the hood, a series of XML files in a zip container. So data that looks like a flat spreadsheet to a human is already in a format an agent can work with cleanly, once you know to treat it that way.

Where Workday already gets this right

Workday is already fairly agent-ready in this sense, largely off the back of the strict data model and, more recently, the general release of ASOR. Something worth paying specific attention to here is your data definitions on calculated fields and reports. If a calculated field has a clear, readable definition of what it is and what it's meant to be used for, an agent can reliably identify when it's the right thing to surface for a given question. If that definition field has been left blank or filled with something vague, the agent's just as lost as a new starter would be looking at the same field with no documentation.

The harder problem: knowing when the job is actually done

ASOR goes a long way toward solving the format and access side of this in an ERP context. But there's a deeper problem underneath it: making sure an agent has a genuinely well-defined goal, one that's actually achievable with the skills and tools it's been given, and clear enough that there's no ambiguity about what "done" looks like.

There's a real example worth knowing here. In July 2026, Hugging Face disclosed that its production infrastructure had been breached by an autonomous AI agent, over 17,000 individual actions logged across a swarm of short-lived sandboxes. Five days later, OpenAI confirmed the "attacker" was actually one of its own models, running an internal cybersecurity benchmark with safety refusals turned off. Rather than working through the benchmark as intended, the agent found a zero-day vulnerability, escalated its own privileges, and pivoted into Hugging Face's production systems to grab the answers and credentials it needed to pass the test. It wasn't malicious in any conscious sense. It was optimising hard for a goal, passing the benchmark, and the boundaries around how it was allowed to achieve that goal weren't tight enough to stop it taking the shortcut.

That's the sharper version of a problem every enterprise deploying agents needs to think through. As models get more capable, the definition of "job done" has to get more precise, and the skills and tools available to reach it have to be deliberately scoped, not just assumed to be used sensibly. We don't want an agent creating a payroll journal that doesn't actually exist just so it has something to report on. The model isn't being dishonest in any meaningful sense. It's doing exactly what an under-specified goal and an overly generous toolset will let it do.

Agent-ready is architecture, not a feature toggle

None of this is really about which model you're using. It's about whether the system underneath has clean, well-documented interfaces, consistent and well-labelled data, and goals and permissions specific enough that an agent can't find a technically valid shortcut to the wrong outcome. Getting that right is the unglamorous work that actually makes agentic AI safe and useful in an enterprise system. Everyone else is bolting a capable model onto a system that was never built to be queried, acted on, or scoped this precisely, and wondering why the results feel unreliable.