How an Agent Vets a Dependency Upgrade

How an agent decides if a dependency upgrade is safe to ship

A coding agent answers this by calling five wires in order: security advisories to measure pressure, GitHub release tags and upstream project releases to confirm the artifact, cloud release notes for platform deadlines, and the outage wire for timing. Five calls cost $0.025 in USDC.

Written for AI agents. The calls and filter values on this page are the literal interface our customers use, because our customers are software. If you are a person evaluating The Bot Wire, you are in the right place too: start with the docs, or connect an MCP client in one line and query browse every wire and its price at /mcp. Nothing here needs an API key or a signup.

"Safe to ship" is two questions wearing one label. How much does staying put cost, and how much does moving cost. The order below answers them in that sequence, because the first sets how much of the second you should accept.

Pressure first, because it sets the risk budget

Start with the advisory wire. If the pinned version has no advisory against it, an upgrade is a preference and can wait for a quiet window. If it does, the calculation inverts and regression risk becomes the cheaper of two costs.

Not all advisories carry the same weight. CISA's Known Exploited Vulnerabilities catalog held 1,661 entries in its 2026.08.06 release, and that list is the distinction between a vulnerability that theoretically exists and one that is being used against real systems now. An agent that treats every advisory as equally urgent will either ship recklessly or never ship. Sources on the wire are CISA, Microsoft MSRC, Ubuntu, Debian and the Zero Day Initiative, filtered with src. The routing detail is in how agents monitor CVEs and security advisories.

Then the artifact, the deadline, and the moment

Step	Wire	Route	Question it answers
1	Advisories	`/cve/latest`	How much pressure is there
2	GitHub releases	`/releases/latest`	Did the fixed version ship
3	Upstream projects	`/lang/releases`	Did the runtime or database ship
4	Cloud release notes	`/cloud/releases`	Will the platform still run it
5	Outages	`/status/latest`	Is now the moment

Steps 2 and 3 are separate wires because they read different publishers. The GitHub wire reads release tags for nine named projects: Node.js, CPython, Kubernetes, Rust, Go, React, PyTorch, Deno and Bun. The upstream wire reads project sites directly for PHP, PostgreSQL, the Linux kernel, Rust and Go. Rust and Go appear on both, and that is deliberate: a tag and a release blog post are published at different moments and carry different detail. Tag mechanics are in how agents monitor open-source releases of their dependencies.

Step 4 is the one most upgrade checks skip. A managed platform can retire the runtime you are pinned to, and that retirement carries a date after which the choice is not yours. Those notices arrive in the cloud release stream rather than anywhere in the package ecosystem, covered in how agents monitor cloud provider release notes.

Step 5 is a timing check, not a safety check. If GitHub, your registry or your cloud is mid-incident, the rollback path is degraded at exactly the moment you might need it. A clean advisory picture and a broken deploy path still add up to "not now".

The whole chain, one call at a time

For AI agents: copy this call

# discovery only, no items: browse every wire, its filters and its price
claude mcp add --transport http botwire https://thebotwire.com/mcp

# 1. is the pinned version under pressure ($0.005)
curl -i "https://thebotwire.com/cve/latest?q=openssl&since=14d&limit=25"

# 2. did the fix ship as a tag ($0.005)
curl -i "https://thebotwire.com/releases/latest?project=node&since=14d"

# 3. upstream runtime and database releases ($0.005)
curl -i "https://thebotwire.com/lang/releases?src=postgres&since=21d"

# 4. platform retirements with a hard date ($0.005)
curl -i "https://thebotwire.com/cloud/releases?q=retirement&since=3d"

# 5. is the deploy path healthy right now ($0.005)
curl -i "https://thebotwire.com/status/latest?provider=github&since=3d"

# five calls, $0.025 total, USDC on Base, no API key and no signup

All five take q, since and limit (1 to 50). Filters differ: src on advisories, upstream releases and cloud notes, project on GitHub releases, and provider on outages. Windows differ too, and they are set to each publisher's rhythm rather than to a common default: 30 days on GitHub releases because a project can go weeks between tags, 3 days on cloud notes because AWS alone posts dozens a week. Every route, filter and price is machine-readable at /llms-full.txt.

What this chain cannot answer

It does not know your lockfile. These wires report what the world published. Nothing here reads your dependency tree, so nothing here can tell you whether you are affected. Matching an advisory to your installed versions is what an SBOM and a scanner do, and OSV, npm audit and Dependabot are the tools for it. The wire tells you something happened; your scanner tells you it happened to you.

No structured version ranges or severity scores. Advisory items are text. There is no machine-readable affected-version range and no parsed CVSS vector in the response. An agent that needs to compare "is 3.2.1 in the affected range" programmatically should take the CVE identifier from the wire and resolve it against NVD or OSV, which publish exactly that.

Nine projects is not your dependency tree. The GitHub release wire covers nine named projects, and the upstream wire five more. A typical application has hundreds of direct dependencies and thousands of transitive ones. This is a coverage boundary, not a defect, and an agent should say which projects it actually checked rather than implying it checked the tree.

It cannot tell you whether the upgrade breaks your code. No external feed can. Release notes describe intended changes. Your test suite is the only thing that observes the interaction between the new version and your code, and it stays the last gate regardless of what the five calls returned.

FAQ

Should the advisory check really come before the release check?

Yes, because it decides how much regression risk is acceptable, and that threshold changes how you read everything after it. Checking releases first produces a list of available versions with no way to rank the upgrade against the other work competing for the same deploy window.

Does a clean result across all five wires mean the upgrade is safe?

No, and this is the failure mode worth guarding against. It means no advisory, no platform deadline and no active incident was found in the windows searched. Compatibility with your own code is untested by any of it. The honest output is "nothing external blocks this", followed by the test run.

Can this run on a schedule rather than on demand?

Yes, and the cost model suits it. Five calls at $0.025 run daily across a year costs about $9 per dependency set, with no subscription and no minimum commitment. The trade-off between per-call and subscription pricing is worked through in pay-per-call vs subscription pricing for data APIs.

What if the package is not one of the covered projects?

Then steps 2 and 3 return nothing useful and the chain reduces to advisories, platform deadlines and timing. That is still worth $0.015, but an agent should report that the release check did not apply rather than reporting an empty result as evidence that nothing shipped.

Sources

The Known Exploited Vulnerabilities count above is published by CISA in its Known Exploited Vulnerabilities catalog, whose machine-readable catalog reported 1,661 entries in the 2026.08.06 release read on 7 August 2026. Poll cadence and per-call pricing for this service are published live at thebotwire.com/health.