Agent-Ready: Why AI is the Least of Your Problems – and Infrastructure is the Biggest Challenge

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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?

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

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?

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.

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.

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.

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.

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

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.

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.

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.

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