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. The framework is voluntary and was written to be adapted to different organisations. 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 judgement or changes every time a different person performs it, the first task is process design, not agent deployment. The pattern is described in when your business wants agents but has no defined workflow.
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. Anthropic's engineering guidance on building agents makes a related point: start with the simplest solution that works, and add autonomy only where predefined workflows fall short.
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. The risk of drifting from this is explored in agent permissions broader than the task requires.
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.
A worked example
A Port Elizabeth (Gqeberha) manufacturer with ninety staff wants an agent to handle supplier invoice queries. At the observation stage, the agent reads incoming queries and classifies them, and a person checks a sample each day. After a month, classification accuracy is good enough to move to recommendation: the agent drafts replies using purchase order and goods-received data, and a creditors clerk approves each one. Only routine "payment date" queries, where the answer comes straight from the accounting system, move to automatic replies. Queries involving disputes, price differences or bank detail changes always go to a person. The business gains capacity without handing over decisions it is not ready to delegate.
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. The UK NCSC's guidelines for secure AI system development similarly treat secure operation and maintenance, including logging, monitoring and update management, as a distinct stage after deployment. 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.
Trade-offs
Waiting for every foundation to be perfect would mean never starting. The practical balance is to match autonomy to readiness: an agent that only drafts or recommends can run on imperfect foundations because a person checks its output, while an agent that acts directly on customers or money needs all seven answers to be yes.
What to do first
- Choose one workflow with clear inputs and high volume.
- Run the seven-question test on it honestly, with the people who do the work.
- Fix the one or two weakest answers before building anything.
- Start the agent at observation or recommendation, with a named owner and a written standard for good output.
- Review results monthly and expand authority only when the evidence supports it.
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.
Sources and further reading
- NIST: AI Risk Management Framework (last verified 10 October 2026)
- NIST: Generative AI Profile (last verified 10 October 2026)
- Guidelines for secure AI system development (last verified 10 October 2026)
- Building Effective AI Agents (last verified 10 October 2026)