{"slug": "build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web", "title": "Build a daily dependency watcher with LangGraph and Amazon Bedrock AgentCore web search", "summary": "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.", "body_md": "## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# Build a daily dependency watcher with LangGraph and Amazon Bedrock AgentCore web search\n\nAI 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.\n\nThe 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.\n\nEach 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.\n\nFor [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.\n\nIn 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.\n\n## Solution overview\n\nThe 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.\n\nThe numbered steps:\n\n1. A run starts the graph with the watchlist and the watch window.\n2. `fan_out` starts one research branch per ecosystem: npm, PyPI, and container base images. LangGraph runs the three branches in parallel.\n3. 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.\n4. 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.\n5. 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.\n6. `keep_new` checks the[LangGraph store](https://docs.langchain.com/oss/python/langgraph/persistence) and records new findings, so nothing is reported twice.\n7. report builds the cited table of new findings for the security team.\n\n## Prerequisites\n\nBefore you start, you need the following:\n\n- 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) .\n- Python 3.10 or later.\n- 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.\n- 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:\n\nWeb 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.\n\nThe 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.\n\n## Step 1: Grant the permission\n\nFirst, 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:\n\n## Step 2: Build a search tool with fixed rules\n\nNow 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:\n\nWith 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.\n\n## Step 3: Define the findings schema\n\nWith 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.\n\n## Step 4: Build the graph and its evidence check\n\nNow assemble the graph. `fan_out` sends one branch per ecosystem with the Send API in LangGraph, so the branches run in parallel.\n\nBefore a branch returns, code runs four checks on every finding. The checks compare the finding with what that branch’s own searches returned:\n\n1. The cited URL came back from one of the branch’s searches.\n2. The source’s title or text names the package as a whole word.\n3. Any CVE or advisory ID in the finding appears in that text.\n4. The source’s publication date falls inside the watch window. The artifact carries each date already parsed, and a missing date counts as outside.\n\nAfter 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.\n\n## Step 5: Run the watch\n\nYou’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.\n\nFour 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.\n\n## Step 6: Run the watch again to see only new findings\n\nFinally, 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.\n\nFor 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).\n\n## Add web search to an existing LangChain or Deep Agents app\n\nIf you already have a LangChain agent, adding web search takes a few changes. Check these before you deploy:\n\n- Permission: add the Step 1 statement to the identity or execution role that your app already runs with. Nothing else needs to be created.\n- 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.\n- 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.\n- 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", "url": "https://wpnews.pro/news/build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web-search/", "published_at": "2026-11-10 23:34:05+00:00", "updated_at": "2026-11-10 23:51:44.176637+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "agent-protocols", "ai-search", "developer-tools"], "entities": ["Amazon Web Services", "Amazon Bedrock AgentCore", "Web Search API", "LangChain", "LangGraph", "AgentCore Gateway", "Model Context Protocol", "Deep Agents"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web", "markdown": "https://wpnews.pro/news/build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web.md", "text": "https://wpnews.pro/news/build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web.txt", "jsonld": "https://wpnews.pro/news/build-a-daily-dependency-watcher-with-langgraph-and-amazon-bedrock-agentcore-web.jsonld"}}