Part 25: Build 5b — AWS: AgentCore runtime, identity and Step Functions approval (with scores)

Part 25 · One Agent, Five Platforms

Part 24 put the nine tools behind one AgentCore Gateway, with Lambda and process APIs behind it. This part builds the agent on top: the last build, AWS-native, with Lambda and Step Functions doing the work around the agent. It covers AgentCore Runtime, identity and memory, the approval in Step Functions, observability, evaluation, and AWS's provisional scores.

It's documentation-only, like the other four builds. Everything below comes from the AWS documentation as I read it on 14 November 2026, linked in the text.

How the pieces map

Using the five layers from Part 3:

• Channel: the AP exception queue, and an approval page for approvers.
• Agent: the invoice agent in AgentCore Runtime, with its own workload identity.
• Tools: the nine tools from Part 24, behind AgentCore Gateway, with Policy checking each call.
• Process layer: process APIs and Lambda functions, with the rules and the approval_id check.
• System of record: the ERP, reached only through process APIs.

1. The agent in AgentCore Runtime

The Runtime page describes a serverless host for agents built with any framework, such as LangGraph or Strands, and any model:

• Isolation: each session runs "in a dedicated microVM with isolated CPU, memory, and filesystem resources", and the microVM is terminated afterwards.
• Duration: sessions run for up to 8 hours on microVMs, or up to 14 days on the Instances compute type. One invoice exception needs minutes.
• Protocols: HTTP and WebSocket, plus MCP and A2A.

Versioning is the clearest of the five platforms. Every update creates a new, immutable version. A DEFAULT endpoint follows the latest version, and named endpoints stay on the version you point them at: dev, staging and production. That's exactly what Part 9 needs, because a new prompt or model resets the evidence, and production shouldn't move until it's been earned again.

Following Part 2, rules still run first. The process layer does the three-way match and duplicate check, and only real exceptions reach the agent.

2. Identity and memory

Identity is Part 23's AWS lane. The agent has a workload identity, the runtime assumes an IAM execution role with a permission boundary, and inbound calls use either IAM or a JWT from your identity provider. Two things from Part 23 to carry into the build:

• Deny the API that issues tokens for an unverified user ID in production.
• The approver's identity comes from the approval, never from the agent.

Memory. AgentCore Memory has short-term memory for "turn-by-turn interactions within a single session" and long-term memory that "automatically extracts and stores key insights" across sessions.

For this agent, I'd use short-term memory only. Each exception is its own session. Long-term memory could be useful later, for example to remember that a supplier often sends duplicates. But the facts that decide a posting must come from the tools, every time. A remembered fact is not a control.

3. The approval in Step Functions

Step Functions has the right primitive. The callback pattern pauses a task until something calls SendTaskSuccess or SendTaskFailure with the task's token. It's available in Standard workflows, not Express.

The flow, continuing from Part 24:

1. request_approval starts a Standard workflow and returns at once with a pending status.
2. The workflow's approval task waits with .waitForTaskToken and notifies the approver.
3. The approver signs in to an approval page and approves or rejects. A small Lambda function records who decided and calls SendTaskSuccess or SendTaskFailure.
4. The workflow writes the decision as an approval_id, as Part 6 requires.
5. Later, post_invoice_adjustment sends the approval_id, and the process API checks it. No valid approval, APPROVAL_MISSING.

AWS's own human approval tutorial is a useful starting point and a useful warning. It sends Approve and Reject links by email. But it's a demo:

• The links are unauthenticated. Anyone with a forwarded email can approve.
• The task token travels in the URL and is written to logs.
• It doesn't record who actually clicked, only the address the stack was set up with.

For finance, each of those would fail an audit. So: an authenticated approval page, tokens kept out of URLs and logs, SendTaskFailure for rejections, a timeout with a Catch, and the approver's identity stored with the decision.

Policy adds a second gate. As Part 24 described, AgentCore Policy checks every tool call at the gateway against Cedar rules, such as an amount limit on post_invoice_adjustment. It sits in front of the approval_id check. It doesn't replace it.

4. Observability and evaluation

Observability. AgentCore Observability emits OpenTelemetry-compatible telemetry and shows it in Amazon CloudWatch dashboards, with session count, latency, duration, token usage and error rates, and traces of each step. One gap: the page says CloudTrail audit coverage currently applies to Gateway and the Agent Registry only.

Evaluation. This is where AWS comes closest to the golden set from Part 10. AgentCore Evaluations scores traces with built-in and custom evaluators, online or on demand. The ground truth page lists evaluators that take expected results:

• Builtin.Correctness compares a response with an expected answer.
• Builtin.GoalSuccessRate checks natural-language assertions about a session.
• Three trajectory evaluators compare the tools the agent called with an expected list, from exact order to any order.

The trajectory check is what Part 10 asked for: did the agent call the right tools? Remember Part 24's naming detail, though. The expected list has to use the gateway's prefixed tool names.

Provisional scores

Documentation-only scores are capped at 4. Blank means no evidence in what I read, as Part 5 requires.

1. Tool exposure (MCP): 4. One gateway, one MCP server, strict schemas. How errors reach the agent is still unconfirmed.
2. Agent build experience: blank.
3. Multi-agent and A2A: 3. Runtime hosts A2A servers with an agent card, and Gateway can proxy A2A services. The page doesn't state which A2A protocol version is supported.
4. Human-in-the-loop: 3. A strong callback primitive, but the approval page, the approver's identity and the audit are mine to build. The official tutorial skips all three.
5. Identity and access: 4. Workload identity, IAM roles with boundaries, token vault and on-behalf-of exchange (Part 23).
6. Governance and gateway: 4. Policy with Cedar at the gateway, generally available, plus gateway authorizers.
7. Observability: 4. OpenTelemetry traces and CloudWatch dashboards, including tokens and errors. CloudTrail coverage is partial.
8. Evaluation support: 4. Built-in, custom and ground-truth evaluators, including tool trajectories.
9. Deployment and CI/CD: 4. Immutable versions and named endpoints per environment.
10. Cost transparency: 3. Consumption-based Runtime billing and token metrics. Cost per outcome is still something you assemble.
11. Data residency and on-prem: 3. VPC networking for Runtime, and Instances in your own account. I didn't check where model processing happens for each model.

That's ten scores, averaging 3.6, level with Azure. MuleSoft averaged 3.3, Boomi 2.8 and SAP 3.0. As with Azure, part of that comes from AWS documenting more, which is fair to reward but isn't a hands-on result.

Where this leaves the five builds

All five platforms can host the same nine tools and the same approval rule. AWS's strengths are versioning, evaluation and a policy engine at the gateway. Its gap is the human step: the primitive is there, the approval experience isn't.

Part 26 puts the five builds side by side, with no winner yet.

AWS users: AgentCore or your own runtime?

This series describes a reference build on a fictional company. This part is based only on AWS documentation as of 14 November 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.