Source linked

Eight Hard Lessons from Building a Production AI Agent on Bedrock AgentCore

hackernoon.com@systems_wire2 hours ago·Systems Engineering·1 comments

Most engineering effort went into deterministic system design, not AI reasoning - a senior engineer shares concrete failures and fixes from an incident-response agent built on AWS.

amazon bedrock agentcoreawsincident response agentagentic aiamazon novaprompt injection

Most of the engineering effort for a production AI agent goes into designing deterministic systems around the model, not into “working on AI” itself. That’s the blunt takeaway from a senior engineer who spent months building an incident-response agent on Amazon Bedrock AgentCore — and documented eight concrete realities that cropped up along the way.

The agent monitors production workloads via EventBridge and Lambda, checks Elastic Beanstalk and CloudWatch logs, and can restart servers. The author chose Amazon Nova for its tool-use support, direct invocation, and no additional approval process, but the selection process itself was the first trap: not all models support tool use, some require inference profiles rather than direct invocation, and access isn’t always immediate.

Deployment Tooling Expects Python, Not TypeScript

AgentCore CLI makes creating an agent trivial — agentcore create and follow prompts. But deploying with agentcore deploy assumes a Python environment. The author’s project used the TypeScript SDK, requiring brew install uv and additional tooling. Even then, deployment failed with a CloudFormation schema mismatch because the CLI generated one version of CDK assets while the deployment tooling expected another. The workaround: bypass the abstraction and deploy directly using AWS CDK. The lesson: new services ship with rough edges, and debugging vague errors takes longer than with established services.

Agent Intelligence Is Bounded by Its Tools — But Too Many Tools Cause Hallucinations

With only a few tools (check frontend/backend reachability), the agent produced generic chatbot-style reports. Adding tools to inspect Elastic Beanstalk health, Lambda logs, and failure details dramatically improved investigation quality. But more tools introduced a new problem: logs showed the agent calling tools the author never added — web_search_ext — because the bootstrapped AgentCore project came with a preconfigured MCP server exposing extra tools. Tool selection is as critical as model choice.

Premature Synthesis and the Safety Trap

The agent would find the first issue (frontend down), declare root cause, and stop investigating — a behavior called “premature synthesis.” Prompt engineering helped by instructing the agent to check all components before concluding. But prompt engineering failed badly on safety: the agent restarted Elastic Beanstalk app servers even when the environment was healthy. The fix was moving safety checks into the tool code itself — deterministic policies that reject restart requests on healthy environments regardless of what the model decides.

Hallucinations Poison Audit Trails — Record Them Deterministically

Comparing investigation reports with execution traces revealed the agent claiming it had checked security groups, network ACLs, and web server logs — none of which existed as tools. The solution wasn’t to eliminate hallucinations (impossible in a probabilistic system) but to record tool invocations, timestamps, and results deterministically at the application layer. The agent only interprets those results. Functions that require correctness or auditability belong in traditional software, not in the model’s reasoning path.

Observability Is Mandatory; Security Changes Shape

Two investigations of the same incident can produce different tool sequences, reasoning paths, and conclusions. Without recording tool execution history and Bedrock invocation logs, debugging is guesswork. On security: agents introduce new attack surfaces — prompt injection can come from application logs the agent reads, and without explicit execution limits, a single invocation can burn unlimited compute and cost. The author implemented least-privilege IAM, tool allow lists, deterministic remediation policies, max call counts, duration limits, and Bedrock Guardrails.

The bottom line: AgentCore delivered a managed runtime, but building a reliable, secure, observable production agent is overwhelmingly a software engineering problem — not an AI problem.


Source: Amazon Bedrock AgentCore vs Reality
Domain: hackernoon.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.