Building agentic AI on AWS with Amazon Bedrock AgentCore

For most of the past year the industry's running joke has been that standing up an AI agent takes about thirty seconds and getting one into production takes about thirty weeks. Amazon Bedrock AgentCore is AWS's answer to that gap. When it reached general availability in October 2025, AWS positioned it not as another model or agent framework but as the managed plumbing underneath agents built in any framework ^[1]. The service is deliberately modular: Runtime hosts the agent, Gateway turns existing APIs and Lambda functions into agent-callable tools, Memory persists both session and long-term context, Identity handles user-to-agent and agent-to-tool authentication, and Observability makes each run auditable.

The technical detail that matters most is Runtime. Each agent session gets its own isolated microVM - the same isolation model AWS uses to keep one customer's workload from touching another's - and a session can run for up to eight hours, long enough for the kind of multi-step, tool-heavy work that shorter serverless timeouts choke on ^[1]. On developer forums the mental model that keeps surfacing is 'Lambda for agents': you bring the agent logic written in Strands, LangGraph, or CrewAI, and AgentCore runs it. That shorthand is doing a lot of work, because it also points straight at the most common source of confusion, which a later section takes up directly.

The quietly important claim in AWS's own writing on AgentCore is that the difficult part of an enterprise agent is no longer the foundation model - it is the data the model has to reason over. AWS's reference architecture pairs AgentCore with Stardog's semantic layer, a knowledge-graph engine that sits over Amazon Aurora (the operational database) and Amazon Redshift (the analytical warehouse) and lets a Strands agent answer customer-360 questions spanning both without any extract-transform-load pipeline ^[2]. Rather than copying data into a third store, Stardog uses virtual graphs: it maps each system's records to shared business concepts through ontologies - formal definitions of what a 'customer' or an 'order' actually is - then translates the agent's SPARQL graph queries into the underlying SQL on the fly.

Why route this through AgentCore at all? Because the semantic layer has to be reachable as a governed tool, and AgentCore bundles inbound authentication, hosting, and tool-credential management into one managed service ^[2]. Stardog can be exposed either as a direct SPARQL tool or as a Stardog Cloud MCP server registered behind AgentCore Gateway. The payoff over ordinary retrieval-augmented generation - where an agent searches loose text chunks - is that business rules and graph-level access control are defined once and reused by every agent and tool. An agent physically cannot return a record the requesting user is not allowed to see, and it can assemble one answer from several systems and show which sources it drew on.

If the Stardog architecture is the theory, KTern.AI is the field test. KTern is an SAP-modernization software vendor that rebuilt its platform on AgentCore, deploying more than twenty specialized agents - for reverse-engineering existing SAP systems, forward-engineering new ones, standard adaptation, custom-code analysis, test-case generation, and process and anomaly mining - each defined through configuration rather than hand-written orchestration code ^[3]. The design choice that makes this hold up over the length of a real engagement is memory: SAP transformations run twelve to eighteen months, and AgentCore's managed memory lets an agent carry project context across that span instead of starting cold every session.

The outcomes KTern reports are the reason the topic earns attention, though they are vendor self-reported figures published in AWS's case study rather than independently audited. The company says the platform cut overall project timelines by 45 percent and compressed discovery-and-assessment work - historically the slowest, most manual phase - by 60 to 70 percent ^[3]. Configuration-driven builds dropped each agent's deployment time to four-to-six hours, and the team says it reclaimed roughly 480 engineering hours a month that used to go into managing infrastructure, while holding 99.8 percent agent uptime. Read skeptically, these are exactly the numbers a vendor would headline; read charitably, they point at where agentic automation actually bites in the enterprise - not in writing code faster, but in collapsing the discovery, testing, and coordination overhead that dominates long programs.

Away from the launch posts, the liveliest discussion among engineers is not whether AgentCore is impressive but what it even is. The single most common question from developers evaluating it is how AgentCore differs from Bedrock itself, and the community has settled into a clean distinction: Bedrock is the model-access platform - APIs, guardrails, evaluations, knowledge bases - while AgentCore is a separate runtime for hosting whatever agent you have already built. You bring the framework and the model; it provides the production scaffolding. Practitioners running it in production tend to single out observability as the feature that actually earned its keep, the thing that moved their proofs-of-concept past the pilot stage.

There is a real counter-current too. One well-known cloud-cost commentator argued that AgentCore is more about guardrails than capabilities - the opposite of what he wants when experimenting - and skepticism runs high toward the wave of AI-generated promotional content around the launch. The cost model gives that skepticism something concrete to hold: AgentCore bills as consumption across many independently metered components rather than a single flat rate, with Runtime charged per vCPU-hour and per GB-hour only during active processing ^[4]. Independent analyses count roughly a dozen separately billable components spread across several billing patterns, which makes cost forecasting a real exercise rather than an afterthought ^[5]. The through-line of the reaction is that AWS has bet on selling the unglamorous production layer, and the people closest to shipping agents mostly agree that is where the pain actually is.