Como transformamos prompts gigantes em uma arquitetura modular de IA no G4 OS

Como saímos de prompts gigantes e ineficientes para uma estrutura modular inspirada em projetos de software no G4 OS. E o resultado: análises complexas de Meta, Realizado e Pessoas na palma da mão da liderança.

Os últimos meses no G4 têm sido intensos. Estamos vivendo na pele o que realmente significa adotar inteligência artificial na ponta da operação.

Quando as pessoas falam sobre colocar IA nas mãos de quem está na linha de frente, a realidade costuma se dividir em dois extremos. De um lado, você tem uma minoria de heavy users que dominam a ferramenta. Do outro, uma grande maioria que até tenta usar, mas fica presa em chats genéricos e não consegue extrair nenhum retorno prático para o negócio.

Nosso desafio era exatamente esse. Queríamos ajudar a liderança do comercial a automatizar tarefas analíticas repetitivas e complexas. Coisas que exigem olhar a operação sob diferentes ângulos.

Mas como fazer isso na prática? Como confiar que a IA vai consultar os dados corretos, seguir as regras de negócio reais da empresa e entender como concatenar as informações sem inventar respostas?

Esse era um desafio enorme. E a resposta tradicional do mercado (criar um prompt gigante de dez páginas com todas as regras) falhou logo no primeiro round.

O ponto de virada: o surgimento do G4 OS

O cenário mudou de figura no G4 quando começamos os testes do G4 OS.

Para quem ainda não conhece, o G4 OS é um harness que roda por cima de qualquer modelo de linguagem do mercado para oferecer um sistema operacional completo para empresas. Eu sou bastante suspeito para falar, porque uso ele para praticamente tudo no meu dia a dia, mas a velocidade de execução do nosso time disparou em poucos meses.

Dentro do G4 OS, existe o conceito de "skills". São conjuntos de instruções onde você grava processos ou procedimentos detalhados sobre como uma tarefa deve ser executada. Quando você cria uma skill, qualquer tarefa repetitiva ou fluxo complexo vira um conhecimento estruturado e compartilhável dentro do próprio sistema operacional.

Sabíamos que a resposta para o nosso comercial estava em criar uma skill poderosa. Mas a pergunta que me deparei logo no início do planejamento foi: como desenhar a arquitetura dessa skill? Será que um único arquivo markdown daria conta de todas as nuances comerciais do G4?

A resposta curta foi: não. Tentar colocar tudo em um arquivo só gerava conflito de instruções, estouro de contexto e respostas imprecisas. Foi preciso dar um passo atrás e mapear o que realmente queríamos resolver.

Mapeando os três pilares comerciais

Entendemos que, para dar suporte real à liderança comercial, a nossa skill precisava ler e cruzar informações de três pilares fundamentais:

A Meta: Ela parece simples (um número único no final do mês), mas tem nuances complexas. A diarização da meta (quanto precisamos entregar por dia útil) varia de mês para mês, dependendo dos feriados, finais de semana e sazonalidade.
O Realizado: É o dado seco e objetivo de quanto o time vendeu de fato ao longo do mês corrente.
As Pessoas: A visão individualizada. Precisávamos saber a meta e o realizado de cada vendedor, cruzando isso com o desempenho do time dele e da área geral.

Com esses pilares desenhados, ficou óbvio que um único documento de texto seria ineficiente. Mas isso não significava que o jogo estava perdido.

Foi aí que tivemos a primeira grande descoberta.

Pensando a IA como um projeto de software

O G4 OS tem uma capacidade incrível: ele consegue ler e navegar por um projeto inteiro de arquivos locais, da mesma forma que um desenvolvedor lê um código em React ou Node. Ele entende a hierarquia, localiza arquivos específicos e navega entre eles quando uma instrução importa outra. É uma lógica muito parecida com a de um LangGraph.

Pensamos: se o sistema operacional lê projetos estruturados, por que não estruturar a nossa skill como um projeto de software, dividindo-a em pastas e arquivos focados?

Desenhamos a arquitetura do projeto de forma totalmente modular:

Skill.md
├── Prevendas/
│   ├── Prevendas.md
│   └── Querysprevendas.md
└── Vendas/
    ├── Vendas.md
    └── Querysvendas.md

Nossa área de Aquisição é dividida em dois times muito diferentes: Pré-Vendas (SDRs) e Vendas (Closers). O contexto de cada um é único. Criar uma pasta isolada para cada área resolveu o conflito de regras.

Para garantir que a IA trouxesse dados 100% corretos, criamos os arquivos de queries (queries.prevendas.md e queries.vendas.md). Eles contêm os templates exatos das consultas SQL que devem ser rodadas no nosso banco de dados. Isso removeu qualquer chance de a IA inventar uma lógica de agregação ou trazer um número errado.

Para resolver a meta, criamos um arquivo separado explicando todas as regras de negócio de cálculo de comissão e distribuição diária. Já tínhamos dois terços do problema resolvido.

O desafio de escala: 160 pessoas e o filtro de onboarding

Faltava o pilar de pessoas. Temos um time comercial de quase 160 pessoas. Se déssemos liberdade para a IA carregar toda a base e histórico de performance de todos os vendedores a cada nova pergunta, a conta de tokens da API explodiria em poucos dias. O custo de crédito seria insustentável.

Foi aí que veio a segunda grande sacada: criamos um arquivo de onboarding.

Na primeira interação do usuário com a skill, o sistema não lê o banco inteiro. Em vez disso, ele faz uma entrevista rápida para descobrir quem está usando a ferramenta, qual é o time dele e qual a sua área.

Com essa identificação feita, a skill ativa um filtro e carrega para o contexto do modelo apenas os arquivos e dados estritamente necessários para aquele usuário específico. O resto do projeto de pastas é ignorado na leitura imediata.

O resultado final

Ao desenhar a skill como um projeto de arquivos interligados, resolvemos as três dores do nosso comercial. Demos à liderança a capacidade de obter insights profundos e tomar decisões melhores baseadas em dados que já foram previamente verificados e validados pelo motor da skill.

Mas, ao finalizar esse projeto, percebemos que ainda faltava algo. E se o G4 OS pudesse ir além e preparar cada líder individualmente para as suas principais reuniões da semana, cruzando a meta com o histórico recente?

Esse foi um segundo desafio fascinante, mas as lições que aprendemos com ele eu compartilho no próximo artigo.

Curtiu os bastidores do desenvolvimento do G4 OS? Qual o maior desafio que você enfrenta hoje ao tentar estruturar dados reais para IA na sua empresa? Comente aí.