The shift from AI assistants that generate text to AI agents that take actions is forcing engineering teams to rethink how they build and deploy systems. Three recent stories from AWS, Deutsche Telekom, and security researcher Duncan Greatwood show the same pattern. Agent reliability depends on structured evaluation pipelines. Agent security depends on identity governance. And both require infrastructure that does not exist in most organizations today.
I want to walk through what these stories reveal about production agent behavior, where the failure modes live, and what you can actually do about them.
The two-phase evaluation blueprint from AWS
AWS published a detailed blueprint for evaluating AI agents using the Strands Agents SDK and Amazon Bedrock AgentCore. The key idea is a two-phase strategy that separates build-time testing from production monitoring.
The Motorway case study is the most concrete example. Motorway built a dealer stock search agent that exposes eight tools for filtering across 89 vehicle attributes, with vector similarity search powered by LanceDB and Amazon Titan Text Embeddings V2. During peak hours, the agent handles around 1,500 concurrent users. A tool selection error or misinterpretation of a semantic search directly impacts user trust.
The AWS blueprint defines a three-layer evaluation framework. Layer 1 checks tool usage, with a pass threshold above 95 percent. Layer 2 assesses reasoning, threshold above 85 percent. Layer 3 measures output quality, threshold above 90 percent. All three layers must pass before deployment. If one fails, the pipeline stops.
The companion repository uses a run_all_layers() function that accepts a num_trials parameter. Running with num_trials=5 gates deployment on a metric called pass^k. This matters because LLM outputs vary between runs. A 75 percent per-trial success rate means only 42 percent reliability across three consecutive runs. AWS recommends pass^k to catch non-deterministic failures.
I find this practical because it acknowledges that single-trial results are misleading. Most teams I talk to run one test, see it pass, and ship. The AWS approach forces you to measure consistency, not just correctness.
The deployment pipeline has five phases. Build-time evaluation runs unit tests, tool correctness graders, and LLM-as-judge scoring. Staging validation runs on-demand evaluation against synthetic traffic. Shadow mode processes real production traffic in parallel without user impact, for at least four hours, with a 2 percent deviation threshold that pauses deployment automatically. A/B testing routes 5 percent of live traffic to the candidate agent. Then production rollout with continuous online evaluation.
The results from Motorway are concrete. Tool selection accuracy went from 87 percent to 98 percent. Task completion rate from 82 percent to 96 percent. Context retention in multi-turn conversations from 71 percent to 94 percent. Production incidents dropped from 12 per month to 2. Mean time to detect issues went from a few hours to a few minutes.
The core lesson is that a fluent response does not mean the agent did the right thing. You have to verify tool selection, parameter correctness, reasoning coherence, and consistency across repeated runs.
The security risks agents introduce
Duncan Greatwood's analysis of enterprise security risks for agentic AI covers a different but related set of problems. Agents can take actions, access systems, execute commands, use tools, and interact with SaaS platforms. This creates vulnerabilities that traditional AI assistants do not have.
The highest-risk deployments combine broad permissions, exposure to untrusted input, and autonomous execution. Greatwood lists prompt injection as a foundational vulnerability. Every agent that accepts natural language input and has access to tools or data is susceptible. The attack surface is not just the model but the entire tool ecosystem.
Identity management is a second major risk. Every AI agent is a non-human identity with its own permissions, credentials, and access requirements. As agents proliferate, organizations lose visibility into who (or what) has access to what. Without unique identities for each agent, you cannot audit actions or revoke permissions cleanly.
Greatwood recommends applying Zero Trust principles to agents. Every agent should have a unique identity. Access decisions should consider context, risk, and the principle of least privilege. Governance should extend to external tools, plugins, MCP servers, APIs, and integrations. Organizations should inspect agent inputs and outputs for signs of prompt injection, enforce policies governing tool usage, and monitor runtime environments.
I think the most underappreciated point is that agents create a growing population of non-human identities with persistent access. Shared credentials and unmanaged service accounts make it hard to enforce policies. The Xage Zero Trust for AI approach tries to address this, but what matters is whether your organization has the infrastructure to manage agent identities at scale.
Deutsche Telekom's sovereign platform
Deutsche Telekom built LMOS, an internal platform for building and scaling AI agents across multiple countries. The platform powers Frag Magenta OneBOT, a customer-facing assistant for sales and service across Europe. Today LMOS supports millions of interactions.
The architectural decisions are worth examining. LMOS uses Arc, a Kotlin-based framework for defining agent behavior through a domain-specific language. Engineers build agents using APIs and libraries they already know. Arc also introduces ADL, which lets business teams define agent logic and workflows directly.
For retrieval, Deutsche Telekom built Wurzel, an open-source Python ETL framework for RAG. They chose Qdrant as the vector database, an open-source Rust-based system that supports multitenancy and metadata filtering. This allowed them to segment datasets by country, domain, and agent type.
The platform abstracted away lifecycle management, deployment models, classifiers, observability, and scaling. The team describes it as a Heroku-like experience for agents. Agents are deployed to Kubernetes environments via LMOS, which handles versioning, monitoring, and scaling.
The results are notable. Development time for a new agent dropped to a day or less. Handover to human support for API-triggering agents is around 30 percent. The team believes LMOS is one of the first multi-agent platforms to go live, with planning beginning before OpenAI released its agent SDK.
I find the open-source and sovereign aspects interesting. LMOS is built on Kubernetes and open standards, providing portability across developer machines, private clouds, and data centers. The team specifically wanted to avoid dependency on closed third-party platforms. This matters for organizations with regulatory constraints or data residency requirements.
Connecting evaluation, security, and platform design
These three stories converge on a few points. Evaluation cannot be an afterthought. AWS showed that layered evaluation with pass^k gates catches failures that single-trial tests miss. Deutsche Telekom built observability and versioning into their platform from the start. Security cannot be retrofitted. Greatwood's analysis shows that agents with broad permissions and untrusted input are recipes for compromise.
If you are building production agents, here is what I think you should take away.
Build evaluation into your CI/CD pipeline. Use multiple trials, not single runs. Measure tool selection accuracy, reasoning coherence, and output quality separately. Set thresholds that block deployment when metrics fail.
Give every agent a unique identity. Monitor what tools and data it accesses. Rotate credentials. Apply the same access controls you use for sensitive human roles.
Choose a platform that abstracts operational complexity. Deutsche Telekom spent significant effort on infrastructure so that engineers could focus on agent behavior. You do not need to build your own LMOS, but you need something that handles deployment, versioning, monitoring, and scaling.
Start with shadow mode. Real production traffic reveals timeout handling, rare terminology, and latency patterns that synthetic tests miss. Run shadow mode for at least four hours. Set a deviation threshold that pauses deployment.
The Motorway example shows that getting agent behavior right improves user trust. The Deutsche Telekom example shows that platform investment reduces development time. The security analysis shows that ignoring identity and governance creates risk. None of these are optional. They are the minimum requirements for production-ready AI agents.