Teams that process documents at scale know the routine: files land in storage, someone notices, opens each one, decides what it needs, and routes it for review. Monitoring alerts queue up the same way, waiting for a person to act on them. The hours lost to manual triage are the operational problem ambient agents solve. Imagine a document lands in your Amazon Simple Storage Service (Amazon S3) bucket and within seconds a job appears on your Jobs page, ready to run (or already running if you configured it that way). The agent analyzes the file, surfaces the findings, and asks you for approval before taking the next step. The event itself is the prompt. That is an ambient agent: it responds to event streams, pauses for human input through a single ask_human tool when it needs to, and resumes from where it left off once the human answers.
Most AI agent experiences today follow a different pattern: a user opens a chat interface, types a prompt, and waits for a response. That works for one-time questions, but it limits the agent to one conversation at a time and requires a human to describe what happened before anything can act on it. For scenarios where agents should react to events happening across your infrastructure (file uploads, database changes, scheduled tasks, system alerts), that chat-only model breaks down.
\nAmbient agents describe a different paradigm, one that LangChain among others has articulated. Instead of waiting for users to initiate conversations, ambient agents listen to an event stream and act on it, potentially handling many events in parallel. They aren’t solely triggered by human messages, and multiple agents can run simultaneously. Crucially, they aren’t fully autonomous: a production design pays careful attention to when the agent pauses to interact with humans. When a signal fires, the agent executes its workflow and only interrupts a human when clarification, approval, or review is needed. This human-in-the-loop component lowers the stakes for deploying agents to production, builds user trust, and lets agents learn and improve over time through feedback.
\nOrganizations running on AWS already have the event-driven infrastructure in place: Amazon S3 event notifications, Amazon EventBridge rules, AWS Lambda triggers, and Amazon DynamoDB streams. The missing piece is connecting those event sources to intelligent agents that can reason about what happened, act, and loop in humans when the situation calls for it. Fully automated pipelines like AWS Step Functions can orchestrate workflows but can’t reason through ambiguity or ask clarifying questions. Chat-based agents can reason but require someone to start the conversation. Ambient agents bridge this gap.
\nAmazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. AgentCore Runtime provides the execution environment that makes this pattern work: container-based agent hosting with support for long-running workloads, built-in session isolation, and integration with Amazon Bedrock foundation models. AgentCore Runtime supports sessions long enough to cover the signal → agent → human-in-the-loop (HITL) flow shown here. The reference implementation caps each agent turn at the Lambda 15-minute timeout, which is more than enough headroom in practice. Combined with AWS Lambda for event processing and Amazon DynamoDB for state management, the result is a fully serverless ambient-agent platform.
\nIn this post we walk through the pattern end-to-end on Amazon Bedrock AgentCore. You will come away understanding:
\nask_human tool plus a canonical response envelope is enough to support the full range of human-in-the-loop interactions.Before deploying the reference implementation, make sure you have the following in place:
\nus-east-1 (the sample defaults are wired up for that Region).cdk bootstrap ).Node.js 18 or later for the React frontend.Before we get into the architecture, it helps to look at what makes an ambient agent different from a typical chatbot and at the building blocks the rest of the post relies on: the event-driven trigger model, the ambient signal abstraction, and the single human-in-the-loop tool that ties them together.
\nUser-initiated agents follow a request-response pattern:
\nAmbient agents follow an event-driven pattern:
\nThe key difference is the trigger mechanism. Ambient agents are activated by system events rather than explicit user requests, which makes them a natural fit for document-processing pipelines, monitoring and alerting, scheduled analysis, and multi-step workflows that need approval gates along the way.
\nAn ambient signal is a configuration that maps an event source to an agent. When the event occurs, the platform automatically creates a job for the agent. What happens next depends on one setting on the signal:
\nautoExecute: false (the default), the job lands on the Jobs page inidle status and waits for a human to review and run it. This is the safe, review-first flow you want when a signal could fire on unknown input or when the agent has high-stakes tools available.autoExecute: true , the signal processor enqueues the job straight onto the worker queue, the agent runs immediately, and a human is only pulled in if the agent itself callsask_human . This is the fully autonomous flow.The pattern covers several signal event sources. The reference sample ships the first two. The rest are extension points you add by writing a new handler Lambda function and a corresponding form field on the Signals page:
\njobType: "scheduled" rather than by a signal on the Signals page.Ambient agents need structured ways to interact with humans. In this sample the agent surfaces those interactions through a single tool (ask_human) and returns a canonical response envelope. In that envelope, status is one of completed, interrupted, or error, and the matching field is result, question, or error. The platform additionally threads session_id and job_id through every response so continuation turns can be correlated. Those are correlation metadata, not part of the core contract your agent must implement. When the agent returns interrupted, the platform moves the job into interrupted status and sets its requiresAction flag to true. The reference React frontend surfaces these on the Interrupted tab of the Jobs page with a warning indicator on each row, so there is no separate review queue to poll. The same Jobs view shows pending questions, proposed actions awaiting approval, final results, and failed jobs, giving a user one place to see everything their agents are doing instead of monitoring multiple chat windows or email threads.
The same mechanism supports several prompting patterns that a reader may recognize from the wider agents literature: a Notify turn where the agent simply reports a result, a Question turn where it asks for clarification, a Review turn where it proposes an action and waits for APPROVE / REJECT / MODIFY, and an Error turn where the failure is captured on the job record and the user decides whether to retry. These are conventions for how the agent writes its question, not separate runtime modes. At the platform level there is exactly one code path and exactly one envelope.
The platform is a small set of serverless components stitched together by an event pipeline. This section walks through the end-to-end flow first, then describes each component in turn.
\nEvents flow through the platform end-to-end as follows. Amazon S3 emits an s3:ObjectCreated notification, which a Signal Processor Lambda function receives. The Signal Processor queries a global secondary index (GSI) on the ambient-signals table to find any matching signal for the event bucket, then creates a job record for each match. The API tier (or the scheduler) enqueues the job onto an Amazon SQS queue. The same Job Execution Lambda function that serves the API path also drains the queue through an attached SQS event source, invokes the agent on Amazon Bedrock AgentCore Runtime, and writes results (and any human-input requests) back to Amazon DynamoDB. A React frontend served from Amazon S3 through Amazon CloudFront polls a small Amazon API Gateway and Lambda tier for updates and lets the user respond to pending interactions.
The major components are:
\nUpdateItem +list_append so concurrent writers do not clobber each other.agent_management ,job_management ,signal_management ,chat_management ,conversation_management ), plus achat_execution worker Lambda thatchat_management invokes asynchronously so chat API calls return immediately. See Production deployment for how they are provisioned.With the architecture in mind, the next step is wiring up the event source that turns an Amazon S3 upload into an agent job. This section creates the bucket, points its event notifications at the Signal Processor Lambda function, and walks through how the processor matches events against configured signals.
\nCreate the Amazon S3 bucket and configure event notifications that drive the Signal Processor:
\nThe bucket is configured to send s3:ObjectCreated:* events directly to the Signal Processor Lambda function. In this sample the notification configuration is installed dynamically by the signal_management Lambda function when a signal is created or updated, so adding a new signal for a new prefix doesn’t require a redeploy.
The Signal Processor receives Amazon S3 events, finds matching signal definitions in DynamoDB, and creates a job per match. At its heart the handler is the shape shown in the following example. The real handler in backend/functions/multi_agent/signal_processor.py also uses AWS Lambda Powertools for structured logging and idempotency, queries the bucketName-signalId-index GSI on the signals table, applies the prefix and suffix checks configured on each signal, and writes a signal_triggered job row.
Signals are stored in DynamoDB with this structure:
\nYou only set configuration.bucketName when creating a signal through the API. The top-level bucketName shown in the preceding example is populated by the platform. DynamoDB GSI partition keys can’t be nested inside a map attribute, so signal_management mirrors configuration.bucketName out to a top-level bucketName on every write so the bucketName-signalId-index GSI can fan out to matching signals on every Amazon S3 event.
The autoExecute flag is the single switch that decides whether the agent fires autonomously or a human reviews the job first. The Signals form in the Agent Management UI exposes it as a checkbox alongside the familiar enabled setting, so changing the behavior is a quick edit without touching code or the database.
Amazon Bedrock AgentCore Runtime hosts the agent container and exposes it through an InvokeAgentRuntime API that the worker Lambda function calls on every job. This section walks through the agent layout that ships with the sample, the configuration that drives it, and the small orchestrator that turns LangGraph tool calls into the platform’s response envelope.
AgentCore Runtime provides a container-based execution environment for agents, so you can bring any Python agent framework. The sample uses a modular design:
\nconfig.yaml defines agent behavior, tools, and the system prompt. The sample defaults to Anthropic Claude Sonnet 4.5 on Amazon Bedrock for this walkthrough, a fit for the multi-step tool calling and long-context reasoning the human-in-the-loop workflow relies on. Switching to Claude Haiku, Amazon Nova, or another tool-calling model available on Amazon Bedrock (availability varies by Region) is a one-line change to model_id in the following configuration. max_iterations: 10 gives the graph enough headroom for around ten model-to-tool round trips before it halts (the orchestrator doubles the value to compute LangGraph’s recursion limit, since each round trip traverses two graph nodes), which covers the multi-step tool use the sample’s S3, calculator, and ask_human tools expect. The file also contains an execution: block (loop-detector, circuit-breaker, session-cache thresholds) omitted here for brevity. See agent/config.example.yaml for the full file.
The agent is built on langchain.agents.create_agent, a tool-calling agent compiled as a LangGraph. LangChain handles the orchestration layer because it brings pre-built tool-calling patterns, a broad open ecosystem of integrations, and APIs many teams already know, while AgentCore Runtime supplies the managed hosting, session isolation, and scaling underneath. The two layers are complementary. The platform wrapper around the graph does three things: it builds the message list for the turn (including any conversation history and, for signal-triggered jobs, the Amazon S3 bucket and key that fired the signal so the model can pick up the file without being told), it invokes the graph, and it scans the tool output for the ask_human sentinel so a tool call can be turned into an interrupted response.
In its simplest form (the full version in agent/core/agent_core.py also handles per-session history caching, loop detection, and an execution trace), the orchestrator is this:
Deploy the agent to AgentCore Runtime using the provided script:
\nThe script returns an Agent Runtime Amazon Resource Name (ARN) which the backend stores in the agent registry so the Job Execution Lambda function can invoke it.
\nAmazon DynamoDB is the system of record for everything that needs to outlive a single Lambda invocation: which agents are registered, which jobs are in flight, the conversation history that gives an agent continuity across turns, and the signal definitions and chat threads the UI reads. The next subsections describe the table layout, the session model, and how the Job Execution Lambda function uses both to drive a job to completion.
\nThe state layer is backed by DynamoDB. The core tables exercised in this post are:
\nAgent registry table (one record per registered agent runtime):
\nJob registry table (one record per agent invocation). With the default autoExecute: false, a new signal-triggered job lands here in idle status, waiting for a user to choose Execute:
While a job is running the worker flips status to busy. If the agent pauses by calling ask_human, status becomes interrupted and requiresAction becomes true, which surfaces the job on the Jobs page’s Interrupted tab.
Conversation store table (full message history per session, with a 30-day time to live (TTL)):
\nAdditional tables exist for ambient signals, chat threads, and Powertools idempotency records. Scheduled execution reuses the job-registry table through a jobType and nextRun GSI rather than having its own table.
Sessions provide conversation continuity across job executions and chat turns. The conversation_management Lambda function owns DynamoDB persistence: every turn (human + AI pair) is appended to the session with an atomic UpdateItem + list_append so two concurrent writers on the same session can’t clobber each other, and a 30-day TTL takes care of cleanup.
The Job Execution Lambda function has two entry paths. The API path sends an SQS message (adding Powertools idempotency and a userId ownership check) and returns 202 Accepted immediately, so the frontend never waits for the model. The SQS worker path is where the real work happens: it loads conversation history, folds any human response into a continuation prompt, calls AgentCore Runtime, and writes the result back. That worker looks roughly like this:
The agent snippet earlier returned a sentinel-based interrupted envelope when the graph produced an ask_human tool call. This section zooms in on the ask_human tool itself and shows exactly how the orchestrator catches that sentinel without breaking the reasoning loop.
The core of human-in-the-loop functionality is the ask_human tool. It doesn’t raise an exception: because LangGraph’s tool node captures tool exceptions as error observations and feeds them back to the model, the tool instead returns a sentinel string. The orchestrator detects the sentinel on the ToolMessage stream after the graph finishes and converts it into an interrupted response. Per-invocation state (metrics, session ID, and so on) isn’t a tool argument. The orchestrator binds it on a ContextVar that tools read through current_execution_state.get(), which keeps concurrent invocations inside the same container isolated from each other.
The agent uses the tool naturally as part of its tool-calling loop. For example, when analyzing an invoice with multiple line items the agent may call:
\nThe tool returns the sentinel, the orchestrator stops the graph, persists the question as the latest AI turn in the conversation store, and surfaces an interrupted job to the UI. When the user replies, the Job Execution Lambda function invokes the agent again with the answer folded into a continuation prompt.
The Agent Management UI is the human side of the platform: where users browse jobs, answer pending questions, and chat with agents directly. It’s a React single-page application that talks to the same REST API the rest of the post has been describing. The next two subsections cover the layout and the user experience flow that ties signals, jobs, and human input together.
\nThe frontend is a React and Cloudscape Design single-page application served from Amazon S3 behind Amazon CloudFront. It exposes a five-tab navigation:
\n/chat ,/chat/:threadId ) for user-initiated conversations with a registered agent.The same chat component is reused by both the standalone Chat page and the Jobs detail Chat tab. While a job is running (status === "busy"), the panel polls /conversations/:sessionId on a short interval so turns from the agent or from a second browser tab show up within a few seconds. After the job settles, polling stops. Because it’s the same component in both places, a user can freely converse with an agent from the Jobs detail view while a job is active. They are not limited to answering a single pending question.
jobType: "signal_triggered" . If the signal hasautoExecute: false (the default) the job lands inidle and the user runs it manually. WithautoExecute: true the worker is already drafting a response by the time the list refreshes. User-initiated jobs carryjobType: "user_initiated" and render with a different badge so you can tell the two apart at a glance.ask_human moves to the Interrupted tab and itsrequiresAction flag flips totrue , which renders a warning indicator on the row.idle →busy →completed |interrupted |error ) are polled and reflected in the list and in the Chat tab header./chat page both render full conversation history and accept new user messages, so humans can answer pending questions or nudge the agent with additional context without leaving the UI.Authentication is handled by Amazon Cognito and an API Gateway CognitoUserPoolsAuthorizer (see backend/infrastructure/multi_agent_stack.py).
Real-time updates are implemented as lightweight polling of the conversation and job endpoints, so there is no WebSocket infrastructure to run.
\nThe reference implementation is deliberately small so you can see the contract before you start adding to it. This section describes what ships in the box, what you build on top, and where to plug in new event sources or tools.
\nBefore extending, it helps to know where the seams are. This sample is a reference implementation of the ambient-agent pattern, not a turnkey product. What ships out of the box:
\nask_human ,list_s3_files ,read_s3_file ) and a generic system prompt. Useful for validating the pipeline end-to-end, not for solving your business problem out of the gate.jobType: "scheduled" . Adding new signal types such as webhooks, Amazon EventBridge events, or DynamoDB streams requires extending thesignalType enum in both the backend and the Signals page form.What you build on top, and what the platform expects from each:
\ncompleted ,interrupted , orerror with the matchingresult ,question , orerror field) and use theask_human sentinel to request human input. That is roughly 50 lines of adapter code around whatever agent framework you prefer.signal_triggered job row (shown in the following template), plus a corresponding form field on the Signals page so users can configure it.agent/tools/ , a registration entry inagent/core/tool_factory.py , and an enable flag inconfig.yaml . The orchestrator and HITL flow do not change. Any tool that returns a string participates in the same graph.In short: the platform does the plumbing, you bring the brain. The three places you will write code (agent logic, tool implementations, and new signal handlers) all slot into the existing contract without touching the rest of the stack.
\nEnabling a new capability for an existing agent is a config change rather than a code change. The agent’s config.yaml toggles tools on or off and supplies their descriptions, so adding a new Amazon S3 prefix handler or a new calculator mode doesn’t require rebuilding the container. Signal definitions live in DynamoDB and are edited from the Signals page in the UI.
Signals today trigger on Amazon S3 events and on cron schedules. Adding a new type (a webhook, an Amazon EventBridge rule, a DynamoDB stream, a Kafka topic) follows the same three-step contract. The downstream pipeline is signal-agnostic: everything from the SQS worker through the AgentCore call through the UI treats all signal_triggered jobs the same, so you only need to write the bridge from your event source into a job row.
You add the Lambda function and its API Gateway route in the CDK stack, extend signalType in the frontend’s TypeScript union and the Signals page form, and the rest (the Jobs page UI, the ask_human interrupt handling, the conversation persistence, the autoExecute toggle, the contract tests) all apply without change. Like the production Signal Processor, a real webhook handler would add AWS Lambda Powertools idempotency so a retried delivery doesn’t create duplicate jobs.
After the pieces fit together locally, the next step is provisioning them in an account. The platform deploys as a single AWS CDK stack. The following subsections describe what that stack creates, the deploy commands, the metrics that matter when it is running, and the security and scaling defaults the sample ships with.
\nThe whole platform is an AWS CDK stack defined in backend/infrastructure/multi_agent_stack.py. For storage and messaging, it provisions the DynamoDB tables (agent registry, job registry, conversation store, ambient signals, chat threads, idempotency records) with pay-per-request billing and point-in-time recovery, plus the SQS job-execution queue and its dead-letter queue.
For compute and delivery, it provisions the three pipeline Lambda functions from the Architecture section (Signal Processor, Job Execution, Scheduler), the five management-tier Lambda functions that back the REST API (agent_management, job_management, signal_management, chat_management, conversation_management) and the chat_execution worker Lambda that chat_management invokes asynchronously, a Cognito-backed REST API, and the CloudFront distribution that serves the React frontend.
IAM grants flow directly from the code: DynamoDB grant_read_write_data on each table, SQS grant_send_messages and grant_consume_messages as appropriate, and a scoped bedrock-agentcore:InvokeAgentRuntime policy on the worker role.
The Lambda functions emit custom CloudWatch metrics under the AmbientAgents namespace for the events that matter in this pattern: signal matches, jobs enqueued, jobs completed, jobs interrupted, and jobs errored. Combined with the default Lambda and SQS metrics (invocation count, errors, queue depth, DLQ depth), these give you a dashboard where the signal → job → agent → human cycle is visible end-to-end. Set an alarm on DLQ depth as the first line of defense against silent failures.
bedrock-agentcore:InvokeAgentRuntime , targeted Amazon S3 prefixes).ask_human prompt. This protects the human-in-the-loop interaction and keeps agent outputs grounded in the source documents.To avoid ongoing charges after you are finished evaluating the sample, tear the stack back down in the reverse order it was created.
\nFirst, delete the agent runtime from Amazon Bedrock AgentCore so the container stops being billed:
\nNext, empty the Amazon S3 buckets the stack provisions (the documents bucket, the frontend hosting bucket, and the CloudFront logging bucket) so CloudFormation can delete them:
\nThen destroy the AWS CDK stack itself, which removes the Lambda functions, API Gateway, CloudFront distribution, DynamoDB tables, SQS queues, Cognito user pool, and IAM roles:
\nFinally, delete the Amazon ECR repository created by the agent deploy script if you do not plan to redeploy:
\nIf you enabled Amazon Bedrock model access only for this walkthrough and no longer need it, you can revoke it from the Model access page of the Amazon Bedrock console.
\nAmbient agents shift AI automation from “wait for a user” to “respond to signals”. Time-to-action drops from hours to seconds, and around-the-clock monitoring becomes possible without constant human attention. Each agent operates independently with isolated sessions, so the platform handles many concurrent events in parallel without coordination overhead. Humans stay in the loop only when their input is truly needed. The unified Jobs page removes context switching across multiple tools, and full conversation history means you never lose track of what an agent did or why it paused.
\nThe following use cases describe the ambient-agent pattern in general. The reference sample ships the plumbing for Amazon S3 and the scheduler today. Webhooks, database changes, and external integrations are extension points you wire up on top.
\nThe pattern is a strong fit whenever an event in your environment should drive work that a model can reason about and a human should occasionally weigh in on. Document-processing pipelines are the canonical example: a file lands, an agent reads it, summarizes it, and asks for approval before acting. Monitoring and alerting flows benefit from the same shape, with the agent triaging an alert and asking a human only when escalation is needed. Scheduled processing, analysis, and reporting fit naturally on the cron path, and any multi-step workflow that needs an approval gate or a human checkpoint along the way maps cleanly onto the ask_human interrupt.
There are also workloads where ambient agents are the wrong tool. Real-time chat applications belong in a traditional chat agent that is purpose-built for low-latency conversational turn-taking. Simple request-response APIs do not need an agent at all. A plain API endpoint is faster, cheaper, and easier to reason about. And for purely deterministic workflows that do not need large language model (LLM) reasoning, AWS Step Functions is still the right choice. Note that ambient agents with autoExecute: true already cover the fully autonomous case if you want LLM reasoning without a human gate.
Clone the reference implementation and follow the top-level README for deployment and configuration.
\nFurther reading:
\nStart small. Pick a single use case (document processing or a monitoring alert) and expand from there. Clone the sample, point it at your own event source, and see how much routine work the Jobs page takes off your plate.
","headings":[{"level":2,"text":"Artificial Intelligence","id":"artificial-intelligence"},{"level":1,"text":"Building ambient agents with Amazon Bedrock AgentCore: From event-driven signals to human-in-the-loop workflows","id":"building-ambient-agents-with-amazon-bedrock-agentcore-from-event"},{"level":2,"text":"Prerequisites","id":"prerequisites"},{"level":2,"text":"Understanding ambient agents","id":"understanding-ambient-agents"},{"level":3,"text":"Event-driven compared to user-initiated agents","id":"event-driven-compared-to-user-initiated-agents"},{"level":3,"text":"Ambient signals: The trigger mechanism","id":"ambient-signals-the-trigger-mechanism"},{"level":3,"text":"Human-in-the-loop: One tool, one envelope, one view","id":"human-in-the-loop-one-tool-one-envelope-one-view"},{"level":2,"text":"Architecture overview","id":"architecture-overview"},{"level":2,"text":"Building the event infrastructure","id":"building-the-event-infrastructure"},{"level":3,"text":"Setting up the Amazon S3 signal trigger","id":"setting-up-the-amazon-s3-signal-trigger"},{"level":3,"text":"Signal Processor Lambda function","id":"signal-processor-lambda-function"},{"level":3,"text":"Signal configuration data model","id":"signal-configuration-data-model"},{"level":2,"text":"Deploying agents on AgentCore Runtime","id":"deploying-agents-on-agentcore-runtime"},{"level":3,"text":"Agent packaging and structure","id":"agent-packaging-and-structure"},{"level":3,"text":"Agent configuration","id":"agent-configuration"},{"level":3,"text":"Core agent implementation","id":"core-agent-implementation"},{"level":3,"text":"Deploying the agent","id":"deploying-the-agent"},{"level":2,"text":"State management with DynamoDB","id":"state-management-with-dynamodb"},{"level":3,"text":"Database design","id":"database-design"},{"level":3,"text":"Session management","id":"session-management"},{"level":3,"text":"Job execution with conversation continuity","id":"job-execution-with-conversation-continuity"},{"level":2,"text":"Implementing human-in-the-loop patterns","id":"implementing-human-in-the-loop-patterns"},{"level":3,"text":"The human input tool","id":"the-human-input-tool"},{"level":3,"text":"Agent-side usage","id":"agent-side-usage"},{"level":2,"text":"Building the Agent Management UI","id":"building-the-agent-management-ui"},{"level":3,"text":"Frontend architecture","id":"frontend-architecture"},{"level":3,"text":"User experience flow","id":"user-experience-flow"},{"level":2,"text":"Extending the sample","id":"extending-the-sample"},{"level":3,"text":"What ships in the sample compared to what you build","id":"what-ships-in-the-sample-compared-to-what-you-build"},{"level":3,"text":"Configuration over code","id":"configuration-over-code"},{"level":3,"text":"Adding a new signal type","id":"adding-a-new-signal-type"},{"level":2,"text":"Production deployment","id":"production-deployment"},{"level":3,"text":"Infrastructure as code","id":"infrastructure-as-code"},{"level":3,"text":"Deployment steps","id":"deployment-steps"},{"level":3,"text":"Monitoring and observability","id":"monitoring-and-observability"},{"level":3,"text":"Security best practices","id":"security-best-practices"},{"level":3,"text":"Scaling strategies","id":"scaling-strategies"},{"level":2,"text":"Clean up","id":"clean-up"},{"level":2,"text":"Summary","id":"summary"},{"level":3,"text":"When to use ambient patterns","id":"when-to-use-ambient-patterns"},{"level":3,"text":"Next steps","id":"next-steps"}]}}