Build a daily dependency watcher with LangGraph and Amazon Bedrock AgentCore web search

AI agents increasingly handle work that depends on what changed today, such as security advisories, product releases, prices, and regulations. A model’s training data can’t answer those questions, so agents need web search. For production use, teams also need results they can cite, and control over which sources count. They want search queries to stay inside their cloud environment because those queries often reveal internal work. The Web Search API in Amazon Bedrock AgentCore is now available. It gives agents and applications current web results through a single API call, signed with the AWS credentials they already use. AWS serves every query from a web index that Amazon operates, and doesn’t send it to a third-party search engine. Each result includes the page’s title, URL, publication date, and an extract relevant to the query. Requests can include or exclude domains, and limit results to a publication date range. On AWS Lambda , Amazon Elastic Container Service (Amazon ECS) , or Amazon Bedrock AgentCore runtime , your agent calls the API with its execution role. There’s no search API key to store or rotate. Web Search on Amazon Bedrock AgentCore is also available through AgentCore Gateway , a capability of Amazon Bedrock AgentCore. There, one administrator source policy covers every agent and Model Context Protocol (MCP) client. For LangChain developers, the AgentCore web search tool in LangChain’s AWS integration now calls the Web Search API. One function call gives an agent current, cited search results. The tool can also hold rules that the model can’t change, such as a date window, a source blocklist, and a search budget. It returns its results as data that your code can check. It works with LangChain agents, with LangGraph , the orchestration framework that runs them, and with Deep Agents , which adds subagents, a virtual filesystem, and context compression. In this post, you build a daily dependency watch for a security team as a LangGraph graph on the Web Search API. Every morning, the watch checks whether anything new affects the open source packages and container base images the team ships. It researches three package ecosystems in parallel, while your code keeps the date window, the blocklist, and the search budget out of the model’s control. It checks each finding against the sources it cites and remembers what it already reported. Then you run the watch on AgentCore runtime, and offer it across teams through AgentCore Gateway. In our test, the three branches finished in 36 seconds, against 99 seconds one after another. Solution overview The model decides what to search for and writes the findings. Every rule that must hold, whatever the model does, stays in code: the date window, the blocklist, the search budget, and the checks on each finding. Figure 1 shows how these parts fit together when you run the watch from the notebook. Figure 1: A daily dependency watch with LangGraph and the Web Search API, run from a notebook The numbered steps: A run starts the graph with the watchlist and the watch window. fan_out starts one research branch per ecosystem: npm, PyPI, and container base images. LangGraph runs the three branches in parallel. Inside each branch, the agent calls an Anthropic Claude model in Amazon Bedrock . The model decides what to search for and, at the end, produces structured findings. The branch’s search tool adds the date window and the blocklist to each query. It calls the Web Search API with a request signed with AWS Signature Version 4 (SigV4) . Steps 3 and 4 repeat, up to four searches per branch, in every branch at the same time. Each branch keeps only findings that its sources support and that fall inside the window. When all three branches finish, LangGraph merges their findings and runs keep_new once. keep_new checks the LangGraph store and records new findings, so nothing is reported twice. report builds the cited table of new findings for the security team. Prerequisites Before you start, you need the following: An AWS account, working in an AWS Region that offers the Web Search API. The examples use the US East (N. Virginia) Region (us-east-1). For other Regions, see Supported AWS Regions . Python 3.10 or later. AWS credentials for the identity that runs the notebook, from environment variables or an AWS Command Line Interface (AWS CLI) profile. That identity needs the AWS Identity and Access Management (IAM) permission from Step 1 and access to an Anthropic Claude model in Amazon Bedrock. The following Python packages: boto3 1.43.127 or later, the AgentCore Python SDK (bedrock-agentcore) 1.26.0 or later, and langchain-aws 1.9.3 or later. Install them with this pip command: pip install -U "boto3>=1.43.127" "bedrock-agentcore>=1.26.0" "langchain-aws[tools]>=1.9.3" langchain langgraph Web Search and model calls are billed per use. For details, see Amazon Bedrock AgentCore pricing . One run of the watch makes at most 12 searches. The complete code is in this notebook . The notebook runs every cell, including setup. The following steps cover the parts that matter for search. Step 1: Grant the permission First, give the identity you run as permission to search. The Web Search API needs one IAM action on one resource that AWS owns, so the statement is the same in every account. (For the full setup, see Grant permission to call the API .) This uses the same permission that a gateway’s service role uses for web search: { "Effect": "Allow", "Action": "bedrock-agentcore:InvokeWebSearch", "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1" } Step 2: Build a search tool with fixed rules Now build the search tool that each research branch uses. The watch can’t let the model choose the date window, the trusted sources, or the number of searches. The graph also needs the returned sources as data, to check findings against them later. The web search toolkit in the langchain-aws package covers all of that with its options: toolkit, tools = create_web_search_toolkit( region="us-east-1", exclude_domains=BLOCKLIST, published_after=window_start.strftime("%Y-%m-%dT%H:%M:%SZ"), model_filters=False, max_searches=4, return_sources=True, ) With no gateway argument, the tool calls the Web Search API. Every search carries the blocklist and the date floor, and a model’s own arguments could only narrow them. With model_filters=False , the model sees only a query argument. The tool stops after four searches, and it returns the results twice: as text for the model, and as an artifact for the graph. Each branch creates its own toolkit, so the branches search in parallel. You can give the same tools to a Deep Agents subagent. Step 3: Define the findings schema With the search tool in place, define what each branch returns. Each branch is a create_agent agent with a Pydantic schema as its response format, so it returns findings instead of prose. A finding has the package, a one-line title, and the CVE or advisory ID if the source gives one. It also has the severity that the source states, whether the source says it’s exploited, a recommended action, and the source URL. The notebook has the full schema and prompt. Step 4: Build the graph and its evidence check Now assemble the graph. fan_out sends one branch per ecosystem with the Send API in LangGraph, so the branches run in parallel. Before a branch returns, code runs four checks on every finding. The checks compare the finding with what that branch’s own searches returned: The cited URL came back from one of the branch’s searches. The source’s title or text names the package as a whole word. Any CVE or advisory ID in the finding appears in that text. The source’s publication date falls inside the watch window. The artifact carries each date already parsed, and a missing date counts as outside. After all branches finish, keep_new compares the surviving findings with a LangGraph store, and report builds the table. These checks catch an unsupported URL, a source that doe