Agentic Architectures on AWS: AgentCore, Durable Workflows, and Where Lambda Ends

1. The mapping problem

Across enterprise architecture and regulated-bank delivery, one distinction matters repeatedly: an agent is not a function. Planning, tool routing, memory, session management and a trajectory that may run for seconds or hours do not map cleanly to one AWS compute primitive. A Lambda-only design can look adequate in a demonstration and then fail when a downstream call crosses the fifteen-minute invocation limit. The worked scenario in this article is designed around that failure boundary.

This article is about service boundaries. It covers AgentCore Harness or Runtime for agent execution, Gateway for tools, Identity for credentials and Memory for governed continuity. Policy supplies deterministic Cedar enforcement at Gateway. Observability and Evaluations provide operational and behavioural evidence. Step Functions represents durable business workflow. Lambda and Fargate remain useful for bounded work.

None of what follows is exotic. The difficult part is deciding upfront which primitive owns which responsibility, before the first line of orchestration code is written. A poor boundary accumulates workarounds as traffic and failure paths expand. A sound boundary lets the system scale without moving workflow state, long-running work and business evidence between services under pressure.

2. Bedrock agentcore: runtime, state and orchestration boundaries

Bedrock AgentCore is a modular platform rather than one automatic agent loop. AgentCore Harness is the managed, config-defined loop and the recommended starting point when its orchestration model fits. AgentCore Runtime hosts code-defined agents and tools in isolated microVM sessions. Runtime is framework- and model-agnostic; the deployed code still owns the loop.

Runtime can host LangGraph, Strands, CrewAI or custom code and call Bedrock or other model providers. Gateway exposes APIs, Lambda functions and MCP servers as governed tools. Identity separates workload identity, inbound authentication and outbound credentials.

Policy in AgentCore, generally available since 3 March 2026, evaluates Cedar policies at Gateway before a tool call executes. AgentCore Evaluations, generally available since 31 March 2026, supports on-demand tests and sampled online evaluation. These managed controls do not remove the need to define business authority, evidence thresholds and stopping rules.

Runtime sessions preserve in-memory and filesystem context across invocations while the session's microVM remains active, with configurable lifecycle limits up to eight hours. That state is ephemeral by default. Durable continuation across a stopped compute lifecycle requires configured session storage, AgentCore Memory or an application checkpoint store. Runtime should not be described as checkpointing every turn automatically to durable storage.

AgentCore Memory provides short-term events and long-term records beyond ephemeral compute state. A sound design still distinguishes conversation continuity, resumable workflow checkpoints and learned memory. They have different retention, provenance and deletion requirements. AgentCore Observability emits CloudWatch metrics, logs and OpenTelemetry-compatible traces for Runtime, Gateway and Memory, but telemetry destinations and sensitive-data controls still require configuration.

None of this removes the need for engineering judgement. The agent framework decides tool policy and stopping behaviour. A durable business process may sit above the runtime in Step Functions, especially when it needs external callbacks, explicit compensation or waits that outlive one runtime lifecycle.

3. Step functions for long-running trajectories

A trajectory is the full sequence of steps an agent takes to resolve one task: gather information, call tools, reason about intermediate results, possibly wait on something external, and reach a conclusion. Some finish in under a second. Others, particularly in banking workflows involving approvals, compliance holds, or downstream batch systems, need to span hours or days. Step Functions is the primitive I use to represent these trajectories explicitly, as a state machine, rather than as a sequence of function calls buried in application code nobody can inspect mid-flight.

The core benefit of a Step Functions state machine is that its state becomes a queryable object rather than something inferred from log lines. Every transition is recorded. If a claims trajectory waits for approval, an operator can see its state and next transition. AWS documents a maximum one-year execution for Standard Workflows and 256 KiB input or output for a task, state or execution.

Human-in-the-loop patterns are a strong fit. The waitForTaskToken integration can pause a trajectory, within the workflow limit, until a Lambda function, SQS consumer or approval interface returns the token and result. The state machine does not run task compute while waiting, although normal Step Functions and connected-service charges still apply.

Retry and backoff policy is the second reason to use Step Functions for anything beyond a single tool call. Every state can carry its own retry configuration: a maximum attempt count, a backoff rate, an interval, and a set of error types that trigger retry versus error types that fail immediately into a catch block. For an illustrative call to an unstable internal pricing API, three retries with a backoff rate of two and a one-second initial interval provide a candidate test configuration, while authentication failures enter a distinct catch branch and operational alert. Production values must come from dependency behaviour, idempotency and the journey's latency budget. Encoding this policy once in a state machine avoids reproducing divergent retry plumbing across tool callers.

The trade-off is real: a state machine is not itself where you want to run substantial computation. States invoke other compute, typically Lambda for short synchronous tasks or Fargate for long-running ones, and the machine's job is sequencing, branching, retrying, and waiting, not executing business logic directly. Standard workflows also carry a payload limit of 256 KiB for the input and output of each state. A design that transports document payloads through state can therefore raise States.DataLimitExceeded; the failure-mode section shows the alternative.

4. Where lambda ends

Lambda remains right for most individual steps inside an agent trajectory: a single tool call, a validation function, a formatting step, a call to AgentCore to advance one turn of the model loop. The mistake is using it as the container for the entire trajectory, and four concrete limits mark where that mistake starts to bite.

The first is the fifteen-minute maximum execution time, a hard limit for one invocation. In the worked failure scenario, a claims-verification agent waits through an identity service's retries and then invokes document analysis. Several individually acceptable calls cross the overall limit, and an uncheckpointed trajectory disappears with the invocation.

The second limit is cold-start latency, disproportionately painful for agent workloads because agent runtimes tend to be large. A typical agent Lambda package, once it includes a model SDK, a tool-calling library, schema validation, and internal client libraries, routinely lands in the 200 to 400 MB range once bundled. Cold starts on packages that size, even with provisioned concurrency mitigating some impact, add between 800 milliseconds and 2.5 seconds before the function begins its own work. For one tool call that is tolerable; for a trajectory fanning out to twelve tool-call Lambdas in sequence, each paying its own cold-start tax, the cumulative latency becomes visible to the end user.

The third limit is the 10,240 MB memory ceiling. The worked claims packet assumes six scanned PDFs held alongside OCR text and embeddings, approaching 6 to 7 GB before other runtime overhead. The local measurement, not the document count alone, should decide the runtime.

The fourth is ephemeral storage. Lambda allows /tmp to be configured between 512 MB and 10,240 MB. A document tool that downloads and unpacks bundles needs a measured peak below the configured value and cleanup that does not assume execution-environment reuse.

The pattern is not Lambda under-provisioning. Lambda is the wrong primitive for long, variable work with a large, variable memory footprint. Fargate removes the fixed execution ceiling and lets the task define memory and storage.

The cost profile also changes. Lambda suits frequent short work. Fargate suits a task that runs for minutes with sustained resources. Choose the compute shape from the realistic tail, not the successful median. My working threshold is Fargate when a step routinely exceeds six minutes or approaches 3 GB under realistic load.

5. Event-driven wiring between the pieces

None of AgentCore, Step Functions, Lambda, or Fargate should call each other synchronously across a trust or reliability boundary, because a synchronous call chain means a failure or slowdown in any one component propagates immediately to every component upstream of it. The wiring between these pieces is where EventBridge and SQS earn their place, and getting it wrong is a quieter failure mode than a Lambda timeout, but just as damaging over the following months.

EventBridge is the routing layer for agent-level events: a trajectory started, reached a wait state, completed, or a tool call failed after exhausting its retries. I model these as named event types on a dedicated event bus rather than a general-purpose one, so downstream consumers, a monitoring dashboard, a billing system tracking token consumption, or a compliance system logging decisions for audit, can subscribe only to what is relevant without coupling to the orchestration's internals. A compliance team, for instance, subscribes only to trajectory-completed and human-override events.

SQS sits underneath the tool-call layer, buffering requests to tools that cannot guarantee instant processing. When an agent calls a rate-limited downstream API, or a batch system processing submissions every fifteen minutes, writing the tool call as a queue message rather than invoking it directly decouples the trajectory from the tool's processing cadence. The trajectory sits at a waitForTaskToken state until the consumer calls back with the token once processed. This is the wait-state pattern from section three, but the queue absorbs bursts: if three hundred claims trajectories call the same fraud-check API within the same sixty-second window, the queue holds the backlog rather than the API, or the calling Lambdas, being overwhelmed.

Dead-letter queues are easy to omit when the initial path is tested only for success. In the worked composite, each tool-call queue has a DLQ with a maximum receive count of three, after which a message leaves the primary queue rather than being retried indefinitely or silently dropped. The DLQ emits an EventBridge event to an operational alert and, critically, back to the originating Step Functions execution. Without that link, the composite failure leaves a claims case marked "in progress" until a customer enquiry three weeks later exposes the stalled work. The interval and case are illustrative; the architectural point is that queue failure must become an explicit trajectory state with an owner.

6. Reference architecture

The reference shape separates the agent runtime from durable business orchestration. API Gateway authenticates a request and passes it to agent code hosted in AgentCore Runtime. That code or its framework makes the model and tool-routing decisions. Simple interactions can return directly. A task that needs a long external wait, explicit compensation or a multi-system process can create or advance a Step Functions execution, which dispatches short tasks to Lambda and long or memory-heavy tasks to Fargate.

The detail that does not show up in a diagram this simple is the event-driven wiring described in the previous section, sitting alongside every arrow rather than replacing it: EventBridge carries trajectory-lifecycle events off to monitoring and compliance systems, and SQS with its DLQ sits between the Lambda and Fargate tasks and the tool APIs wherever those tool APIs cannot be trusted to respond within a synchronous request window. I have deliberately left those off the diagram to keep the primary control flow legible; in an actual architecture document I maintain a second diagram purely for the event and queue topology, because showing both in one picture produces something too dense to reason about at a glance.

7. Choosing between lambda, step functions, and fargate

Teams ask me, more than any other question, how to decide where a given agent task should run. Step Functions is not a competitor to Lambda and Fargate in this decision; it is the orchestrator that chooses between them, task by task, based on three properties: expected duration, payload size, and whether the task needs to hold state across multiple external waits. I apply this per task, not once per system, because a single trajectory routinely mixes task types: a fast classification step suited to Lambda, followed by a long document-processing step suited to Fargate, followed by a wait state suited to nothing but Step Functions itself.

Duration is the first filter because it is cheap to estimate and often wrong in practice. Build in margin. An eight-minute estimate belongs on Fargate even when a theoretical Lambda limit appears sufficient. Model latency and downstream jitter make real tails longer than synthetic tests suggest.

Payload size is the second filter. A claims file likely to approach the Step Functions payload limit belongs in S3. Pass only its reference through the workflow. The third filter is state across external waits. Multiple callbacks belong in separate durable states, not inside one Lambda invocation.

8. Failure modes

The worked design concentrates on three recurrent failure modes that can be addressed at design time: lost state at a compute boundary, oversized workflow payloads and incompatible session state during rollout.

The first is a Lambda-hosted agent loop timing out mid-trajectory and losing accumulated state. The symptom is specific: a trajectory stops with only a generic timeout in CloudWatch while a downstream system continues waiting. In the document-heavy underwriting scenario, three sequential calls occasionally exceed nine hundred seconds under load. The fix is architectural: checkpoint after each material step in a durable application store or Step Functions state. AgentCore Runtime's default ephemeral session state is not a substitute for durable workflow checkpointing.

The second failure is the Step Functions payload limit. Small test documents can hide it until production raises States.DataLimitExceeded. A poor patch compresses or truncates claims context merely to fit. The model then reasons from an incomplete file without an explicit risk decision.

Workflow payload is control data, not bulk evidence transport. Put claims files, retrieved documents and large intermediate outputs in S3. Pass object keys, hashes and small summaries through the state machine. Let each authorized state read the full object when required.

The third is session incompatibility during a rollout. AgentCore documents that an existing runtime session continues on the code version with which its microVM was created until that compute terminates. Problems arise when application checkpoints, schemas or tool contracts change without backward compatibility and a resumed session reaches the new release. Version durable state records, support at least one prior schema during the rollout and test stop-resume behaviour explicitly. Session affinity helps while a microVM is active; it does not replace migration design for persisted state.

9. Worked example: a regulated claims-processing estate

The worked composite makes the architecture concrete through first-notification-of-loss claims across three insurance product lines. It uses an intake agent for structured extraction, a verification agent for policy and history checks, a fraud-signal skill model and a settlement-recommendation agent whose proposed payout still requires human review.

At steady state the worked system assumes 14,000 claims trajectories per day across three product lines, with a peak of 2,200 in one hour. The average end-to-end trajectory takes 34 minutes, but the distribution matters. Straightforward claims complete in under 90 seconds and make up 61 percent of volume. A further 24 percent require at least one Fargate-hosted document step, modeled at seven minutes, while 15 percent involve a human wait averaging 6.4 hours. Three percent exceed 24 hours, with an eleven-day modeled tail. These are capacity-planning assumptions, not observed client traffic.

Under those assumptions, 39 percent of trajectories cannot be represented as one Lambda invocation because they are document-heavy or include a long human wait. The percentage is not a platform benchmark. It demonstrates why workload-shape measurement should precede the service decision.

The illustrative monthly cost model assigns $41,000 to model invocation, $3,200 to Step Functions, $6,800 to Lambda, $12,400 to Fargate, $900 to SQS and EventBridge, and $1,100 to S3: $65,400 in total. The model assumes the larger general-purpose model receives only the 18 percent of ambiguous fraud-signal cases. Current regional prices, discounts, token use and task sizes must replace these inputs before a business case is made.

The failure-rate scenario assumes one in 400 document trajectories silently stalls before DLQ-to-trajectory wiring and fewer than one in 20,000 afterward. Those rates are illustrative. The defensible production claim is narrower: wiring the dead-letter event back to the originating execution makes the failure visible and measurable instead of leaving the case in an indefinite in-progress state.

10. Mapping AWS services to agent architecture components

The table below is the summary I hand to teams starting a new agent build, after they have read everything above, as a quick reference for which service owns which responsibility and against which numeric limit.

Notes for practitioners

If you take one idea from this article, take this: decide the compute primitive for each piece of an agent's execution before writing the orchestration code, based on the actual expected duration, payload size, and statefulness of that piece, not on what is easiest to stand up on a Friday afternoon. Lambda is excellent for what it is built for, and I use it constantly for short, well-bounded tool calls and formatting steps. It stops being the right choice the moment a step's realistic duration approaches six minutes, its memory footprint approaches 3 GB, or it needs to survive more than one external wait, and all three thresholds can be estimated honestly before launch rather than discovered under production load.

Build durable checkpointing into every material workflow from day one. Use a configured persistent store or Step Functions state for resumption across compute lifecycles; use Runtime session state only within its documented lifecycle. Externalise large payloads to S3 by default because the Step Functions 256 KiB limit is too small for a claims file, document bundle or long tool history.

Wire your dead-letter queues back to the trajectories that created the messages sitting on them. A DLQ that only triggers a monitoring alert is half a solution; the other half is making sure the trajectory itself transitions to an explicit, visible failure state rather than sitting in silent limbo. Treat session-store schema changes and deployment routing with the same seriousness as a database migration. Otherwise a rollout can quietly orphan active sessions when application checkpoints, tool contracts or runtime versions no longer agree.

Finally, measure the split. Know, with real numbers from your own traffic, what percentage of trajectories are short enough for Lambda alone, what percentage need Fargate, and what percentage need a genuine human-in-the-loop wait measured in hours rather than seconds. The worked claims scenario assumes a 61, 24 and 15 percent split only to make the service decision visible. Production placement should follow the measured distribution rather than the shape of a demonstration.

11. Separate reasoning, workflow and work

Three execution concerns are often collapsed into one container. They should be designed independently. The reasoning runtime interprets evidence. The workflow runtime owns durable state and waits. The work runtime performs bounded computation or calls an external system.

The workflow owns progress; the agent owns interpretation; the tool owns execution. This split makes retries and human waits visible without forcing a model session to remain alive.

12. Failure ownership and compensation

Every asynchronous boundary needs an owner for timeout, retry, duplicate suppression and final failure. A queue does not own the business state. The trajectory must observe the terminal event.

A failed message is an operational fact; a failed trajectory is a business fact. Both must be recorded.

13. A change-risk map

Platform change becomes riskier as state lifetime and external consequence rise. This map helps determine release controls.

The architecture is ready when compute failure, deployment change and human delay all produce explicit business states. The service map then becomes an operating model rather than a collection of AWS icons.

Primary AWS references

• AWS, Step Functions service quotas.
• AWS, Lambda quotas.
• AWS, Amazon SQS dead-letter queues.
• AWS, Using Amazon ECS on AWS Fargate.
• AWS, Amazon Bedrock AgentCore Runtime.
• AWS, Bedrock Agents Classic maintenance mode and migration.
• AWS, AgentCore overview.
• AWS, Policy in AgentCore.
• AWS, AgentCore Evaluations general availability.

Use managed services to make responsibility explicit. Never let their boundaries obscure who owns the trajectory, the decision and the external effect.