An ADR agent can begin with a tiny web-search function and still point toward a larger architectural decision.
I built an ADR agent in Google ADK to investigate architecture options, look up past ADRs, and draft a record for review. To prove the complete loop, its original web_search was deliberately small: an embedded DuckDuckGo Lite HTML parser. It supported the agent’s initial investigation before the move to MCP.
It parsed returned HTML locally, retained five results, and formatted them for the ADR agent.
That starting point also exposed a boundary worth making explicit. The ADR workflow keeps two workflow-specific capabilities local: looking up past ADRs, because the repository and recorded decisions provide its context, and drafting the ADR record for review.
External research has a different path. Before adding a second workflow, I am moving that research into a shared MCP capability. The reason is concrete: a future review or discovery workflow should be able to use the same research capability without inheriting the ADR agent’s code.
The shared integration owns the provider connection, credentials, limits, returned sources, and failures. I am using Firecrawl Cloud MCP as the provider integration for the current ADR agent. The ADR workflow can request research while keeping its decision-history lookup and ADR drafting focused on the context and output that belong there.
This is a small change in where a capability lives, with a practical consequence for the next workflow. The embedded search proved the loop. The MCP capability creates a reusable starting point for external research before that next workflow arrives.
That leaves each workflow with its own context while sharing the external research capability.
The full post follows the ADR agent from its embedded search function to the shared capability boundary and the local capabilities that remain in the ADR workflow.
Want the complete picture? Read the complete post at zulmehdi.blog.
Top comments (0)