Published on

Agents of Change

Authors
  • avatar
    Name
    Benjamin Lee
    Twitter

The old chatbot answered a question and went quiet. The new one books the flight, checks the weather, changes its mind, and phones a colleague. Someone has to run the machinery underneath.

For a decade the shape of an AI request has been reassuringly dull. A user asks; a model answers; the connection closes. Nothing lingers. Agentic systems break that tidy contract. They plan, they execute multi-step tasks, they reach for external tools, and they carry on doing so with meaningful autonomy over time. AWS's own architecture blog frames the shift bluntly: from "user request → LLM → response" to "user goal → agent network → coordinated actions → outcome."

That small rewrite of the arrow has large consequences for the plumbing. You are no longer merely routing HTTP requests to a model endpoint. You are minding long-running stateful processes, tool execution, inter-agent chatter and failure recovery—all at cloud scale, and all while the user waits.

Who's in charge here

AWS prescriptive guidance identifies two primary patterns for coordinating agents. They differ, in essence, on a single question: is anyone in charge?

1. Synchronous Orchestration (Supervisor)

In the first, a supervisor agent runs the show. It receives the goal, plans the subtasks, delegates to specialised worker agents and stitches their results together. Control is centralised.

User Goal
    ↓
Supervisor Agent (Bedrock / LangGraph)
    ├── Research Agent → web search, document retrieval
    ├── Analysis Agent → data processing, computation
    └── Writer Agent   → output generation
    ↓
Final Response

The appeal is legibility. The supervisor is the single source of truth for task state, which makes the whole thing easy to reason about and easier still to debug. The catch is that a single point of truth is also a single point of failure: the supervisor is a bottleneck, and it must stay online for the entire duration of the task.

AWS implementation: Supervisor on ECS Fargate (long-running), workers on Lambda (short-lived, event-triggered). State in DynamoDB or S3.

2. Asynchronous Choreography (Event-Driven)

The second pattern dispenses with the conductor altogether. Agents behave autonomously, roused by events. There is no central coordinator; each agent reacts to messages on a queue or event bus and publishes its own output for the next agent to pick up.

User Goal → SQS → Research Agent
                       ↓ (publishes results)
                   EventBridge → Analysis Agent
                                     ↓
                                 SQS → Writer Agent → Output

This scales more gracefully and shrugs off trouble more readily—a failed agent can retry on its own without dragging the others down with it. The price is opacity. The workflow as a whole becomes far harder to observe, and reconstructing what actually happened demands distributed tracing. Freedom, as ever, is expensive to audit.

AWS implementation: SQS for queuing, EventBridge for routing, Lambda for stateless agents, Step Functions for workflow visibility.

The forgetful function

A practical indignity of cloud-deployed agents is that Lambda functions are stateless. They cannot hold a conversation's context from one invocation to the next; each awakening is a blank slate. The remedy, per AWS guidance, is to externalise session state to persistent storage and rebuild it at the start of every invocation.

import boto3, json

s3 = boto3.client('s3')
STATE_BUCKET = "my-agent-state"

def load_state(session_id: str) -> dict:
    try:
        obj = s3.get_object(Bucket=STATE_BUCKET, Key=f"sessions/{session_id}.json")
        return json.loads(obj['Body'].read())
    except s3.exceptions.NoSuchKey:
        return {"messages": [], "steps": 0}

def save_state(session_id: str, state: dict):
    s3.put_object(
        Bucket=STATE_BUCKET,
        Key=f"sessions/{session_id}.json",
        Body=json.dumps(state),
    )

def handler(event, context):
    session_id = event["session_id"]
    state = load_state(session_id)
    # ... run agent step ...
    save_state(session_id, state)

The trick keeps the Lambda itself stateless, and so freely horizontally scalable, while presenting the user with something that feels like memory. For sub-second reads, DynamoDB beats S3—worth the switch for hot session data.

A runtime off the shelf

Not everyone wants to build their own scaffolding. For teams that would rather rent than construct, Amazon Bedrock AgentCore, a purpose-built runtime for deploying agents on ECS, arrives with identity, observability and tool execution already fitted. It absorbs the undifferentiated heavy lifting: session management, tool routing and IAM scoping for each agent action.

AgentCore can be provisioned with CloudFormation:

Resources:
  MyAgent:
    Type: AWS::Bedrock::AgentCoreAgent
    Properties:
      AgentName: research-agent
      FoundationModel: anthropic.claude-sonnet-4-6-v1
      InstructionConfiguration:
        Instruction: "You are a research agent. Use tools to answer questions accurately."
      MemoryConfiguration:
        EnabledMemoryTypes: [SESSION]

The bargain, set against LangGraph-on-ECS, is flexibility for convenience. AgentCore is quicker to stand up and fully managed, but it pens you inside Bedrock models and the AgentCore tool interface. LangGraph, a framework for building stateful agent graphs, hands back full control of the graph, any model provider you fancy and custom checkpointing backends. You pay for that freedom in setup.

Watching the watchmen

Conventional application monitoring maps poorly onto agents. A single user request might spawn 20 LLM calls, 8 tool executions and 3 retry loops—every one of them invisible to a traditional APM trace. What you cannot see, you cannot fix.

The instruments that earn their keep:

  • AWS X-Ray: traces requests across Lambda, ECS and Bedrock invocations, threading a single trace ID through all hops
  • CloudWatch Logs Insights: queries structured logs from agent steps to reconstruct execution paths
  • LangSmith: LangChain's dedicated tracing platform, which captures every LLM call, tool invocation and state transition in a browsable interface

For production, instrument every agent node with a trace ID and log the input state, the output state and the latency. When something goes wrong—and it will—you will want to replay the exact sequence of steps that led to the wreck.

What to build on Monday

If you are starting an agentic project on AWS today, five recommendations hold up:

  1. Use LangGraph for the agent logic—explicit state, built-in checkpointing, human-in-the-loop support
  2. Deploy on ECS Fargate for long-running agents; Lambda for short-lived tool execution workers
  3. Store session state in DynamoDB (hot) and S3 (cold archive)
  4. Use SQS + EventBridge to decouple agents in async workflows
  5. Wire up X-Ray and LangSmith before you ship anything to production

The agentic infrastructure business is moving at a gallop. The patterns above are settled enough to build on. It is the services and framework versions beneath them that will keep changing—which is another way of saying the architecture is the easy part, and keeping up is the job.

Sources:

Discuss on Twitter