Lambda as tool host and agent host

The book has a loop, a model plane, memory, isolation, swarms, trust, and operations. What it has not yet nailed down is the unglamorous question underneath all of them: what compute actually runs this, and how does work arrive? Part 4 is that skeleton, the serverless plumbing that turns "an agent" into "a service that reacts." It is written last among the infrastructure parts on purpose, because you understand plumbing best once you know what flows through it, and this chapter starts at the smallest unit: a function that runs on demand, hosting either one of the agent's tools or a short agent itself.

Two jobs, one runtime

An agent platform needs somewhere to run two kinds of short-lived code, and Lambda (decoded in Part 3 as a Firecracker microVM per invocation) fits both:

  • Tool host. The agent's tools are functions: query_metrics, file_ticket, search_logs. Each is a natural Lambda, invoked when the agent's loop requests it. The tool that ran in-process in Part 1 becomes a network call to a function that runs in its own microVM, under its own identity, and nothing about the loop changes, because the loop was built against an interface.
  • Agent host. A short, event-triggered agent (the incident responder, a document classifier) is itself a natural Lambda: an event arrives, the function runs the loop for one task, and exits. Longer or interactive agents want Fargate or AgentCore Runtime; Lambda is for the short, bursty, event-driven end.

Why a tool per function is a security win

Hosting each tool as its own function is not just tidy; it is the least-privilege principle made structural. Each Lambda runs under its own IAM role, so the query_metrics function can be granted read access to metrics and nothing else, while file_ticket gets ticket-write and nothing else. The blast radius of a compromised tool is that one function's role, not the agent's union of all permissions. This is the same argument as the tool-design chapter's "promote an action to a dedicated tool," now with an infrastructure payoff: dedicated tools get dedicated identities, and a per-tool role is a per-tool wall.

It also composes with the injection defenses: a tool host reached by an agent processing untrusted content still executes only what its own scoped role permits, so even a hijacked tool call cannot exceed that one function's authority. The function boundary and the IAM boundary reinforce each other.

The 15-minute ceiling, and what it means

Lambda's defining constraint is a hard 15-minute execution limit, and for agent work that is a design input, not a nuisance. An agent loop can run many minutes (the model thinks, tools run, the caching lab's pauses happen), and a long autonomous run will blow past 15 minutes. The consequences:

  • Short agents and tools: fine. A tool call is seconds; a single-task event-driven agent usually finishes inside the window.
  • Long agents: not on Lambda. A fleet run of hours belongs on Fargate (no ceiling, flat per-hour) or in AgentCore Runtime sessions (managed, pay-active). Trying to force a long agent into Lambda by splitting it across invocations is possible but usually a sign you picked the wrong host.
  • The event-sourced design makes the split safe when you do need it. Because state is a durable ledger, a task that must span invocations checkpoints and resumes, exactly the resume machinery from Part 6. The ceiling stops being a data-loss risk and becomes a scheduling one.

Streaming and cold starts

Two Lambda mechanics matter for agents specifically. Response streaming lets a function return output incrementally rather than in one final blob, which is how a Lambda-hosted agent streams its progress and partial results to a caller, the same streaming UX that long-running agents need everywhere. And cold starts, the latency of a fresh microVM booting your runtime, are the one place the serverless dream leaks: the first invocation after idle pays boot time.

The fix connects straight back to Part 5. SnapStart eliminates the cold start by taking a Firecracker snapshot of your initialized runtime at deploy time and restoring it per invocation instead of booting, the exact snapshot-restore mechanic the sandbox-pool lab measured, now applied to function startup. When someone tells you SnapStart "makes Lambda start faster," you know precisely what it is doing, because you built the idea by hand: restore beats boot.

Lab 4.1's home: the queue underneath

Tools and short agents on Lambda are invoked by something, and that something is usually a queue or an event bus, which is the next chapters' subject and where this part's runnable lab lives. The preview: functions are invoked at-least-once, so a tool that has side effects (files a ticket, sends a message) must be idempotent, the tool-design chapter's operation_id earning its keep the moment a real queue sits in front of a real function. The plumbing and the tool contract were designed for each other.

Don't be confused: a tool host vs the sandbox. Both "run code for the agent," and Part 3 already drew the line; Lambda sharpens it. A tool-host Lambda runs your code, file_ticket you wrote and deployed, trusted, under a scoped role. The sandbox runs the model's code, authored at runtime, untrusted, behind a stronger wall. They can both be Firecracker microVMs and still be opposite trust domains, and a tool-host Lambda that evals model-generated code has quietly become a sandbox without any of a sandbox's controls, which is the mistake the distinction exists to prevent.

👉 Next: Step Functions as the orchestrator, where the functions gain a conductor: a durable state machine that runs the multi-step flow, holds the human-approval pause, and turns retries and errors into design instead of accident.