A company wants to introduce a customer service agent. The AI has been selected, the prompt is written, and initial tests with demo data look promising. Then comes the sobering reality: The agent cannot access the ticketing system because there’s no suitable API. The required customer data is scattered across systems that don’t communicate with each other, and some of the most up-to-date information exists only in Excel files on employees’ desktops. GDPR compliance for automated data processing is unresolved. And no one has defined what the agent is allowed to do when a customer wants to cancel their contract—or what it must never do.

The AI is ready to go. The organization is not.

This scenario is not an isolated case. In Part 1 of this series, we explored what agentic AI is and why it works technically: tools, planning, and memory—the three pillars that transform LLMs from chatbots into agents. But these three pillars require a foundation. And that foundation is missing in many companies.

What is Agent-Readiness?

Agent-Readiness describes the degree to which a company is technically and organizationally prepared to enable AI agents to work productively.

The analogy is clear: You wouldn’t onboard a new employee without providing them with a laptop, system access, a job description, and a point of contact. With AI agents, most companies do exactly that—they assume the AI’s capabilities and overlook the operational conditions.

The six dimensions of Agent-Readiness:

1. Tool Infrastructure → Can the agent act at all?

2. Data Accessibility → Can the agent access the right data?

3. Access Control → Is the agent permitted to do what it’s supposed to do?

4. Observability → Do we know what the agent is doing?

5. Accountability → Who is responsible if something goes wrong?

6. Team & Processes → Who builds, maintains, and improves the agent?

None of these dimensions are optional. Each can become a bottleneck that renders a theoretically powerful agent practically useless.

Dimension 1: Tool Infrastructure – Can the Agent Act at All?

Agents act through tools (function calling). Without tools, an agent is just a chatbot. But tools don’t exist by default—they must be built, documented, and deployed.

APIs as the Lifeline

Agents interact with systems via APIs. This isn’t new—but the quality of the API landscape determines whether an agent can function or not.

Agent-Ready	Not Agent-Ready
RESTful APIs with clear documentation	No APIs, only manual interfaces
Consistent authentication	Different authentication methods per system
Versioned APIs with backward compatibility	Undocumented changes, breaking changes
Structured error messages	Cryptic errors or silent failures

Question for companies: How many internal systems have a machine-readable API?
If the answer is “half” or “less,” the agent can’t complete half the tasks—and will fail entirely when tasks require multiple systems to interact.

Tool Descriptions: The Human-Machine Interface

The AI selects tools based on natural language descriptions. Precise descriptions are critical—vague ones lead to incorrect tool calls or tools being ignored altogether. Parameters must be clearly defined: which values are expected, which are mandatory, and what formats are valid. Error cases must also be described so the LLM knows how to respond when a call fails.

Example:

❌ Poor tool description:

Name: search_customer

Description: Searches for customers

Parameter: query (string)

✅ Good tool description:

Name: search_customer

Description: Searches for a customer by name, email, or customer number.

Returns customer data including contract status and last interaction.

Use this when you need specific customer details.

Parameters:

– search_term (string, required): Name, email, or 8-digit customer number

– field_type (string, optional): “name”, “email”, or “customer_number” – improves search accuracy

Errors:

– “no_match”: No customer found. Ask the user for more details.

– “multiple_matches”: Multiple customers match. List the results and ask for clarification.

The difference isn’t cosmetic—it’s functional. With the first description, the AI might pass incorrect parameters, fail to handle errors, and guess when faced with ambiguity. With the second, it operates precisely, proactively, and resiliently.

Tool design for agents is a new craft: a blend of API design and UX design—except the user is an AI.

Dimension 2: Data Accessibility – Can the Agent Access the Right Data?

The smartest agent is useless if the data it needs is trapped in silos it can’t reach.

Common Data Barriers

Barrier	Impact on the Agent
Data stored in Excel files on network drives	Agent can’t access it—no API available
Customer data spread across three systems	Agent can’t provide a unified answer
Documents as scanned PDFs	Agent can’t read the text directly
Legacy systems without APIs	Agent can only access them indirectly
Poor data quality (duplicates, inconsistencies)	Agent works with incorrect data → unreliable results

What Agent-Readiness means here:

Data must be machine-readable and accessible. This sounds obvious, but in many companies, it’s the biggest bottleneck.

RAG (Retrieval-Augmented Generation) can bridge the gap for unstructured data (documents, manuals, wikis)—but only if: A functional vector database exists, Documents are current and well-structured, Metadata is available.

Data quality is agent quality. An agent working with outdated or contradictory data will produce outdated or contradictory results. Data maintenance isn’t made obsolete by agents—it becomes more important.

If a human takes 10 minutes to find a piece of information, how long does the agent take? If the answer is “longer” or “never,” the problem isn’t the agent.

Dimension 3: Access Control – Is the Agent Permitted to Do What It’s Supposed to Do?

Agents need access—but not to everything, and not with admin-level permissions. The principle of least privilege applies especially to them.

Permission Models for Agents

Right Type	Wrong	Right
Data access	Agent has access to all customer data	Agent sees only data relevant to the task
Actions	Agent can send emails to anyone	Agent uses only predefined distribution lists
System access	Agent has admin rights in the CRM	Agent has a dedicated service account with restricted permissions
External APIs	Agent can call any external API	Agent uses only approved, vetted APIs

Service Accounts for Agents

Agents should have their own identities—not those of human employees. This enables:

Auditing: Every action is traceable to the agent.
Permission scoping: The agent gets only the rights it needs for its task.
Deactivation: The agent can be shut down without affecting human users.
GDPR clarity: It’s obvious that a machine is accessing data.

Human-in-the-Loop as a Business Requirement

Not every action should be autonomous. The decision about which actions are autonomous and which require human approval is a business requirement—not a technical one.

Action	Autonomous?	Reasoning
Retrieve customer data	✅ Yes	Read-only access, low risk
Send standard email	✅ Yes	Predefined templates, vetted
Process customer refund	❌ No	Financial impact
Change contract terms	❌ No	Legal relevance
Escalate incident to support	✅ Yes	Time-critical, clear process

This classification can’t be made by a tech team alone. It requires input from the business to define: Where is the risk acceptable? Where do we need human oversight? What happens if the agent operates in a gray area?

Dimension 4: Observability – Do We Know What the Agent Is Doing?

An agent may execute hundreds or even thousands of actions per day. Without traceability, this becomes a black-box operation—and that’s unacceptable.

Three Levels of Traceability

Level 1: Logging – What happened?
Every tool call is logged: which tool, what parameters, what result. Every reasoning step is stored: what did the agent consider before acting? Include timestamps, duration, and token usage per step.

Level 2: Monitoring – Is everything running normally?
Success rates of tool calls, average task duration, error rates by tool and task type, cost per task, escalation rate (how often human intervention is needed). Signal: If a tool suddenly fails more often, it’s a red flag.

Level 3: Auditing – Why did something happen?
Complete decision chains for every task. Traceability: Which input led to which action? Comparison: Did the agent solve the task? Does the result meet expectations?

What Good Agent Logging Looks Like

The difference between:

“The agent sent an email.”

And:

“On May 15, 2026, at 14:32, the agent sent an email to kunde@example.com with the subject ‘Your inquiry about order #4821’—because in Step 3 of the ReAct cycle, the load_order tool returned a status of ‘in progress,’ and the agent decided the customer needed to be notified.”

This level of detail is what makes auditing meaningful. Without it, the agent remains a black box—and black boxes have no place in production systems.

Dimension 5: Accountability – Who Is Responsible If Something Goes Wrong?

Agents make decisions and take actions. When something goes wrong, who is accountable? The answer is clearer than many think—and more uncomfortable than many hope.

The Three-Layer Model

Layer 1: The Model Provider (OpenAI, Anthropic, Google) is responsible for the quality and safety of the base model. However, model providers don’t know your company’s context. They don’t guarantee correct behavior in every application.

Layer 2: The Platform Team is responsible for tool design, guardrails, permissions, and monitoring. This is the bridge between what the model can do and what the agent is allowed to do in your company’s context.

Layer 3: The Business Domain is responsible for defining the task, approving actions, and validating results. The model delivers; the business decides.

The Uncomfortable Truth

An agent is not an autonomous actor. It’s a tool built, configured, and monitored by humans. Accountability always lies with the people who deploy it—not the AI.

Regulatory clarity confirms this:

The EU AI Act defines responsibilities for AI system deployment. The agent has no legal personality—the liability remains with the company. Companies that don’t document a clear strategy for agent deployment today will face compliance headaches tomorrow.

Dimension 6: Team & Processes – Who Builds, Maintains, and Improves the Agent?

Agents aren’t a one-time development project. They require continuous care, improvement, and adaptation. Most companies drastically underestimate this effort.

Three Roles Every Agent Project Needs

Role	Responsibilities	Typical Profile
Agent Developer	Builds the agent, writes prompts, integrates tools	Software engineer with LLM experience
Agent Operator	Monitors operations, analyzes logs, intervenes when errors occur	IT operations with AI understanding
Domain Expert	Defines tasks, evaluates results, provides domain knowledge	Business domain expert familiar with the process

Most common mistake: Developers build an agent without deep understanding of the business process. The result works technically but fails in practice. Collaboration between developers and domain experts is critical—and it takes time that’s often missing from project plans.

Processes That Must Be Established

Agent Lifecycle Management: From definition to development, testing, staging, deployment, and monitoring—agents need structured processes like any other software product.

Prompt Review: Prompts are code. They must be versioned, tested, and reviewed. A changed prompt can radically alter an agent’s behavior—for better or worse.

Tool Review: Every new tool changes the agent’s capabilities. New tools must be vetted: What could go wrong? What guardrails are needed? How does the agent respond to unexpected behavior?

Regular Evaluation: Agent performance evolves due to model updates, changing data, or new requirements. Regular testing with real-world tasks is not optional.

The Agent-Readiness Check: A Pragmatic Self-Assessment

Dimension	✅ Agent-Ready	⚠️ On the Way	❌ Not Ready
Tool Infrastructure	Most systems have well-documented APIs	Some APIs exist but are poorly documented	Most systems lack APIs entirely
Data Accessibility	Data is structured and machine-accessible	Some data is accessible; others are siloed	Data trapped in Excel, scanned PDFs, or legacy systems
Access Control	Service accounts with least privilege in place	Permission models exist but not for agents	Shared admin accounts
Observability	Full logging and monitoring of agent actions	Logging exists but lacks agent-specific analysis	No systematic logging
Accountability	Roles and responsibilities clearly defined	Points of contact exist but no formal processes	No explicit accountability
Team & Processes	Dedicated team with structured processes	Some staff involved, but as a side task	No personnel assigned

Rule of Thumb: If fewer than three dimensions are rated “✅ Agent-Ready,” focus first on infrastructure—not the agent. An agent built on weak foundations will fail. But investments in infrastructure pay off beyond agents, benefiting the entire digital transformation.

Outlook: Agent-Readiness Is a Maturity Level, Not a Destination

Agent-Readiness isn’t a one-time achievement. It’s a gradual maturity that evolves over time.

The good news: Every improvement to infrastructure benefits not just the agent, but the entire company. Better APIs, accessible data, clearer permissions—these are investments that pay off even without an agent.

Last Updated: May 2026