Trending Articles
Trending Topics
Trending
This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.
The conversation around enterprise AI has moved past whether agents will take action. They already do. The harder, less-discussed question is which workflows are actually ready to receive that action safely.
Most enterprise workflows were built for a traditional operating model. One where a human user clicked a button, filled out a form, or initiated a process from a specific screen. Now, AI agents are being asked to call those exact same workflows from Slack, Claude, ChatGPT, mobile, voice, and other surfaces.
Many of those workflows simply weren’t designed for this. They work when a human is guiding them, but they break down or pose massive risks when an autonomous system pulls the trigger. Agent-readiness is not a model capability. It’s a workflow design discipline.
For two decades, “production-ready” was the gold standard for software deployment. It meant your application could safely run at scale, meeting strict benchmarks for uptime, security, performance, and integration. Today, a new bar is taking precedent: Agent-ready. Agent-ready means that a workflow can be safely invoked by a non-human actor, such as an LLM, agent framework, or conversational interface, without losing the governance, security, and compliance properties the business depends on.
Right now, most enterprises are hitting a wall here. According to Cisco’s 2026 State of AI Security report, 85% of large enterprises are actively piloting AI agents, but only 5% have successfully moved them into production. Furthermore, Deloitte’s 2026 State of AI in the Enterprise report highlights that roughly 79% of organisations are facing severe challenges in scaling their AI initiatives despite record investments. While the AI skills gap is often cited as the top barrier, the underlying technical reality is that our existing backend processes are rejecting the agents we try to hook up to them.
It’s been clear to me that document workflows are uniquely exposed to this agentic friction for three specific reasons:
I frequently see teams build a beautiful demo where an LLM pulls customer data, drafts a contract, and prepares it for sending. It looks like magic. But when you ask the enterprise architecture team to clear it for production, the project stalls. Why? Because the workflow relies on the agent “figuring out” how to generate the document on the fly, it leaves no audit trail, bypassable access controls, and a high risk of data leakage.
Let’s take the most common document used in enterprises: a contract (or its variants). A contract has data (customer PII, dates, products and services, legal protections and clauses, signatories). In this day and age of LLMs, anyone can generate a “contract” that looks like it’s very real, but clauses and legal protections aren’t just “generated,” and legal counsel has curated and carefully defined those. Using generative AI in this case is like using coding agents to build a personal stock-trading portfolio for your investments. The risk of getting this wrong has far-reaching implications, both reputational and monetary. Workflows and templates drive consistency. When it comes to compliance and legal requirements (especially in regulated industries), consistency trumps everything.
Across enterprises successfully running agents in production, the same handful of design properties continue appearing. These are characteristics of the underlying workflow itself, and they determine whether an agent can safely interact with it.
Most legacy document workflows require a human to click through an interface. Agent-ready workflows expose that exact same business logic as a structured, callable action—through an API, a Model Context Protocol (MCP) tool, or a strict function call.
MCP has been a massive step forward because it standardises how models discover and use tools, without requiring developers to reinvent integrations from scratch. But a protocol is only as good as what it connects to. The workflow must have clear inputs, defined outputs, and a stable interface that doesn’t depend on fragile UI automation or screen scraping.
The Test: Could this document workflow be invoked identically from a Slack message, a Claude prompt, an internal portal, and a mobile app? If the answer is no, it’s not agent-ready.
Many early AI document architectures pull raw data from a source system (such as Salesforce), generate the document in a separate, isolated AI-powered tool, and then push the finished document back. This pattern introduces massive governance debt.
Agent-ready workflows flip this model; the agent initiates, but the system of record executes. Data, templates, approvals, and storage never leave the governed environment. MCP itself is neutral on governance; an MCP server can be implemented with enterprise-grade access controls or with none at all. Where the work actually runs determines whether your application is defensible.
When a human generates an invoice or a contract, the system inherently knows what data they are allowed to see. When an agent acts on behalf of a user, those exact same permissions must accompany the request.
Agent-ready workflows do not run using omnipotent, generic service accounts. They run under the identity of the requesting user, preserving sharing rules, field-level security, and approval authorities. We have to treat AI agents as first-class identities in the enterprise, giving us full visibility into what they access and enforcing standard security controls over time.
The Test: If an agent generates a proposal on behalf of a junior sales rep, does the resulting document contain only the data that the specific rep is authorised to see? If you can’t answer with a confident yes, the workflow isn’t safe for an agent.
In a human-driven workflow, the audit trail is simple: User X clicked button Y at time Z. In an agentic workflow, the chain is longer and more abstract. A user prompted an agent, the agent interpreted intent, selected a tool, passed parameters, received an error, retried, and finally succeeded.
Agent-ready workflows log the entire chain. They record which agent invoked the action, on whose behalf, with what specific inputs, against which template, and with what result. For high-risk systems, this isn’t just a best practice. It’s a legal requirement. Frameworks like Article 14 of the EU AI Act mandate clear human-in-the-loop oversight and verified confirmation steps for high-stakes automated decisions.
This is the most critical characteristic, and the one most frequently misunderstood. Agent-ready document workflows completely separate the intelligence layer from the execution layer.
The agent’s job is to use its intelligence to decide what should happen. Which customer needs a renewal packet, which contract tier applies, or which executives need to sign off. However, the document itself should be produced via pre-approved templates, validated data fields, and hardcoded business rules. The agent shouldn’t draft a liability clause from scratch; it should populate a vetted template with vetted data. This boundary keeps the output completely predictable and compliant.
If I were to add a sixth characteristic from my years designing large-scale enterprise architectures, it would be this: The workflow must be transactionally idempotent – meaning repeating the exact same call with the same parameters results in the same single outcome without duplicating records.
Humans naturally understand context and consequences. If a page takes too long to load, a person might wait, refresh the page, or abandon the task altogether. They generally won’t click a “Submit Payment” or “Generate Final Contract” button twenty times in a few seconds. AI agents, however, operate differently. They execute tasks through automated loops, and when an API call times out or a process fails unexpectedly, their default behaviour is often to retry. Without proper safeguards and state awareness, that retry can trigger the same action multiple times, creating duplicate transactions, documents, or other unintended outcomes.
If your underlying document workflow isn’t idempotent, an agent loop can easily generate hundreds of duplicate contracts, trigger endless customer notifications, or corrupt downstream databases in a matter of seconds. Agent-ready workflows safely handle retries, gracefully manage bulk operations, and explicitly track their own state across system boundaries.
It is incredibly easy to focus your AI strategy entirely on the frontier models, comparing LLM benchmarks, debating orchestration layers, or choosing agent frameworks. While those things matter, they are rarely the deciding factor in whether enterprise AI initiatives succeed or fail.
The real determining factor of success is your unglamorous backend architecture.
Before exposing your enterprise data to an autonomous system, evaluate your core document workflows against these six characteristics. A workflow that holds up across all of them is ready for the future of agentic work. One that doesn’t require a design intervention before an agent ever touches it. Taking the time to build a structured, governed, and bounded workflow foundation is what turns AI from a risky experiment into an enterprise-grade asset.
