Construindo o Delivery Control Plane: Lições do Apollo

Eu não me propus a construir um produto. Me propus a resolver um problema que estava me tirando do sério.

Era final de 2024, e a Moonxi — nosso estúdio de consultoria — estava rodando seis engagements simultâneos em três fusos horários. Tínhamos engenheiros em São Paulo, clientes em Nova York e Londres, infraestrutura espalhada por contas AWS, e uma colcha de retalhos de ferramentas que supostamente fariam tudo funcionar: Jira para tasks, GitHub para código, Terraform para infraestrutura, Datadog para monitoramento, planilhas para rastreamento de custos e Slack para todo o resto.

Nenhuma delas conversava com as outras. Não de verdade.

Eu conseguia dizer quais tasks estavam em progresso. Conseguia dizer o que estava deployado. Conseguia, com bastante esforço, estimar quanto um projeto específico estava nos custando em recursos de cloud. Mas eu não conseguia — em nenhum momento — responder à pergunta que mais importava: qual é o custo real de entregar este resultado, e estamos ganhando dinheiro fazendo isso?

Essa pergunta me assombrava porque eu sabia que a resposta provavelmente era “não.” Ou pelo menos “mal e mal.” E eu não estava sozinho.

---

A Indústria Opera às Cegas

A SPI Research publica um relatório anual de benchmark que deveria aterrorizar todo executivo de consultoria. Nos dados mais recentes, a utilização de consultorias — o percentual de horas disponíveis que são efetivamente faturadas a clientes — atingiu 68,9%. O menor nível em uma década. Para cada dez horas que um consultor está disponível, mais de três não são faturadas. Perdidas. Custo puro.

Mas utilização é apenas o sintoma. A doença é mais profunda.

As margens médias de EBITDA na indústria de consultoria colapsaram para 9,8%. Pense nesse número. Para cada milhão de dólares em receita, menos de cem mil sobrevivem como lucro. Em uma indústria que vende expertise — que não tem custo de mercadoria vendida no sentido tradicional, sem estoque, sem manufatura — uma margem de um dígito é uma falha estrutural.

Para onde vai o dinheiro? Evapora no espaço entre as ferramentas. No gap entre um ticket do Jira ser marcado como “done” e o custo real das horas de engenharia, infraestrutura e coordenação que foram necessárias para entregá-lo. No overhead invisível de troca de contexto, reuniões de status e reconciliação manual de dados que deveriam ser automatizados.

A indústria de consultoria passou duas décadas digitalizando tudo, exceto a coisa que mais importa: o feedback loop econômico entre delivery e margem.

---

O Operational Graph

O Apollo começou como um projeto de fim de semana. Um script Python que puxava dados dos nossos repositórios GitHub, correlacionava com tickets do Jira e cruzava ambos com o AWS Cost Explorer. A primeira versão era feia. Também foi reveladora.

Pela primeira vez, eu conseguia ver — em uma única tela — que uma feature específica tinha consumido 47 horas de engenharia ao longo de três sprints, gastado $340 em recursos de cloud durante desenvolvimento e teste, e agora rodava em produção a um custo estável de $12/mês. O ticket dizia que eram “2 story points.” A realidade era $4.200 em custo de delivery fully-loaded.

Esse foi o momento em que o Apollo deixou de ser um script e começou a se tornar um sistema.

Hoje, o Apollo é um delivery control plane completo. Tem 203 ferramentas governadas para agentes — capacidades discretas que agentes de IA podem invocar sob controle de políticas. Tem 54 rotas de API que conectam a todos os sistemas do nosso stack de delivery. E em seu núcleo, mantém o que chamamos de operational graph: um modelo vivo e consultável de como tasks se conectam a código, como código se conecta a deployments, como deployments se conectam a custos de infraestrutura, e como tudo isso se consolida em margem por projeto e por portfólio.

O operational graph não é um dashboard. Dashboards são snapshots. O graph é uma estrutura de dados — um grafo acíclico direcionado onde cada nó é um artefato (uma task, um commit, um deployment, um evento de custo) e cada aresta é uma relação causal. Quando um desenvolvedor faz commit de código que referencia uma task, o Apollo cria uma aresta. Quando esse código é deployado, o Apollo cria outra aresta do commit para o evento de deployment. Quando esse deployment dispara uma mudança de custo na AWS, o Apollo captura e vincula de volta.

O resultado é que em qualquer momento, eu consigo traçar uma linha de um resultado de negócio até o custo de infraestrutura que o sustenta. E consigo fazer isso em tempo real.

---

203 Ferramentas Governadas para Agentes

O número 203 não é arbitrário. É o resultado de dois anos iterando sobre o que agentes de IA realmente precisam para operar dentro de uma organização de consultoria — e, mais importante, o que eles devem ser impedidos de fazer.

Quando começamos a integrar agentes de IA no nosso fluxo de delivery, demos a eles acesso amplo. Criar tasks, modificar código, disparar deployments. Os resultados foram previsivelmente caóticos. Um agente fechava uma task antes do code review. Outro criava infraestrutura na conta AWS errada. Um terceiro atualizava um documento voltado ao cliente com linguagem que não tinha sido aprovada.

A lição foi clara: capacidade de agente sem governança de agente é passivo.

Então construímos uma camada de governança. Cada ferramenta no Apollo tem um envelope de política — um conjunto de regras que definem quem pode invocá-la, sob quais condições, com quais aprovações e com qual trilha de auditoria. Um agente pode criar um pull request em draft, mas não pode fazer merge na main sem aprovação humana. Pode estimar custos de cloud para uma arquitetura proposta, mas não pode provisionar recursos acima de um threshold de custo. Pode redigir um status update para o cliente, mas não pode enviá-lo.

É isso que queremos dizer com “governado.” Não restrito. Não tolhido. Governado. O agente tem capacidade completa dentro de uma fronteira de política, e cada ação é registrada no operational graph.

---

A Onda de Padronização MCP

Quando a Anthropic introduziu o Model Context Protocol, algo clicou. Estávamos construindo nossa própria interface de chamada de ferramentas — um sistema sob medida que funcionava mas era frágil e atrelado ao nosso stack específico. O MCP ofereceu algo melhor: um padrão.

Padrões importam em pontos de inflexão. Quando a web era jovem, cada servidor tinha seu próprio protocolo. O HTTP padronizou a interface e a web explodiu. Quando o cloud computing surgiu, cada provedor tinha APIs proprietárias. O modelo de providers do Terraform padronizou infrastructure-as-code e DevOps se tornou uma disciplina.

O MCP está fazendo o mesmo para a interação agente-ferramenta. E para organizações como a nossa que estão construindo sistemas de governança de agentes, padronização não é um nice-to-have — é existencial.

Eis o porquê: se cada framework de agente define sua própria convenção de chamada de ferramentas, então cada política de governança precisa ser reimplementada para cada framework. Sua trilha de auditoria se fragmenta. Seus controles de custo viram remendos. Seu modelo de segurança tem brechas onde quer que você tenha esquecido de implementar uma verificação em uma das dezessete convenções de chamada diferentes.

Com MCP, escrevemos políticas de governança uma vez. O envelope de política envolve a definição da ferramenta MCP. Qualquer agente compatível com MCP — independente do modelo ou framework subjacente — passa pela mesma camada de governança. Auditoria é unificada. Controles de custo são consistentes. E quando um novo framework de agente aparece (e eles aparecem mensalmente), não precisamos reconstruir nossa governança do zero.

O Apollo adotou MCP cedo. Hoje, todas as 203 ferramentas são compatíveis com MCP, com metadados de governança embutidos nas descrições das ferramentas. O agente sabe não apenas o que pode fazer, mas o que tem permissão para fazer, sob quais restrições, e o que acontecerá se tentar excedê-las.

---

Dogfooding como Validação Definitiva

Existe um tipo particular de convicção que vem de usar seu próprio produto todo dia. Não em um ambiente de demonstração. Não em um sandbox. Em produção, com clientes reais, dinheiro real e consequências reais.

O Apollo roda as operações da Moonxi. Toda manhã, ele gera um briefing que me mostra: quais projetos estão no trilho, quais estão desviando, onde a margem está comprimindo e quais ações os agentes tomaram durante a noite. Quando um agente otimiza um pipeline de deployment e economiza $200/mês em custos de infraestrutura, eu vejo no graph antes de terminar meu café.

Quando algo quebra — e coisas quebram — eu sinto imediatamente. Um bug no modelo de atribuição de custos mostrava um projeto como 12% mais lucrativo do que realmente era. Pegamos porque o cálculo de margem do graph não batia com a fatura que estávamos prestes a enviar. Esse é o tipo de bug que você só pega quando a ferramenta está conectada ao seu negócio real, não quando está rodando em um ambiente de teste com dados sintéticos.

Dogfooding também cria uma função de priorização implacável. Quando você é tanto o construtor quanto o usuário, sabe exatamente quais features importam e quais são vaidade. Matamos dezenas de features que pareciam importantes na teoria mas nunca eram usadas na prática. As que sobreviveram são as que economizaram tempo, pegaram erros ou tornaram o dinheiro visível.

---

A Lição para Founders

Todo founder tem um momento em que percebe que está construindo algo que não existe no mercado — não porque ninguém pensou nisso, mas porque ninguém estava com dor suficiente para construir direito.

O Apollo existe porque eu estava cansado de não saber se meu negócio de consultoria estava ganhando dinheiro por projeto, por sprint, por deployment. As ferramentas disponíveis eram ou de nível alto demais (dashboards financeiros que te diziam resultados trimestrais depois que já era tarde demais para agir) ou de nível baixo demais (monitoramento DevOps que podia te dizer o uso de CPU de um container mas não seu custo de negócio).

O gap no meio — o delivery control plane — estava vazio. E estava vazio porque construí-lo exige expertise de domínio tanto em operações de consultoria quanto em platform engineering. Você precisa entender o que uma taxa de utilização significa e como um deployment Kubernetes funciona. Essa intersecção é pequena.

Se você é founder, preste atenção nas ferramentas que constrói para si mesmo. Os scripts que escreve nos fins de semana. Os dashboards que monta na marra porque as opções comerciais não fazem o que você precisa. Os sistemas internos nos quais seu time confia mas que ninguém fora da sua empresa conhece.

Se essas ferramentas são boas o suficiente para que outras pessoas na sua indústria pagariam por elas, você pode ter um produto. Não um pivot. Não um “por que não tentar vender isso.” Um produto, nascido de dor genuína e validado pelo uso diário.

O Apollo não foi planejado como produto. Foi planejado como sobrevivência. O fato de ter se tornado algo que outras consultorias querem usar é consequência de construir algo que realmente funciona — porque precisava funcionar, porque nosso negócio dependia disso.

---

O Que Vem a Seguir

O Apollo ainda está no início. O operational graph cobre nosso stack, mas a ambição é maior: um delivery control plane universal que qualquer organização de consultoria possa adotar, customizar com suas próprias políticas de governança e conectar ao seu próprio ecossistema de ferramentas.

O padrão MCP torna isso possível de uma forma que não era há dois anos. E o mercado está pronto — ou melhor, o mercado está desesperado. Com utilização em 68,9% e margens em 9,8%, a indústria de consultoria não pode continuar operando às cegas.

Construímos o painel de instrumentos. Agora estamos aprendendo a voar.