Sete arquiteturas para um assistente que o time usa
Do protótipo em Streamlit a um agente ADK com A2A no Agent Engine: cada troca de arquitetura respondeu a um problema real.
Resultados
7
arquiteturas iteradas em 7 meses
medidojan a jul/2026histórico dos repositórios
22
PRs no pipeline de ingestão da base de conhecimento
medidojan a jun/2026histórico do repositório da base
Adotado
pelo time interno, como chat e como servidor MCP de conhecimento
declaradouso interno
Resumo
Contexto
O time da Revvo perdia tempo procurando respostas espalhadas em manuais, documentação técnica e processos. A ideia era um "matador de dúvidas": um assistente que respondesse com base nos documentos oficiais, tanto no chat quanto dentro do editor.
Ação
Comecei com um protótipo em Google ADK, Vertex AI RAG e Streamlit, já exposto como ferramenta MCP. A cada limitação, mudei a arquitetura: ingestão automática por GitHub Actions, app em React e FastAPI, teste do Gemini Enterprise com citações, ingestão orientada a eventos (Eventarc e Cloud Run) com sincronização incremental por hash e retry com jitter, um agente LangGraph que também consulta Jira e Confluence via MCP e, por fim, um agente ADK no Agent Engine com rotas A2A.
Resultado
Foram sete arquiteturas entre janeiro e julho de 2026. O assistente foi adotado pelo time interno como chat e como servidor MCP de conhecimento, e hoje o RAG é uma das conexões do gateway MCP da empresa.
Lição
Em RAG, o gargalo raramente é o modelo: é manter a base atualizada sem reprocessar tudo.
Arquitetura
Versão longa
O problema
A informação existia, mas espalhada: manuais, documentação técnica e processos. Responder uma dúvida exigia saber onde procurar. O objetivo era inverter isso: perguntar em linguagem natural e receber a resposta com base no documento oficial.
Sete versões
| # | Quando | Versão | O que mudou e por quê | |---|---|---|---| | 1 | jan | Protótipo: ADK, Gemini, Vertex AI RAG, Streamlit e ferramenta MCP | Prova de conceito do RAG, já levando a resposta para dentro do editor por MCP | | 2 | jan | Ingestão por GitHub Actions | Os documentos vivem num repositório Markdown: cada push sincroniza o bucket e reimporta no RAG | | 3 | abr | App em React e FastAPI | Interface de verdade no lugar do Streamlit | | 4 | mai | Gemini Enterprise | Testar a busca gerenciada, com citações | | 5 | jun | Ingestão orientada a eventos | Eventarc e Cloud Run, sincronização incremental por hash e retry com jitter | | 6 | jun | Agente LangGraph + Atlassian MCP | Responder também com dados de Jira e Confluence | | 7 | jul | Agente ADK no Agent Engine, com A2A | Implantação gerenciada e integração com o Gemini Enterprise |
A troca que mais importou
A mudança com mais impacto não foi de modelo. Foi a ingestão. Na versão por CI, cada mudança reimportava tudo e esbarrava em limites de quota da API. A versão orientada a eventos reage só ao arquivo que mudou: compara o hash MD5, sanitiza o nome e sincroniza o corpus. Quando a quota estoura, ela tenta de novo com jitter. O resultado foi o fim do reprocessamento redundante, com a base sempre atualizada.
Para onde foi
O RAG virou uma das conexões do gateway MCP da empresa. Qualquer agente com permissão consulta a base pelo mesmo ponto de entrada, com auditoria.
O que eu faria diferente
Mediria a qualidade das respostas desde a primeira versão, com um conjunto fixo de perguntas e as respostas esperadas. Troquei de arquitetura guiado por problemas reais de uso, mas sem uma régua numérica de qualidade para comparar as versões entre si.
Lições aprendidas
- Ingestão é produto. A troca que mais valeu foi a do pipeline, que passou a ser orientado a eventos e incremental.
- Protótipo cedo, com usuários. Cada versão nasceu de uma limitação que quem usava encontrou na anterior.
- Conheça o ecossistema. ADK, Agent Engine e A2A trouxeram operação gerenciada e interoperabilidade sem código de cola.