Enterprise data is ready for AI agents when an agent can retrieve authoritative context, act through controlled tools, respect identity and permissions, handle incomplete information, produce traceable evidence and escalate exceptions to an accountable human.

A clean warehouse alone is not enough. Agent readiness spans data, APIs, identity, workflow design, security, evaluation and operating ownership.

Start with a business decision

Do not begin with where agents can be deployed. Begin with a bounded outcome: resolve a defined support request, prepare a sales brief, reconcile an exception, draft a regulated report for approval or update a system after validated conditions.

Specify value, risk, decision rights and failure tolerance. If success cannot be observed, the pilot cannot be governed.

Who should own an enterprise AI agent?

The business owner should own the outcome, while named data, engineering, security and risk owners control their domains. Ownership cannot sit solely with an innovation team.

Dimension 1: Authoritative data

Identify the system of record for every critical fact. Resolve duplicate customer, product, contract and policy definitions.

For each source, document owner, freshness, quality controls, permitted uses and failure behaviour. Retrieval from many sources is not useful if the agent cannot distinguish current policy from an obsolete document.

Dimension 2: Semantic consistency

Define entities, metrics, statuses and relationships in a governed semantic layer or well-managed contracts.

If active customer means three things across CRM, billing and support, an agent will reproduce the disagreement with confidence.

Dimension 3: Identity and permissions

The agent must not become a bypass around application controls. Propagate user or workload identity where possible. Enforce access at the source or tool layer. Separate read, recommendation and action permissions.

Test cross-tenant access, administrative functions and information leakage through explanations.

Dimension 4: Tool and API reliability

Every tool needs a narrow purpose, validated inputs, authorisation, idempotency where required, timeouts, retries, clear errors, audit logging, version control and cost limits.

Do not expose a broad database or administrative API because it is convenient for a prototype.

Dimension 5: Workflow boundaries

Define deterministic steps and steps requiring model judgement. Keep irreversible, financial, safety-critical and regulated actions behind controls appropriate to risk.

Use workflow orchestration when reliable state progression matters. A conversational loop is not a transaction engine.

Dimension 6: Context and retrieval

Measure retrieval separately from generation. Test whether correct sources are found, access filters remain intact and answers cite evidence.

Include conflicting, missing and outdated documents. Enterprise knowledge is not a clean demonstration set.

Dimension 7: Evaluation

Build test cases from real workflows and exceptions. Measure task success, grounding, policy compliance, tool correctness, escalation and cost.

Define pass criteria and regression tests before model, prompt or retrieval changes.

Dimension 8: Observability

Record model and tool versions, policy identifiers, retrieved evidence, calls, latency, cost, errors and outcomes while respecting privacy.

Connect traces to business outcomes. A faster agent that creates more rework has not improved the process.

Dimension 9: Governance and ownership

Name a business owner, data owner, technical owner, security owner and operating reviewer. Define change approval, incidents, vendor review, retention and shutdown authority.

A drafting assistant and an agent initiating payments should not share the same approval model.

Dimension 10: Economics

Model model usage, retrieval, storage, tool execution, review, exceptions, monitoring and engineering labour. Calculate cost per accepted outcome, not cost per token alone.

Readiness decision

Ready for bounded pilot: Sources are authoritative, permissions enforceable, tools narrow, outcomes measurable and escalation designed.

Conditionally ready: Value is plausible but data definitions, controls or evaluation require remediation.

Not ready: No owner, uncontrolled access, unclear authority, irreversible actions without safeguards or no incident evidence.

A 30-day readiness engagement

Week 1: Select workflow, outcome and risk boundary.

Week 2: Map data, semantics, identity and tools.

Week 3: Build evaluation cases and control design.

Week 4: Produce pilot architecture, remediation plan, economics and go/no-go decision.

Turn the assessment into a controlled pilot

Choose a bounded decision

Select one workflow with a measurable outcome, known users and a clear risk boundary. Avoid beginning with a general-purpose assistant that can touch many systems but has no accountable business decision.

Build evaluation cases before automation

Create representative normal, ambiguous, incomplete and adversarial cases. Define acceptable answers, abstention behaviour, escalation and prohibited actions. This makes model and retrieval changes testable instead of subjective.

Expand authority only after evidence

Start read-only, log data and tool access, require approval for consequential actions and measure error cost. Broaden permissions only when evaluation, monitoring and recovery evidence supports the next level of autonomy.

Choose the workflow before the model

Start with a business decision or action that has a named owner, measurable outcome and bounded consequence. “Use agents across the company” is not a use case. A useful starting point might classify a support request, assemble evidence for an analyst or prepare a draft action for approval. Document who benefits, what good performance means, where the agent must abstain and how a person takes over.

Map the current workflow before automating it. Identify systems, handoffs, unofficial spreadsheets, exceptions and judgement calls. Agents amplify ambiguity: if teams disagree about the source of truth or approval rule, automation produces inconsistent decisions faster. Improve the operating process where necessary before adding autonomy.

Build a usable data contract

For every required field, name the authoritative source, owner, freshness expectation, identifier and allowed consumers. Separate factual attributes from generated interpretation. Define how customers, products, contracts and transactions join across systems; similarity search cannot repair incompatible identifiers or contradictory definitions.

Expose data through governed views or APIs that return enough context for the task without granting broad database access. Include provenance and timestamps so the system can explain where an answer came from. Handle missing, stale and conflicting values explicitly. An agent needs a policy for uncertainty, not merely more documents.

Retrieval, context and memory

Use retrieval when the answer depends on changing or private knowledge, but evaluate whether the retrieved material actually supports the response. Segment content around semantic units, preserve titles and access controls, and test queries that use customer language rather than internal terminology. More chunks can increase noise and cost without improving correctness.

Distinguish temporary task context, user preferences and durable organisational memory. Define what may be stored, for how long, who can inspect or delete it and how incorrect memory is corrected. Never allow conversation history to become an undocumented source of truth for consequential decisions.

Tools, permissions and safe action

Treat every tool as a production API with authenticated identity, validated inputs, idempotency, timeouts and audit logs. Use separate read and write capabilities, least privilege and explicit scopes. A tool description is not a security boundary; enforce permissions in the receiving service based on the acting user, tenant and approved purpose.

Begin read-only. Add human approval for financial, customer-facing, destructive or regulatory actions and make the approval show the evidence and proposed effect. Define transaction limits, rate limits, duplicate prevention, rollback and escalation. The system must remain safe when the model repeats an action, selects the wrong record or receives malicious instructions in retrieved content.

Evaluation and monitoring

Create test cases before selecting a model. Include normal, ambiguous, incomplete, adversarial and high-consequence examples with expected answers, acceptable alternatives, abstention and escalation. Measure task success, factual support, tool selection, parameter accuracy, policy compliance, latency and cost. A pleasing demo is not a repeatable evaluation.

In production, trace the user request, retrieved evidence, model decision, tool call, outcome and human intervention without logging unnecessary sensitive data. Monitor changes by workflow and risk segment rather than one global accuracy number. Re-run the evaluation set whenever prompts, models, data, tools or policies change.

Governance, ownership and economics

Assign owners for the business outcome, data, model behaviour, tool integrations, security, evaluation and incident response. Record approved use, prohibited use, escalation and change control. Procurement and legal review should address data handling, retention, subprocessors, intellectual property and exit, while engineering proves that configured controls work in the deployed path.

Compare agent cost with the entire current workflow: labour, waiting, rework, errors and opportunity cost. Include inference, retrieval, integration, evaluation, monitoring and human review. Measure cost per successful outcome, not per prompt. A pilot should stop or change when it creates more review work than it removes.

From pilot to production

Run a shadow phase in which the agent produces recommendations without acting. Compare them with real decisions and examine disagreement. Move to assisted operation with approval, then limited autonomy only for well-tested low-consequence cases. Keep a control group or baseline so improvement can be attributed rather than assumed.

Before expansion, prove access control, incident response, rollback, data deletion, vendor failure and own

The readiness score should drive a decision

Do not collapse readiness into one percentage. Score the target workflow across authoritative data, semantics, identity, tool reliability, workflow boundaries, retrieval, evaluation, observability, governance and economics. Mark any non-negotiable gate separately: a high average cannot compensate for uncontrolled production writes or missing access enforcement.

Finish with one of four decisions: stop and repair foundations; run a read-only shadow pilot; run an assisted pilot with approval; or allow bounded autonomy. For each gap, identify evidence, consequence, owner and next test. Reassess after data, model, tool or policy changes. The assessment is useful only when it controls scope and authority rather than serving as a presentation score.

ership transfer. Document the conditions for increasing authority and for disabling the system. Scaling means repeating a governed pattern across workflows, not connecting a general agent to every system at once.

Common readiness failures and how to repair them

The first failure is document dumping: teams index every available file and expect retrieval to create knowledge. Repair it by selecting the workflow, removing obsolete material, defining authoritative sources and evaluating retrieval against real questions. The second is broad access: a service account can read more than the user requesting the answer. Repair it with user- and tenant-aware enforcement at retrieval and tool execution, plus tests that attempt cross-boundary access.

The third failure is uncontrolled action. A prototype can send email, edit records or initiate payments without idempotency, limits or approval. Repair it by separating read from write, validating parameters in the receiving system and beginning with shadow or assisted operation. The fourth is evaluation after launch. Repair it by creating representative cases and release gates before connecting production tools.

The fifth failure is missing operational ownership. When an answer is wrong, teams debate whether data, retrieval, prompts, the model or the integration caused it. Use end-to-end traces, named component owners and an incident path that can disable authority quickly. Review feedback for systemic patterns instead of allowing individual users to create undocumented prompt fixes.

The sixth is an economics blind spot. A pilot may appear productive while shifting work into review, reconciliation and support. Measure successful outcomes, correction time and avoided effort. Compare performance by workflow segment and stop automating cases where ambiguity or consequence keeps human work unchanged. Readiness means knowing where the agent should not operate as clearly as where it should.

Scenario: an enterprise support agent that can recommend but not silently act

A company wants an agent to help support teams resolve complex account issues. Relevant information exists in a CRM, product database, contract repository, incident system and internal knowledge base, but customer identifiers and terminology are inconsistent. The readiness work starts with one bounded outcome: assemble a supported recommendation for an authorised support specialist. It does not begin by granting the model permission to edit accounts.

The team defines authoritative sources for customer identity, entitlement, contract terms, incidents and product behaviour. Governed retrieval preserves document title, effective date and access restrictions. The agent must show supporting evidence and identify conflicts rather than blend them into a confident answer. Evaluation cases include outdated articles, customers with similar names, incomplete records, hostile instructions embedded in tickets and questions outside the approved scope.

Tools are introduced in stages. Read operations enforce the specialist’s user and tenant permissions in the receiving system. A proposed account change is generated as a structured draft with parameters, evidence and expected effect. The specialist approves it, after which a separate service validates limits, applies the transaction idempotently and records the actor. High-consequence changes remain subject to additional approval even when general performance improves.

Production monitoring connects request, retrieved evidence, recommendation, approval, tool outcome and correction without storing unnecessary customer content. The business measures resolution quality, handling time, rework, escalation and cost per successful case. Expansion occurs by case type, not by switching on universal autonomy. This scenario shows that data readiness includes semantics, permissions, tools, evaluation and ownership—not only a vector database or a cleaned document collection.

Questions for an AI-agent readiness partner

Ask the partner to select one workflow and explain the business outcome, authoritative data, user permissions, tool boundaries, evaluation cases and incident path. Require demonstrations of missing evidence, conflicting sources, cross-tenant access attempts, repeated actions and malicious instructions in retrieved content. Clarify whether the assessment evaluates the deployed identity and data path or only model responses. The roadmap should distinguish data-foundation repair, read-only shadow operation, assisted action and bounded autonomy. Ask who owns evaluation after prompts, models, data or tools change and how production traces avoid unnecessary sensitive content. Commercially, require cost per successful workflow outcome including human review and correction, not a token estimate alone. A strong partner will identify use cases that should remain human-led and conditions that stop the pilot. Readiness is not permission to connect an agent widely; it is evidence that a defined workflow can become more useful without weakening access, accountability or recoverability.