AgentCore vs Reality: Lessons from Building Production AI Agents on AWS

I attended a talk at the AWS AI In Practice community event in London last month that delivered something rarely heard in hype-driven AI circles: brutal honesty about what happens when you deploy autonomous agents to production. The incident investigation use case presented provides a masterclass in why building reliable agents is fundamentally a software engineering problem, not a model selection problem.

Marina's team set out to build an agentic system that monitors live applications, autonomously investigates incidents, attempts safe remediation, and sends investigation reports. The vision is compelling: reduce alert fatigue and incident response time. The reality, after two weekends of debugging, was quite different.

The presentation slides literally say "agentcore create, agentcore deploy" followed by "... 2 weekends later ..." and then a flood of red text detailing everything that went wrong. That gap between the quickstart tutorial and production reliability is where the actual engineering lives.

Choosing a model for AgentCore is not a simple task. The team discovered that decision-making requires weighing multiple competing concerns: default model options, access approval requirements, inference profiles, tool support, cost, and latency.

Some Bedrock models do not support tool use at all. Anthropic models require additional approval processes. The AgentCore framework was silently defaulting to Anthropic models despite being configured otherwise. Tool support varies significantly across model families, and this limitation directly bounds what the agent can accomplish, regardless of prompt quality.

The lesson: evaluate models empirically with your actual data and tool set before committing to production. A model that looks good in benchmarks might lack tool-use capability or require approval workflows that delay deployment.

This is the uncomfortable truth few practitioners admit. AgentCore makes Python assumptions, requires specific UV configurations, and the CDK schema documentation mismatches cloud reality. Deployment failures happen silently. The CLI tooling contains bugs. Documentation is sparse and community support limited.

The team encountered situations where agentcore deploy failed but cdk deploy succeeded. Local state disagreed with AWS reality. Runtime environments couldn't write to application directories. Environment variables disappeared after deployment.

This is not a criticism of AWS, it's a realistic assessment of a nascent service. If you're considering AgentCore, budget extra engineering time for infrastructure debugging alongside agent development. The technology works, but expect friction on the path to production.

This insight reshapes how you should think about agent capability. The agent is only as intelligent as its toolkit allows. When tools are insufficient, the agent produces generic responses. When tools are excessive, the agent hallucinates tool usage and invokes actions when none are needed.

AgentCore's boilerplate includes an MCP server pre-loaded with tools. The pattern observed is that "if an agent has tools, it will find a way to try to use them." The implication: tool selection is a critical design decision, not an afterthought.

In the incident investigation scenario, the agent needed precise tools for infrastructure queries, log retrieval, and safe remediation checks. Each tool's schema mattered enormously. inputSchema and parameters are not interchangeable. Poorly defined schemas led to the agent making up tool invocations that didn't exist.

Model behaviour in agentic loops differs markedly from single-turn interactions. The agent summarises findings prematurely. It draws conclusions before gathering sufficient evidence. It exhibits overconfidence in incomplete investigations.

These behaviours stem from how language models optimise for next-token prediction. Agents running in loops amplify this effect. Prompt engineering alone cannot fix this. The solution: make the desired reasoning process explicit in the prompt rather than leaving it to the model to infer. Specify investigation steps, evidence-gathering phases, and synthesis rules as constraints.

This is a critical shift in perspective. The agent attempted unnecessary remediation actions. Telling it via prompt not to do something was insufficient. Safety policies had to move into the tool implementations themselves.

If a remediation tool should only run during business hours, that logic lives inside the tool, not in the system prompt. If an action requires human approval, the approval gate sits in code. This follows the principle of defence in depth: guardrails at multiple layers.

Bedrock Guardrails do not solve most operational problems. They provide filtering but not the domain-specific logic needed to prevent unsafe agentic decisions.

The agent claimed to have checked infrastructure, logs, and tools that didn't exist or were never called. This created a dangerous audit trail: investigation reports documenting checks that never happened.

The solution is architectural: investigation timelines, timestamps, and audit traces must be kept outside the agentic loop. Agents should investigate and propose findings, but deterministic software must maintain the integrity of the audit trail. You cannot trust the agent's narrative about what it did; you need external logging of actual invocations.

This is perhaps the most important lesson. The quality of investigations depended far more on available observability (execution traces, tool call history, investigation timelines, invocation logging, evaluation datasets) than on model intelligence.

Building an agent is not a model problem. It is an observability problem. You need complete visibility into what the agent attempted, what tools it called, what data it received, and how it reasoned. Without comprehensive logging, you cannot debug failures, evaluate performance, or audit decisions.

Invest heavily in execution traces and tool call history. These become the primary artefacts for agent improvement. Evaluation datasets emerge from real invocation logs. This is unglamorous engineering work, but it is what separates production-ready agents from research prototypes.

Lambda functions have a 30-second timeout. Agents investigating incidents may need much longer. AgentCore runtime allows yielding an immediate response to the caller while the agent continues in the background.

This architectural decision cascades throughout the system. Someone must manage incident state. Opening incidents before the agent successfully invokes creates deadlocks. Monitoring and investigation concerns must be separated. Clear ownership of responsibilities prevents duplicate invocations and protects against agent failures.

Marina's key lesson: put critical operational state under deterministic software control. Let the agent investigate and propose remediation, but do not make it responsible for guaranteeing system reliability itself. The agent is an investigator and advisor, not an autonomous decision-maker in critical paths.

Agents running in loops until they reach a goal create new attack surfaces. Log data becomes an injection vector. Tool allow-lists become essential. Cost can spiral if the agent loops indefinitely.

Mitigation strategies include IAM-scoped invocation permissions, tool allow-lists, remediation policies inside tools, human approvals for dangerous actions, and Bedrock Guardrails for additional filtering. But none of these are zero-effort. They require thoughtful policy design and careful implementation.

The agent will exploit whatever surface area you leave exposed. Security is not a guardrail you add at the end; it is woven into tool design, permission scoping, and loop termination logic.

The core principles distilled from this experience are:

The final insight: agents are powerful tools that require substantial software discipline to deploy safely. The AI component is perhaps 20% of the work. The remaining 80% is infrastructure, observability, security, and deterministic control logic.

If you are considering agentic systems for production workloads, the lessons here are practical:

Evaluate tool availability first. Sketch the tools your agent will need and validate that they can be implemented correctly. Tool design is agent design.

Plan for observability from day one. Logging, tracing, and evaluation datasets are not add-ons; they are prerequisites for debugging and improvement.

Separate agentic and deterministic concerns. Agents are excellent at investigation and recommendation. Deterministic software is excellent at state management and policy enforcement. Hybrid architectures are more reliable than fully agentic ones.

Budget extra time for infrastructure and deployment. New services like AgentCore have friction. Plan accordingly.

Start with clear success criteria. What does a successful agent look like in your domain? For incident investigation, success is accurate reporting and safe remediation, not maximum autonomy.

The AWS AI In Practice presentation lands at a moment when AI enthusiasm often outpaces engineering discipline. This work demonstrates that building production agents requires serious software engineering: careful architecture, comprehensive observability, layered security, and honest assessment of what the agent should and should not do.

The incident investigation system works. It reduces human toil and accelerates response. But it works because of disciplined engineering, not because the model is intelligent. That distinction matters as agentic systems become more prevalent.

If you are building agents on AWS, the lessons shared here-hard-won over two weekends of debugging are worth internalising. The path from "AgentCore create" to reliable production systems runs through software engineering fundamentals.