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

Amazon Web Services made the Web Search API in Amazon Bedrock AgentCore generally available, giving AI agents current web results through a single AWS-signed API call served from a web index Amazon operates rather than a third-party search engine. The API returns each result's title, URL, publication date and a query-relevant extract, supports domain include/exclude filters and publication date ranges, and requires no search API key to store or rotate; it is also reachable through AgentCore Gateway, where one administrator source policy covers every agent and Model Context Protocol client. LangChain's AWS integration now calls the API, and a sample LangGraph dependency watcher that checks npm, PyPI and container base images finished its three parallel research branches in 36 seconds versus 99 seconds run sequentially.

Artificial Intelligence https://aws.amazon.com/blogs/machine-learning/ 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 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/web-search-api.html 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 https://aws.amazon.com/lambda/ , Amazon Elastic Container Service Amazon ECS https://aws.amazon.com/ecs/ , or Amazon Bedrock AgentCore runtime https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html , 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 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html is also available through AgentCore Gateway https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html , a capability of Amazon Bedrock AgentCore. There, one administrator source policy covers every agent and Model Context Protocol MCP https://modelcontextprotocol.io/ client. For LangChain https://docs.langchain.com/oss/python/langchain/overview developers, the AgentCore web search tool in LangChain’s AWS integration https://docs.langchain.com/oss/python/integrations/tools/bedrock agentcore web search 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 https://docs.langchain.com/oss/python/langgraph/overview , the orchestration framework that runs them, and with Deep Agents https://docs.langchain.com/oss/python/deepagents/overview , 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. The numbered steps: 1. A run starts the graph with the watchlist and the watch window. 2. fan out starts one research branch per ecosystem: npm, PyPI, and container base images. LangGraph runs the three branches in parallel. 3. Inside each branch, the agent calls an Anthropic Claude https://aws.amazon.com/bedrock/anthropic/ model in Amazon Bedrock https://aws.amazon.com/bedrock/ . The model decides what to search for and, at the end, produces structured findings. 4. 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 https://docs.aws.amazon.com/IAM/latest/UserGuide/reference sigv.html . Steps 3 and 4 repeat, up to four searches per branch, in every branch at the same time. 5. 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. 6. keep new checks the LangGraph store https://docs.langchain.com/oss/python/langgraph/persistence and records new findings, so nothing is reported twice. 7. 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 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-regions.html . - 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 https://aws.amazon.com/cli/ profile. That identity needs the AWS Identity and Access Management IAM https://aws.amazon.com/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: Web Search and model calls are billed per use. For details, see Amazon Bedrock AgentCore pricing https://aws.amazon.com/bedrock/agentcore/pricing/ . One run of the watch makes at most 12 searches. The complete code is in this notebook https://github.com/langchain-ai/langchain-aws/blob/main/samples/agents/agentcore web search supply chain watch.ipynb . 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 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/web-search-api-get-started.html web-search-api-permissions . This uses the same permission that a gateway’s service role uses for web search: 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 https://github.com/langchain-ai/langchain-aws covers all of that with its options: 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 https://docs.langchain.com/oss/python/langchain/agents 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: 1. The cited URL came back from one of the branch’s searches. 2. The source’s title or text names the package as a whole word. 3. Any CVE or advisory ID in the finding appears in that text. 4. 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 doesn’t name the package, an invented ID, and an out-of-window source. They don’t confirm severity, exploitation status, affected versions, or the recommended action. They also don’t prove when an issue was first disclosed: a page that the index dates this week can describe an older incident. For a production security workflow, verify findings against authoritative vulnerability feeds. Have someone review a finding before anyone acts on it. Step 5: Run the watch You’re ready to run the watch with a 7-day window. In our run, the three branches made 12 searches and got 80 sources back. They finished in 36 seconds of wall time, against 99 seconds for the branches added together. The evidence check dropped two findings: one whose source didn’t name the package, and one whose CVE ID didn’t appear in its source. None of the sources came from the blocked domain. Four findings passed the checks, and keep new reported two of them. Earlier test runs had already reported the other two, so the store held them back. Figure 2 shows the run in LangGraph Studio https://docs.langchain.com/langsmith/quick-start-studio , the visual debugger for LangGraph. Every row of the report links to its source, which the Web Search acceptable use terms https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/web-search-api.html web-search-api-acceptable-use require for any output shown to users. Step 6: Run the watch again to see only new findings Finally, run the watch a second time to see the store at work. A scheduled watch runs every day, and the team shouldn’t see the same advisory twice. In our second run, the branches searched again and kept two findings, and the store had reported both before. So the report had nothing new, as Figure 3 shows. For a scheduled job, swap InMemoryStore for a durable store with exact key lookups, such as DynamoDBStore from langgraph-checkpoint-aws https://github.com/langchain-ai/langchain-aws/tree/main/libs/langgraph-checkpoint-aws . Add web search to an existing LangChain or Deep Agents app If you already have a LangChain agent, adding web search takes a few changes. Check these before you deploy: - Permission: add the Step 1 statement to the identity or execution role that your app already runs with. Nothing else needs to be created. - Region: the toolkit’s Region must offer the Web Search API, and it can differ from the Region of your model or the rest of your app. - Tool name: the tool is named web search . If your agent already has a tool with that name, such as another search provider, set a different name on the tool before you add it. - Rules and budget: each toolkit carries its own filters and search budget. Create one toolkit for each agent or branch that needs separate rules or its o