AWS's ambient-agent sample exits Lambda at each human checkpoint and resumes from DynamoDB

The design follows from one constraint: where the waiting happens. A chat agent runs inside a request-response cycle. It keeps state in memory or a session store, and the conversation ends when the user closes the window ^[9]. An ambient agent's reviewer may answer hours later ^[10]. The reference caps each agent turn at Lambda's 15-minute timeout ^[14]. A wait of hours does not fit in a 15-minute invocation, so the agent has to stop running while the human decides ^[19].

AWS's answer is to exit early. When the agent calls ask_human, the tool returns a special status code. The handler catches it, serializes the agent's state, writes it to DynamoDB and exits ^[4]. Approval comes back as a second SQS message that triggers the function again ^[6]. Nothing runs while the reviewer is at lunch ^[4]. I think this is good engineering. Every pause goes through one tool, so exactly one code path writes a paused agent to the table ^[3].

Resume is where it can break. The dev.to writeup says the agent picks up from the exact tool call that triggered the pause ^[6]. AWS's own wording is that it resumes from where it left off ^[1]. That only works if the resumed agent treats the saved tool outputs as finished. Tools such as sending email run synchronously inside the invocation ^[3], so any that ran earlier in the turn have completed before the pause. An email sent ahead of the checkpoint is already out when the reviewer says no.

The routing is code the team writes. The writeup offers an illustrative handler and labels it a typical pattern. It checks for eventSource 'aws:s3', source 'aws.events' and an AlarmName field, then falls back to 'default-agent' ^[16]. Every new event source is another branch in that one function.

Concurrency comes from Lambda. Each invocation takes one SQS message, and workflows with different execution IDs run in parallel ^[7]. When a resume shares an execution ID, DynamoDB optimistic locking prevents the race, according to the writeup ^[22]. The Jobs page finds pending work by polling DynamoDB for rows marked WAITING_FOR_HUMAN ^[8].

The 15-minute figure is a claim about AWS's workload. AgentCore Runtime offers container hosting for long-running workloads with session isolation ^[17]. This reference still stops each turn at Lambda's limit, and AWS calls that "more than enough headroom in practice" ^[14]. The practice AWS describes is a document landing in S3 and an agent analyzing it before asking for approval ^[13]. For the claim to carry over, a team's slowest single turn, model calls plus synchronous tools, has to finish inside 15 minutes.

The setup list is long. The prerequisites ask for permission to create IAM roles, Lambda functions, DynamoDB tables, S3 buckets, SQS queues, API Gateway APIs, CloudFront distributions, Cognito user pools and ECR repositories, plus Bedrock resources ^[18]. Nine AWS services appear in that list ahead of Bedrock ^[20].

The writeup's author put the conclusion bluntly: "This is not a chatbot with extra triggers. It is a different control flow." ^[12] The sources support that. The human step covers more than approval, though. AWS says the agent interrupts a person when it needs clarification, approval or review ^[11].