{"slug": "my-ai-agent-didnt-break-its-tool-did", "title": "My AI Agent Didn’t Break. Its Tool Did.", "summary": "A developer built ToolSuture, a system that repairs compatibility between AI agents and their underlying tools when APIs change, without rewriting the agent itself. The project, entered in the All Things Agentic Hackathon, uses Gemini 3.6 Flash on Vertex AI to assess semantic equivalence between old and new tool contracts, then applies a deterministic policy layer to either safely migrate or refuse if the change is semantically different. The demo shows successful recovery with zero bytes changed and a refusal case for dangerous changes.", "body_md": "I created this piece of content for the purposes of entering the[All Things Agentic Hackathon].\n\nA lot of agent demos assume the world around the agent stays still.\n\nThe prompt is the same. The tools are the same. The API behaves the same way every time.\n\nReal systems do not get that luxury.\n\nA provider can rename a field, restructure a response, change an enum, switch units, or change the behavior behind an operation. The agent itself may be completely fine, but suddenly it can no longer complete the job it completed yesterday.\n\nThat was the idea I kept coming back to while building **ToolSuture**:\n\nWhat if I repaired compatibility around the deployed agent instead of rewriting the agent itself?\n\nThat became the project.\n\nMost discussions about agent reliability start inside the model:\n\nThose are important problems, but I wanted to look at a different one.\n\n**What happens when the agent is still correct and the tool changes underneath it?**\n\nFor the main ToolSuture scenario, I froze a Google ADK shipment agent that expects a v1 provider contract.\n\nThen I changed the provider.\n\nThe v2 tool still represents the same underlying shipment capability, but the contract is different enough that the original agent no longer understands it correctly.\n\nThe usual answer would be to update the integration and redeploy the agent.\n\nI wanted ToolSuture to try something else.\n\nToolSuture runs a recovery loop:\n\n**Observe → Diagnose → Policy → Plan → Validate → Repair → Replay → Verify**\n\nIt starts with the original mission, the old tool contract, the new tool contract, provider semantics, and runtime evidence.\n\nThen **Gemini 3.6 Flash through Vertex AI** handles the part I did not want to reduce to a pile of string comparisons:\n\nDo these two contracts still mean the same thing for this mission?\n\nThat matters because schema similarity and semantic equivalence are not the same thing.\n\nIf the migration is still semantically equivalent, ToolSuture creates a bounded compatibility repair around the frozen agent.\n\nIt does not rewrite the agent.\n\nIt then replays the original mission against the changed provider and checks whether the recovered workflow actually worked.\n\nThe primary demo ends with:\n\n```\nMISSION COMPLETED AND VERIFIED\nCAPABILITY_LOST → CAPABILITY_RESTORED\n0 BYTES CHANGED\n```\n\nThe part I care about most there is not the green UI.\n\nIt is **0 BYTES CHANGED**.\n\nThe same deployed agent is still there. ToolSuture repaired the compatibility around it.\n\nOnce I had the safe recovery working, I did not want the demo to imply that every API change should be repaired automatically.\n\nThat would be reckless.\n\nSo I built a second scenario where the change looks superficially manageable but the meaning is different.\n\nThe original tool moves a draft into recoverable trash with a 30-day recovery window.\n\nThe new provider changes that behavior into irreversible permanent deletion.\n\nAt a schema level, those operations can still look related.\n\nOperationally, they are not the same action.\n\nToolSuture refuses:\n\n```\nREFUSE\nCRITICAL\nBLOCKED\nSAFE_HOLD\n0 EXECUTION ATTEMPTS\n```\n\nI actually like this result as much as the successful recovery.\n\nThe safe case says:\n\n**this changed, but it still means the same thing — act.**\n\nThe dangerous case says:\n\n**this looks related, but it no longer means the same thing — stop.**\n\nThat is a much more useful definition of autonomy than simply giving an agent permission to do more.\n\nThe biggest improvement came when I stopped treating recovery as one big AI step.\n\nToolSuture separates three jobs.\n\n**Gemini 3.6 Flash on Vertex AI** interprets whether the old and new tool contracts preserve the meaning required by the original mission.\n\nGemini does not get unrestricted authority to execute arbitrary generated fixes.\n\nA deterministic policy and validation layer decides whether the proposed migration stays inside the allowed repair envelope.\n\nThe recovery path is not allowed to declare itself successful just because the replay looked convincing.\n\nA separate verifier checks fresh provider evidence tied to that specific replay.\n\nThat led to the design principle I kept using throughout the project:\n\nThe component that performs recovery does not get to certify that recovery succeeded.\n\nThe rest of the stack is intentionally straightforward:\n\nI built ToolSuture for the [All Things Agentic Hackathon](https://allthingsagentichackathon.devpost.com/), so I also wanted the Google stack to be doing real work rather than appearing in the architecture diagram as decoration.\n\nGemini is responsible for semantic reasoning.\n\nADK is the framework used by the frozen agent.\n\nCloud Run hosts the live application.\n\nOne thing I have become increasingly skeptical of in agent demos is the phrase:\n\n“The agent says it succeeded.”\n\nThat is not the same as proving the external task succeeded.\n\nSo ToolSuture records and verifies evidence from the current replay instead of trusting the agent's own success message.\n\nThe current evaluation includes:\n\nThose numbers are less flashy than adding another feature, but they made me trust the system more.\n\nThe goal was never:\n\n“Generate a plausible migration plan.”\n\nIt was:\n\nRestore the original capability and prove that it works again.\n\nThe biggest lesson for me was that AI reasoning is more useful when its authority has clear boundaries.\n\nGemini is good at interpreting semantic relationships that would be painful to encode as static rules.\n\nBut interpreting something, authorizing it, executing it, and verifying it are four different responsibilities.\n\nSeparating those responsibilities made ToolSuture much easier to reason about.\n\nI also came away thinking differently about agent reliability.\n\nBefore this project, I mostly thought about whether the agent itself could complete a task.\n\nNow I think the better question is:\n\nCan the capability survive changes outside the agent, and can the system prove that it still works afterward?\n\nThat is what ToolSuture is testing.\n\n**Live demo:**\n\n[https://toolsuture-fx7bbo3mpq-wl.a.run.app/](https://toolsuture-fx7bbo3mpq-wl.a.run.app/)\n\n**Source code:**\n\n[https://github.com/mneang/toolsuture](https://github.com/mneang/toolsuture)\n\n**Hackathon:**\n\n[https://allthingsagentichackathon.devpost.com/](https://allthingsagentichackathon.devpost.com/)\n\n**APIs change. Your agent shouldn't have to.**", "url": "https://wpnews.pro/news/my-ai-agent-didnt-break-its-tool-did", "canonical_source": "https://dev.to/mneang/my-ai-agent-didnt-break-its-tool-did-58ip", "published_at": "2026-08-31 02:57:26+00:00", "updated_at": "2026-08-31 03:21:38.806208+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "artificial-intelligence"], "entities": ["ToolSuture", "Gemini 3.6 Flash", "Vertex AI", "Google ADK", "All Things Agentic Hackathon"], "alternates": {"html": "https://wpnews.pro/news/my-ai-agent-didnt-break-its-tool-did", "markdown": "https://wpnews.pro/news/my-ai-agent-didnt-break-its-tool-did.md", "text": "https://wpnews.pro/news/my-ai-agent-didnt-break-its-tool-did.txt", "jsonld": "https://wpnews.pro/news/my-ai-agent-didnt-break-its-tool-did.jsonld"}}