Seven architectures for an assistant the team actually uses
From a Streamlit prototype to an ADK agent with A2A on Agent Engine: every architecture change answered a real problem.
Results
7
architectures iterated over 7 months
measuredJan to Jul 2026repository history
22
PRs on the knowledge base ingestion pipeline
measuredJan to Jun 2026knowledge base repository history
Adotado
by the internal team, as a chat and as a knowledge MCP server
self-reportedinternal usage
Summary
Context
Revvo's team lost time hunting for answers scattered across manuals, technical documentation and process docs. The idea was a "question killer": an assistant that answers from the official documents, both in a chat and inside the editor.
Action
I started with a prototype on Google ADK, Vertex AI RAG and Streamlit, already exposed as an MCP tool. Each time I hit a limit, I changed the architecture: automatic ingestion through GitHub Actions, a React and FastAPI app, a trial of Gemini Enterprise with citations, event-driven ingestion (Eventarc and Cloud Run) with incremental hash-based sync and retry with jitter, a LangGraph agent that also queries Jira and Confluence through MCP and, finally, an ADK agent on Agent Engine with A2A routes.
Result
Seven architectures between January and July 2026. The assistant was adopted by the internal team as a chat and as a knowledge MCP server, and the RAG is now one of the connections of the company's MCP gateway.
Lesson
In RAG, the bottleneck is rarely the model: it is keeping the knowledge base current without reprocessing everything.
Architecture
Long version
The problem
The information existed, but it was scattered: manuals, technical documentation and processes. Answering a question meant knowing where to look. The goal was to flip that: ask in natural language and get an answer grounded in the official document.
Seven versions
| # | When | Version | What changed and why | |---|---|---|---| | 1 | Jan | Prototype: ADK, Gemini, Vertex AI RAG, Streamlit and an MCP tool | Proof of concept for the RAG, already bringing the answer into the editor through MCP | | 2 | Jan | Ingestion through GitHub Actions | The docs live in a Markdown repository: every push syncs the bucket and re-imports into the RAG | | 3 | Apr | React and FastAPI app | A real interface in place of Streamlit | | 4 | May | Gemini Enterprise | Trying the managed search, with citations | | 5 | Jun | Event-driven ingestion | Eventarc and Cloud Run, incremental hash-based sync and retry with jitter | | 6 | Jun | LangGraph agent + Atlassian MCP | Answering with Jira and Confluence data as well | | 7 | Jul | ADK agent on Agent Engine, with A2A | Managed deployment and integration with Gemini Enterprise |
The change that mattered most
The change with the most impact was not the model. It was ingestion. In the CI version, every change re-imported everything and ran into the API's quota limits. The event-driven version reacts only to the file that changed: it compares the MD5 hash, sanitizes the name and syncs the corpus. When the quota is exhausted, it retries with jitter. The result was the end of redundant reprocessing, with the knowledge base always current.
Where it went
The RAG became one of the connections of the company's MCP gateway. Any agent with permission queries the knowledge base through the same entry point, with auditing.
What I would do differently
I would measure answer quality from the first version, with a fixed set of questions and the expected answers. I switched architectures guided by real usage problems, but without a numeric quality yardstick to compare the versions against each other.
Lessons learned
- Ingestion is a product. The change that paid off most was the pipeline, which became event-driven and incremental.
- Prototype early, with users. Each version came from a limitation that the people using it found in the previous one.
- Know the ecosystem. ADK, Agent Engine and A2A brought managed operation and interoperability with no glue code.