The rest of this series took AgentCore apart primitive by primitive — Runtime, Memory, Gateway, Policy, Identity, Code Interpreter. This post puts them back together. Once you place AgentCore as a governed server-side hub, the useful question stops being what it lacks and becomes what you assemble on it.
The pattern under every case below is the same: a Bedrock model does the reasoning, and AgentCore holds the operational parts — hosting, session isolation, tool credentials, per-user authorization, memory, observability — so the team building the agent writes the agent, not the infrastructure. That division is the whole value of a harness. Here are four shapes teams are shipping in 2026, and the wiring behind each. Two of them I have wired end to end; the other two are patterns AWS and its customers have published, and I have marked which is which.
1. Agentic analytics: ask a question, get a computed answer
The shape. A user asks a business question in natural language — “which customers churned last quarter and what did they have in common” — and the agent plans the query, runs it against live enterprise data, and answers. The distinguishing property is that the numbers are computed, not approximated by the model.
The wiring. A model plans and generates the query; a semantic or data layer gives it a governed view of the real data; Runtime hosts the agent and manages security. AWS’s own reference for this runs a Strands agent on AgentCore querying a semantic layer across Aurora and Redshift with no ETL, and is explicit about why AgentCore is the runtime: it “bundles inbound auth, hosting, and tool credentials into one managed service.”
I built the computed-answer half of this directly. An agent inside Runtime pulls a dataset, runs real Python in an AgentCore Code Interpreter session, and returns a result derived from the data — I checked it against a known-good computation and it matched exactly, and a tamper test (corrupting the input) changed the output, proving the code ran rather than the model guessing. The lesson that makes this a use case and not a demo: a language model asked to rank or aggregate will produce a plausible answer it never calculated. The Code Interpreter is the difference between a number and a guess.
Where each piece sits: model = plan and generate; Code Interpreter or a data-layer tool = execute; Runtime = host and govern; Gateway = present the data tool; Policy = decide who may ask what.
2. A research copilot: parse, search, summarize
The shape. A domain expert asks a research question and gets a grounded, cited answer — not a paragraph from the model’s training, but a synthesis over a real corpus or index. This is the “deep research” pattern applied to a vertical: legal, scientific, financial, internal knowledge.
The wiring. AWS’s protein-research copilot is the clean template: one Strands agent inside a single AgentCore Runtime orchestrates three tools — a parser that extracts structured search parameters from the natural-language question, a searcher that embeds and runs similarity search against a vector store, and a summarizer that turns results into a cited answer. The reasoning runs on Anthropic Claude Sonnet 4.6 through the Bedrock Converse API; AgentCore handles hosting and scaling, with the container built and deployed via CodeBuild so no local Docker is needed.
The tiering matters here for cost, and it is a pattern I ran in my own build: a cheap, fast model for the routing and extraction steps, a stronger model reserved for the synthesis that earns it. A parser does not need a frontier model; a summary that a domain expert will trust does. Splitting the work across a fast tier and a reasoning tier is how you keep a research agent affordable without dropping quality on the step that counts.
Where each piece sits: fast model = parse and route; reasoning model = summarize; Gateway = the search tool; Memory = carry the research thread across turns; Runtime = host the orchestration.
3. Enterprise workflow automation: a fleet of specialized agents
The shape. A complex, multi-step business process — one that used to need a team of specialists over weeks — is handed to a fleet of agents that orchestrate the workflow autonomously and surface the exceptions a human still has to judge. This is the case with the most at stake and the most governance, because the agents act on systems of record.
The wiring. KTern.AI’s SAP transformation platform is a shipped example that uses six AgentCore capabilities at once: Runtime hosts the agents, Memory preserves project context, Gateway connects the tools, Identity governs access, Observability traces behavior, and Evaluations measures quality. The reported result — from their own production measurements — is SAP project timelines cut 45 percent, discovery and assessment time down 60 to 70 percent, and 90 percent of finance and sales operational exceptions surfaced autonomously. The headline is the fleet, not any single agent: the whole thing runs “without custom agent infrastructure,” because the harness is the infrastructure.
This is the case where the governance primitives stop being optional. When an agent can act on a system of record, per-user authorization (who may trigger what, on which account) and a readable audit trail are not features you add later — they are the reason the workflow is allowed to run unattended at all.
Where each piece sits: models = plan and execute each step; Gateway = the enterprise tool surface; Policy + Identity = who may do what, and as whom; Memory = project state across days; Observability + Evaluations = the audit and quality surface; Runtime = host the fleet.
4. Support triage: route, answer, act — under a policy
The shape. Inbound support tickets are classified, the routine ones answered directly, the hard ones escalated, and a resolved ticket can trigger a real action — a refund, a credit — but only within limits a human set. This is the case I built most completely, so it is the one I can describe from the run rather than the docs.
The wiring, as I ran it. A two-tier agent inside Runtime: a fast model classifies each ticket and answers the simple ones; a stronger model handles the escalations. When a ticket calls for an action, the agent calls a refund tool through a Gateway, forwarding the caller’s identity — and a Cedar policy on the gateway decides. In my run, a $450 refund was permitted and executed; a $600 refund was denied by default; and both decisions were visible in the policy engine’s metrics as allow and deny counts. The same agent also reached a managed search connector by signing as its own execution role, to ground answers that needed current facts.
The point of this case is the combination: the model decides what to do, and AgentCore decides whether it is allowed. The refund amount is an argument the policy can read, so “this agent may issue refunds under $500, acting as this user, and no other” is enforced at the gateway, outside the agent’s own code. That is what makes an acting agent safe to ship — the authorization does not live in the prompt.
Where each piece sits: fast model = classify and answer simple; reasoning model = handle escalations; Gateway = the action tool and the search connector; Policy = the refund limit; Identity = the agent acts as the caller for the action and as itself for search; Runtime = host it; Memory = recall a returning customer.
The through-line
Four different products, one assembly. In every case the model is the part that reasons and the harness is the part that hosts, remembers, authorizes, and observes. What changes between an analytics agent and a support agent is which primitives you switch on and how you wire them. The analytics case leans on Code Interpreter; the workflow case leans on Policy and Evaluations; the support case leans on the gateway-plus-Cedar seam. The harness is the same body; each use case uses a different set of muscles.
That is the payoff of placing AgentCore correctly. Once it is a governed server-side hub rather than a client library, “what do I build on it” has a clean answer: describe the agent, switch on the primitives the job needs, and let the managed parts be managed.
So what
If you are choosing between hand-wiring these primitives yourself and adopting the harness, the deciding question is how much of the operational surface you want to own. For a single agent doing one thing, hand-wiring is fine. The moment you have a fleet, or an agent that acts on a system of record, or a returning user whose context has to survive the session, the operational parts — isolation, per-user authorization, memory, audit — are the hard part, and they are exactly what the harness manages. The model was never the bottleneck. The wiring around it was.
The open question I am still holding: every case above is a single-agent or single-fleet shape. The multi-agent pattern — agents that hand off to each other over A2A, each with its own identity and policy — is the one I have not built yet, and it is where the authorization model gets genuinely harder. That is the next thing to wire.
Part of a series working through Amazon Bedrock AgentCore by building on it. Start with The AgentCore Map, then Where AgentCore Sits in the Architecture. The mechanics behind the cases above: AgentCore Runtime, Two Ways to Authorize an Agent Tool, Who May Call What, and AgentCore Memory.