AI agents are moving from chat interfaces into workflows that can read records, call APIs, create tasks, send messages, update systems and trigger downstream actions. That changes the readiness question. A business does not become agent-ready because it has access to a capable model. It becomes agent-ready when the operating environment around the model is dependable enough to support delegated action.
NIST's AI Risk Management Framework and its Generative AI Profile frame AI risk management as an organisational discipline that spans governance, mapping, measurement and management rather than a one-time model choice. That is a useful lens for normal businesses too: the quality of the surrounding operating system matters as much as the intelligence of the agent.
Agent readiness is systems readiness with a new actor added to the workflow.
Start with a process that is already understandable
An agent needs a bounded job. If the business cannot explain when a process starts, what inputs are required, what decisions are allowed, what counts as success and when a human must intervene, an agent will inherit the ambiguity.
Before introducing an agent, map the real workflow. Identify the trigger, the systems involved, the information required, the decisions made, the exceptions that occur and the final outcome. If the process depends on undocumented judgment or changes every time a different person performs it, the first task is process design, not agent deployment.
This is the same reason Mellorca argues for understanding how work actually moves before automating it. AI increases flexibility, but flexibility does not remove the need for an operating model.
Check whether the agent can access trustworthy context
An agent can only act on the context available to it. If customer data is duplicated, policy documents conflict, system ownership is unclear or key information lives in personal spreadsheets, the agent will be forced to work across the same uncertainty that already slows people down.
Readiness therefore includes data ownership and retrieval. For each important fact, determine which system is authoritative, whether the information is current, how the agent will retrieve it and what should happen when sources disagree. A practical starting point is the same discipline described in deciding what should be the system of record.
Design permissions around the job, not the novelty
Giving an agent broad access because it might be useful later is weak architecture. Access should follow the task. An agent that prepares a draft may only need read access. An agent that updates a customer record may need tightly scoped write permission. An agent that can issue refunds, change bank details or commit the company to a contract requires a very different level of control.
Define what the agent may read, what it may change, which actions require human approval, which actions are prohibited and which actions must create an audit record. The same least-privilege principle used for human and service accounts should apply to AI-enabled workflows.
Make integrations explicit
Useful agents often sit across several systems: CRM, email, finance, service management, document stores and internal databases. The agent may appear to be the visible layer, but the operational dependency is the integration architecture underneath it.
Document every API, connector, credential, rate limit and downstream dependency. Decide what happens if one system is unavailable or returns incomplete data. If the workflow relies on fragile point-to-point connections or user-owned credentials, improve those foundations before increasing the agent's authority.
Separate recommendation from execution
Not every use case needs autonomous action. A useful maturity path is to begin with observation, then recommendation, then supervised execution, and only then consider autonomous execution for bounded, low-risk decisions.
For example, an agent can first identify invoices that appear to need follow-up and explain why. Once the business trusts the selection logic, it might prepare draft communications. Later it could send routine follow-ups within approved rules while escalating exceptions to a person. This staged approach creates evidence before authority expands.
Plan for failure before launch
Agentic workflows can fail because the model gives a poor answer, an integration breaks, a credential expires, a source system changes, the input is unusual or a downstream action succeeds only partially. The workflow therefore needs more than a happy path.
Define retry rules, duplicate-prevention controls, escalation routes, human fallback and the evidence needed to reconstruct what happened. Important actions should be observable enough that the business can tell what the agent attempted, what it changed and whether the intended outcome occurred.
NIST's current AI resources continue to emphasise testing, evaluation, verification and validation as part of operationalising AI risk management. That reinforces a basic principle: production AI should be managed as a living business capability, not a finished experiment.
Assign an operational owner
Someone must own the outcome after launch. The owner does not need to build the agent, but must know what process it supports, what acceptable performance looks like, which exceptions matter, who can change the workflow and when it should be paused or retired.
Without ownership, an agent becomes another piece of software that continues running after the original project team has moved on.
A practical readiness test
Before moving an AI agent into a business-critical workflow, ask seven questions:
- Can we describe the process and its boundaries clearly?
- Do we know which data and systems are authoritative?
- Are permissions limited to what the job requires?
- Are integrations stable, documented and owned?
- Do high-risk decisions have appropriate human control?
- Can we observe, investigate and recover from failures?
- Is there a named owner responsible for the workflow after launch?
If several answers are no, the business may still be ready for an AI experiment. It is not yet ready to make that agent part of dependable operations.
What better looks like
An agent-ready operating environment has clear process boundaries, governed data, deliberate permissions, maintainable integrations, visible failure handling and explicit human accountability. The agent is not a parallel experiment sitting beside the business. It is one controlled component inside the operating system.