Check upgrade risks before you ship

A ReAct agent reviewed dependency data for a planned cloud upgrade and blocked it when it found an incompatible SDK version.

Done with Custom agent· Advanced· Sep 2026

What they did
A developer built SHIPCHECK as a ReAct agent linked to Sanity Content Lake through MCP. For each proposed upgrade, it used four tools to inspect component state, version rules, cluster links, and a knowledge graph, then traced two-level dependencies with GROQ. When docs disagreed, it chose the source with the higher authority score, on a scale from 1 to 10.
How it went
For a payment service upgrade from v2 to v4, the agent took 13 steps and found the cluster was still on Payment SDK v2.4.1, which was below the needed v3.0.0. It answered DO NOT SHIP YET; after a simulated SDK update, the check changed to safe.
Tips
This works best when dependency data is structured and the agent can verify it against current records. Keep the dataset small and clearly labeled if you want reliable checks.

Try it yourself with Claude Code

Review the current deployment data at [path or system] for [service] before [upgrade/change]. Check component status, version requirements, direct dependencies, and any linked dependencies up to two hops away. If sources conflict, rank them by authority and explain which one you used. Compare the installed versions against the required versions and list any blockers with evidence. Stop and ask for my approval before you make or submit any change, including deploys, config edits, rollbacks, deletes, or payments. End with a clear go/no-go recommendation and a short risk summary.

Fill in the [brackets]. Agents can make mistakes, so review anything before it is sent, paid or deleted.

Read the original on dev.to ↗

Get 3 agent uses like this every morning

With the day's top AI news. Free, and one click to unsubscribe.