Por que construímos a Apollo Space

A Contagem de Abas Que Me Quebrou

Em janeiro de 2025, eu tinha 47 abas do navegador abertas. Sei disso porque o Chrome travou e me contou.

Catorze dessas abas eram dashboards de SaaS diferentes. Pipedrive para vendas. Linear para engenharia. Notion para documentação. Slack para todo o resto. Google Analytics para tráfego que ninguém olhava. Console da AWS para infraestrutura que ninguém entendia exceto eu. Três ferramentas de monitoramento diferentes porque nenhuma sozinha cobria tudo. Uma planilha que deveria ser nossa “fonte única da verdade” mas que ninguém atualizava.

Sou o CTO da Moonxi. Somos uma consultoria de software. Na época, tínhamos oito pessoas e doze projetos ativos de clientes. A conta era simples: estávamos gerando mais overhead operacional do que receita por hora.

Naquela tarde, depois que o Chrome se recuperou, fechei todas as abas exceto uma. Abri um documento em branco e escrevi uma única frase: “E se os dashboards fizessem o trabalho em vez de me mostrar o trabalho?”

Essa frase se tornou a Apollo Space.

O Problema Real Não São as Ferramentas, São os Espaços Entre Elas

Todo fundador com quem conversei no último ano tem a mesma doença. Eu chamo de síndrome da fragmentação SaaS. Você começa com um stack simples. CRM, gestão de projetos, talvez uma ferramenta de comunicação. Aí um cliente precisa de faturamento, então você adiciona isso. Aí percebe que precisa de monitoramento, então adiciona isso também. Aí alguém sai e você descobre que metade do conhecimento de processo vivia na cabeça da pessoa e a outra metade em uma página do Notion que ninguém consegue encontrar.

A McKinsey publicou um relatório em 2024 mostrando que a empresa média com 50-200 funcionários usa 89 aplicações SaaS diferentes. Para empresas abaixo de 50, ainda são 34. São 34 ferramentas que não se comunicam entre si, cada uma com seu próprio sistema de notificações, seu próprio modelo mental, sua própria versão da verdade.

Mas eis o que ninguém fala: o custo real não são as assinaturas. É o overhead cognitivo.

Um estudo de 2023 da Qatalog e Cornell descobriu que trabalhadores do conhecimento gastam 58 minutos por dia apenas procurando informações entre ferramentas. São 5 horas por semana. 250 horas por ano. Seis semanas inteiras de trabalho gastas não trabalhando, mas procurando o contexto necessário para trabalhar.

Na Moonxi, éramos piores que a média. Tínhamos ferramentas para clientes, ferramentas internas e ferramentas que existiam unicamente para conectar outras ferramentas. Zapier era nossa fita adesiva. Chegamos a ter 67 Zaps ativos. Sessenta e sete workflows automatizados, cada um sendo uma pequena ponte entre dois sistemas que deveriam ser um só.

Quando um Zap quebrava, e quebravam constantemente, alguém tinha que diagnosticar qual ponte desabou, descobrir quais dados estavam dessincronizados e remendar tudo manualmente. Esse alguém geralmente era eu, às 23h, porque o Zap quebrado estava entre nosso sistema de monitoramento e nosso sistema de alertas, e ninguém mais entendia como estavam conectados.

O Momento em Que Parei de Pensar em Ferramentas

Em março de 2025, eu estava em uma call com o Marcelo, meu cofundador e CEO. Ele estava frustrado. Tínhamos acabado de perder um deal porque nosso follow-up foi lento. O prospect tinha esfriado. Os dados estavam no Pipedrive, mas ninguém tinha verificado. O lembrete tinha disparado no Slack, mas estava enterrado sob 200 outras notificações.

“Precisamos contratar um SDR,” disse o Marcelo.

“Precisamos contratar três pessoas,” eu disse. “Um SDR, alguém para gerenciar o CRM e alguém para garantir que o SDR e a pessoa do CRM estão realmente fazendo o trabalho deles.”

Ele riu. Eu não. Porque eu estava falando sério, e a conta era devastadora. Um SDR júnior no Brasil custa cerca de R$4.000/mês. Um gerente de CRM, outros R$5.000. De repente você está olhando para R$120.000/ano em novo quadro de pessoal para resolver o que é fundamentalmente um problema de roteamento de informação.

Naquela noite, comecei a construir o que chamei de “script do SDR”. Era feio. Um script Python que se conectava à API do nosso CRM, puxava deals parados, rascunhava emails de follow-up usando GPT-4 e enviava para um canal do Slack para aprovação. Levei quatro horas para construir.

Na manhã seguinte, ele tinha identificado seis deals parados. O Marcelo aprovou os follow-ups com um joinha no Slack. Dois desses deals reengajaram naquela semana.

Eu não sabia ainda, mas aquele foi o primeiro agent da Apollo Space.

De Script a Sistema

Nos três meses seguintes, construí mais scripts. Um agent de QA que rodava testes automatizados em ambientes de staging e postava resultados antes de qualquer um pedir. Um agent de resumo de reuniões que consumia nossas transcrições do Fireflies e extraía itens de ação. Um agent de monitoramento de concorrentes que vigiava os blogs e páginas de preços de cinco concorrentes procurando mudanças.

Cada script resolvia um problema específico. Mas juntos, criaram um novo problema: eu agora estava mantendo um micro-império SaaS de minha própria autoria. Doze scripts, cada um com seu próprio cron job, seus próprios modos de falha, seu próprio logging. Tinha trocado fadiga de dashboard por fadiga de script.

A virada aconteceu quando percebi que esses scripts não eram independentes. Eram um time. O agent de SDR precisava de dados do agent de deal intelligence. Os resultados do agent de QA informavam o agent de code review. O agent de resumo de reuniões alimentava o agent de team intelligence.

O que eu precisava não eram doze scripts. Precisava de um sistema operacional para eles. Uma forma de coordenar, priorizar e escalar. Uma forma dos agentes se comunicarem entre si e com humanos, usando um contexto compartilhado.

Foi quando a Apollo Space deixou de ser um projeto paralelo e se tornou um produto.

A Arquitetura da Ação

A maioria dos produtos de IA que vi são o que chamo de “IA decorativa.” Eles pegam um produto SaaS existente e adicionam uma interface de chat. Pergunte ao seu CRM uma pergunta em linguagem natural. Obtenha um resumo gerado por IA do seu dashboard. É bonitinho. Mas é inútil para qualquer um que está se afogando em trabalho operacional.

A decisão fundamental de design da Apollo Space foi esta: agentes não esperam. Eles agem.

O agent de SDR da Apollo Space não espera você perguntar “com quem devo fazer follow-up?” Ele verifica seu pipeline a cada quatro horas. Identifica deals parados usando critérios que você define uma vez. Rascunha outreach. Coloca na fila para sua aprovação ou, se você confia o suficiente, envia autonomamente.

O agent de QA da Apollo Space não espera um desenvolvedor rodar testes. Ele vigia seu ambiente de staging. Quando um deploy chega, roda a suite de testes, compara screenshots para regressões visuais e posta um relatório. Se algo quebra, cria um ticket e atribui antes de qualquer humano sequer saber que o deploy aconteceu.

Essa é a diferença entre um dashboard e um agent. Um dashboard é uma janela. Um agent é um colega.

Por Que Quase Não Construímos

Quero ser honesto sobre algo. Quase matamos a Apollo Space três vezes.

A primeira foi em junho de 2025, quando nosso trabalho de consultoria aumentou e não tínhamos bandwidth. Construir um produto de IA enquanto se opera uma consultoria é como trocar o motor com o carro em movimento. Quase decidimos manter os scripts apenas internamente e focar no trabalho com clientes.

A segunda foi em setembro de 2025, quando o ciclo de hype de IA atingiu seu máximo local e toda startup estava alegando ser uma “plataforma de agentes de IA.” Lembro de rolar o Product Hunt e ver cinco lançamentos em um único dia com a palavra “agent” no nome. O mercado parecia saturado antes mesmo de entrarmos.

A terceira foi em dezembro de 2025, quando um potencial investidor nos disse que o mercado era “horizontal demais.” Vocês estão tentando fazer coisas demais, ele disse. Escolham um agent e vão fundo.

Ignoramos ele. Não por arrogância, mas porque tínhamos aprendido algo ao rodar nossos próprios agentes: o valor não está em nenhum agent individual. Está no efeito de rede entre eles. Um agent de SDR é útil. Um agent de SDR que é informado por deal intelligence, análise competitiva e contexto de reuniões é transformador. Você não consegue isso indo estreito.

O Que a Apollo Space É Hoje

A Apollo Space é um sistema operacional de IA. Quatro diretores, Growth, Ops, Finance e Custom, gerenciam doze agentes de execução. Os diretores cuidam da priorização e escalação. Os agentes fazem o trabalho.

O Growth Director gerencia os agentes de SDR, Deal Intelligence e Conteúdo. Quando o agent de SDR identifica um lead quente, o agent de Deal Intelligence enriquece o perfil com dados firmográficos, e o agent de Conteúdo pode rascunhar outreach personalizado baseado na atividade recente do prospect.

O Ops Director gerencia os agentes de QA, Code Review, Observabilidade e Resumo de Reuniões. Quando o agent de Observabilidade detecta uma anomalia, ele pode acionar o agent de QA para rodar testes direcionados e o agent de Code Review para verificar commits recentes em busca de mudanças relacionadas.

O Finance Director gerencia o agent de Monitor de Orçamento. O Custom Director cuida dos agentes de Team Intelligence, Monitoramento de Concorrentes e Saúde Pós-Venda.

Não é um chatbot. Não é um dashboard. É uma força de trabalho.

A Lição Que Aprendemos Construindo

Eis o que gostaria que alguém tivesse me dito dois anos atrás: o futuro do software não é inteligência. É agência.

Inteligência é saber a resposta. Agência é fazer algo a respeito. Todo LLM do mercado tem inteligência. Pouquíssimos produtos têm agência. E agência exige algo muito mais difícil de construir do que uma cadeia de prompts: exige uma opinião sobre como o trabalho deve fluir.

A Apollo Space tem opiniões. Ele acredita que deals parados devem receber follow-up em até 48 horas. Acredita que deploys em staging devem ser testados em até 15 minutos. Acredita que itens de ação de reuniões devem ser extraídos e atribuídos em até uma hora após o fim da reunião. Acredita que anomalias de orçamento devem ser sinalizadas imediatamente, não descobertas em uma revisão mensal.

Essas opiniões não são hardcoded. São configuráveis. Mas o fato de a Apollo Space ter defaults, de ser entregue com um ponto de vista sobre como operações devem funcionar, é o que o torna diferente de um toolkit.

Um toolkit diz: aqui estão as peças, monte você mesmo. Um sistema operacional diz: é assim que as peças se encaixam, e é isso que acontece quando você liga.

Construímos a Apollo Space porque estávamos cansados de montar. Cansados de ser a cola entre sistemas. Cansados do overhead cognitivo de gerenciar ferramentas que deveriam reduzir nosso overhead cognitivo.

Se você já encarou 47 abas do navegador e sentiu o peso de todo o trabalho operacional escondido atrás delas, a Apollo Space foi construído para você. Porque foi construído por alguém exatamente nessa posição.

E honestamente? A melhor parte não é que a Apollo Space faz o trabalho. É que eu parei de abrir aquelas abas. O agent de SDR faz o follow-up. O agent de QA testa. O agent de resumo de reuniões resume. Eu acordo, verifico um dashboard, o dashboard da Apollo Space, e sei o estado de tudo.

Isso não é eficiência. É sanidade.