Todos os dias, na hora do almoço, eu costumo dirigir ouvindo vídeos, entrevistas e análises que me ajudam a organizar ideias sobre tecnologia, economia e negócios.
Em um desses trajetos, escutei dois vídeos novos que conectaram com algo que eu já vinha pensando há bastante tempo: não faz sentido construir uma operação séria ficando refém de uma única empresa, de um único país, de um único governo ou de uma única plataforma.
O vídeo do Fernando Ulrich olhava para IA pelo lado de mercado, geopolítica e incentivos: concorrência chinesa, modelos de pesos abertos, guerra de preços, dúvidas sobre lucratividade das grandes labs americanas e reação de clientes que começam a desconfiar de fornecedores capazes de usar o aprendizado do mercado para depois competir com os próprios clientes.
O do Lucas Montano olhava pelo lado de produto e engenharia. A provocação central era parecida: modelos de fronteira deixaram de ser apenas uma assinatura de software e passaram a ser tratados como ativo de segurança nacional. Se o acesso pode ser limitado por governo, fornecedor, parceiro aprovado ou regra geopolítica, então amarrar um produto inteiro a uma única API deixa de ser só uma decisão técnica. Vira risco operacional.
Para mim, isso conversa com uma preocupação antiga: acompanhar a tecnologia de perto, mas sem perder meus contextos dentro de uma ferramenta que amanhã pode mudar, encarecer, limitar acesso ou deixar de existir. Sempre pensei que meus contextos, meus métodos e minhas ferramentas precisavam ser portáveis o bastante para eu carregar comigo, até em um pen drive, se fosse necessário.
À primeira vista, eram vídeos sobre assuntos diferentes. Um falava mais de mercado, big techs e Estado. O outro falava mais de modelos, APIs e engenharia. Mas, para mim, os dois acabaram apontando para uma mesma tese.
A inteligência artificial está evoluindo rápido demais para que a gente trate qualquer ferramenta como definitiva.
Uma solução que hoje parece revolucionária pode virar apenas mais uma opção em poucas semanas. Um modelo que hoje parece imbatível pode ser ultrapassado, limitado, encarecido, bloqueado ou substituído. Uma plataforma que promete resolver tudo pode mudar suas regras, seus preços, sua API, sua política de acesso ou simplesmente deixar de servir ao que precisamos.
E isso não é uma reflexão distante para mim. É algo que estou vivendo no dia a dia.
A experiência prática com uma squad agêntica
Na Tecelume, estamos experimentando, testando ferramentas, avaliando modelos, montando fluxos, errando, ajustando e aprendendo enquanto a própria indústria muda. Estamos vivendo o desafio real de estruturar uma squad agêntica: entender onde agentes ajudam, onde atrapalham, onde precisam de supervisão humana, onde uma automação simples resolve melhor e onde o excesso de novidade pode virar ruído.
Essa experiência tem reforçado uma convicção: o risco não está em usar ferramentas novas.
Pelo contrário. Precisamos testar rápido. Precisamos aprender rápido. Precisamos comparar. Precisamos aproveitar o que realmente funciona. Precisamos abandonar o que não sustenta resultado.
O risco está em confundir ferramenta com estratégia.
Essa percepção tem guiado muito do caminho que estamos seguindo com o OPS.
O OPS não nasceu, para mim, como uma tentativa de criar mais uma ferramenta para competir com as ferramentas que já existem. Também não nasceu de uma vontade de reinventar tudo do zero.
Ele nasceu de uma necessidade prática: como continuar aprendendo, evoluindo e operando com IA sem transformar a empresa em refém de uma plataforma específica?
Porque, sinceramente, construir tudo em cima de uma única ferramenta fechada para um cenário que muda toda semana parece cada vez mais arriscado.
O aprendizado não pode ficar preso na ferramenta
Você investe tempo demais em uma solução muito presa a uma interface, a um modelo, a uma API ou a um fornecedor. Pouco tempo depois, surge algo melhor, mais barato, mais rápido, mais integrado ou mais simples. E aí vem a pergunta: o que acontece com todo o aprendizado acumulado?
Fica preso na ferramenta antiga? Fica perdido em conversas soltas? Fica espalhado em prompts, planilhas, configurações privadas e decisões que ninguém sabe mais explicar?
Ou vira método?
Para mim, essa é a diferença central.
A ideia de seguir pelo OPS não veio de uma abstração. Veio dessa mistura entre assistir esses debates, acompanhar o movimento do mercado e, principalmente, viver o trabalho real de tentar colocar agentes, automações e IA para funcionar em problemas concretos.
No trabalho real, não basta uma demonstração bonita.
É preciso entender o contexto. É preciso lidar com restrições. É preciso respeitar dados sensíveis. É preciso saber o que pode ou não ser automatizado. É preciso revisar. É preciso deixar rastro. É preciso conseguir repetir o que funcionou. É preciso corrigir o que falhou. É preciso explicar por que uma decisão foi tomada.
E é exatamente aí que a simples dependência de uma ferramenta começa a mostrar seus limites.
A operação não pode morar dentro do modelo
Uma ferramenta pode ajudar muito. Um bom modelo pode acelerar demais. Um agente bem configurado pode economizar horas. Um ambiente moderno de desenvolvimento pode mudar completamente a produtividade.
Mas a operação não pode morar dentro deles.
A fonte da verdade precisa estar fora do modelo. O conhecimento precisa ser organizado de um jeito que possamos entender, revisar, versionar, adaptar e carregar conosco.
Essa é a essência do OPS para mim: uma base operacional própria, evolutiva e portátil, onde o método fica mesmo quando as ferramentas mudam.
Não é sobre rejeitar OpenAI, Anthropic, Google, ferramentas de agentes, IDEs inteligentes, automações prontas ou qualquer outra tecnologia. Pelo contrário. É sobre criar uma estrutura que permita usar o que houver de melhor sem entregar a essas ferramentas o centro da operação.
- O modelo interpreta.
- O método permanece.
- A ferramenta executa.
- O aprendizado acumula.
Essa separação parece simples, mas muda a forma de trabalhar.
Quando a operação está organizada em torno de contexto, critérios, processos e melhoria contínua, uma nova ferramenta deixa de ser uma ameaça e vira um experimento. Se funcionar, incorporamos. Se não funcionar, descartamos. Se aparecer algo melhor, testamos. Se uma plataforma limitar, migramos. Se um modelo ficar caro, buscamos alternativa. Se uma automação não for segura, mantemos aprovação humana.
Uma empresa AI-friendly precisa de um company brain
Essa forma de pensar também muda o papel do conhecimento interno. Para uma empresa trabalhar bem com IA, não basta ter várias ferramentas inteligentes espalhadas. Ela precisa de um company brain: uma fonte única de verdade, organizada, revisável e preparada para ser lida por pessoas, scripts e agentes.
Não estou falando de colocar todo o conhecimento da empresa dentro de um modelo. Isso seria caro, inseguro e confuso. Estou falando de manter decisões, processos, critérios, padrões, responsabilidades, schemas, integrações e contexto operacional em uma base própria, com dono, histórico, links, status e regras de acesso.
Um bom company brain torna a empresa mais AI-friendly porque transforma conhecimento disperso em contexto acionável. O agente não precisa adivinhar como a empresa trabalha. Ele pode buscar a fonte certa, entender o recorte necessário e devolver uma ação, um rascunho, uma revisão ou uma pergunta melhor.
Essa é uma diferença importante: o cérebro da empresa não deve ser o modelo. O cérebro da empresa deve ser a base de conhecimento e operação que permite trocar modelos sem perder método.
Second brain, LLM Wiki e GBrain
Essa visão conversa com duas inspirações recentes. No texto LLM Wiki, Andrej Karpathy descreve um padrão de second brain em que fontes brutas ficam preservadas e uma wiki em Markdown, mantida com ajuda de LLMs, acumula sínteses, links, contradições e aprendizado ao longo do tempo. O ponto mais forte ali não é a ferramenta. É a ideia de que conhecimento não precisa ser redescoberto do zero em cada pergunta.
O GBrain, do Garry Tan, aponta para uma direção parecida em contexto de agente e empresa: uma camada de brain que combina busca, síntese, citações, análise de lacunas, grafos e escopo de acesso. Como inspiração, isso reforça a tese do company brain: a empresa AI-friendly precisa de memória institucional operável, não apenas arquivos guardados ou chats inteligentes.
Para o OPS, a lição é direta: o cérebro da operação deve ser composto por fontes confiáveis, contexto estruturado, regras claras e revisão humana. Modelos podem ler, sintetizar e agir sobre isso. Mas o ativo durável é a base que continua melhorando mesmo quando a ferramenta muda.
Do system of record ao system of intelligence
Outra forma de olhar para isso é separar system of record de system of intelligence. O system of record é onde o fato oficial mora: contrato, tarefa, cliente, transação, documento, decisão, código, histórico ou status. É a camada que precisa ser confiável, auditável e preservada.
O system of intelligence é outra camada: ele interpreta sinais, conecta fontes, sugere próximos passos, prepara rascunhos, aponta riscos, coordena agentes e ajuda a transformar conhecimento registrado em ação. Ele não deve substituir o registro oficial. Deve operar sobre ele, respeitando permissão, contexto e revisão.
É aqui que aparecem os moats reais em IA. O diferencial sustentável provavelmente não será só usar o modelo mais novo, porque modelos ficam mais acessíveis e parecidos com o tempo. O diferencial tende a estar na qualidade do contexto próprio, nos dados bem organizados, nos processos explícitos, nas avaliações, nos fluxos de revisão, na integração com sistemas de registro e na capacidade de aprender com o uso diário.
Em outras palavras: a vantagem não está apenas no modelo. Está no sistema que transforma modelo em operação confiável.
IA também virou infraestrutura geopolítica
Existe outro ponto que não dá para ignorar: IA deixou de ser apenas uma disputa entre empresas de tecnologia. Ela entrou no centro de uma espécie de guerra fria geopolítica, com países, blocos econômicos, chips, data centers, energia, nuvem, modelos, restrições de exportação, regulação e controle de infraestrutura disputando espaço ao mesmo tempo.
Isso não significa que toda empresa pequena precisa virar especialista em política internacional para usar IA. Mas significa que dependência tecnológica passou a ter uma camada a mais. O risco não é só um fornecedor mudar preço ou API. Pode haver limitação de acesso, mudança regulatória, sanção, restrição de hardware, disputa por capacidade computacional ou concentração de dados e infraestrutura em poucos atores.
Para uma operação prática, o cuidado é manter o máximo possível de clareza sobre onde estão os dados, quem processa cada coisa, que tipo de contexto entra em cada ferramenta, quais fluxos dependem de um único fornecedor e quais partes precisam ter plano de substituição. Não é paranoia. É arquitetura operacional proporcional ao momento.
Segurança também é arquitetura de contexto
A pressa para usar IA não pode virar descuido com dados sensíveis. Não faz sentido ganhar produtividade se, no caminho, a empresa passa a expor informações de clientes, credenciais, dados financeiros, documentos internos, histórico comercial ou qualquer contexto que deveria ser tratado com mais cuidado.
Para mim, uma operação madura com IA precisa nascer com algumas perguntas simples: este agente realmente precisa ver esse dado? Essa informação pode ser resumida ou anonimizada? Essa ação pode ser executada automaticamente ou precisa de aprovação humana? O que deve ficar registrado? O que não deve ir para o prompt? O que deve permanecer em ambiente controlado?
Isso também reforça a lógica do OPS. O objetivo não é colocar tudo dentro de um modelo e torcer para que ele use bem. O objetivo é organizar a operação para que contexto, acesso e execução sejam tratados com critério.
Dados sensíveis não devem circular sem necessidade. Ações críticas não devem acontecer sem revisão. Segredos, credenciais e informações privadas precisam estar protegidos por camadas adequadas, não jogados em conversas soltas.
Agentes não precisam saber tudo
Essa lógica se torna ainda mais importante quando falamos de uma squad agêntica.
Uma squad agêntica, do jeito que tenho pensado, não é um grande agente tentando entender tudo sobre tudo. Essa ideia de um agente universal, carregado com todo o contexto possível, parece sedutora no começo. Mas, na prática, ela pode gerar confusão, custo alto e pouca precisão.
O caminho que faz mais sentido é outro.
Em vez de um agente que sabe tudo, prefiro agentes que sabem o que precisam saber para executar bem uma tarefa.
Isso muda bastante a arquitetura mental do trabalho com IA.
Um agente não precisa carregar o mundo inteiro nas costas. Ele precisa receber o contexto certo, no momento certo, para o objetivo certo. Precisa entender sua função, seus limites, seus critérios de qualidade e o que deve devolver.
Quando precisa de mais informação, ele deve buscar ou pedir o contexto adequado. Quando não deve executar sozinho, precisa parar e encaminhar para revisão humana.
Essa abordagem é mais simples, mais segura e mais eficiente. Também otimiza custo.
Em IA, contexto demais também custa. Cada informação enviada para um modelo consome tokens. E tokens não são apenas uma unidade técnica: eles representam custo, latência e ruído. Quanto mais contexto desnecessário colocamos em cada tarefa, mais caro e potencialmente mais confuso fica o processo.
Por isso, uma boa operação com agentes não deve tentar colocar tudo em todos os lugares.
Ela precisa saber distribuir contexto.
O agente certo recebe o contexto certo para fazer a tarefa certa. E essa distribuição também é uma medida de segurança: cada agente deveria acessar apenas o que precisa para cumprir sua função, nada além disso.
Uma operação modular é mais adaptável
Essa ideia é muito importante para o OPS.
O OPS não precisa ser um lugar onde existe um agente que entende tudo da empresa, todos os clientes, todos os processos, todos os detalhes técnicos, todas as decisões, todas as exceções e todos os históricos ao mesmo tempo. Isso seria pesado, caro e provavelmente frágil.
O que me parece mais forte é construir uma base onde diferentes agentes possam operar com recortes de contexto bem definidos.
Cada agente trabalha com o que precisa saber. Cada tarefa puxa o contexto que faz sentido. Cada fluxo pode ser melhorado sem depender de um cérebro central onisciente.
Isso deixa a operação mais modular, mais auditável e mais adaptável.
Também combina melhor com a realidade de empresas.
No mundo real, ninguém entende tudo. Uma boa equipe não funciona porque uma pessoa sabe absolutamente tudo. Ela funciona porque existem papéis, especialidades, critérios, comunicação e uma forma clara de coordenar o trabalho.
Com agentes, a lógica não deveria ser tão diferente.
A pergunta não é "como criar um agente que sabe tudo?". A pergunta melhor é: "como criar uma operação em que cada agente sabe o suficiente para entregar bem a parte que lhe cabe?".
Essa mudança de pergunta reduz complexidade, reduz desperdício e ajuda a evitar um problema comum em projetos com IA: transformar contexto em bagunça.
Porque contexto não é só acumular informação. Contexto bom é informação organizada para uma finalidade. É saber o que importa para aquela tarefa, naquela etapa, com aquele nível de risco.
Transformar uso diário em ativo composto
É por isso que, para mim, o OPS é menos sobre automatizar tudo e mais sobre tornar a operação explícita, versionada e portável.
Quando a operação fica explícita, conseguimos melhorar. Quando fica versionada, conseguimos rastrear. Quando fica portável, conseguimos trocar ferramentas. Quando fica modular, conseguimos distribuir contexto. E quando conseguimos distribuir contexto, agentes ficam mais úteis, mais baratos e mais controláveis.
Essa é uma das ideias que mais me interessam no OPS: transformar uso diário em ativo composto.
Uma conversa pode virar aprendizado. Uma decisão pode virar referência. Um erro pode virar ajuste. Um processo pode virar padrão. Um bom prompt pode virar prática. Uma automação pode virar componente reutilizável. Uma dúvida recorrente pode virar documentação. Uma experiência com uma ferramenta pode virar critério para a próxima escolha.
A empresa deixa de apenas usar IA e passa a aprender a operar melhor com IA.
Existe uma diferença grande entre essas duas coisas.
Usar IA pode ser simplesmente abrir uma ferramenta e pedir ajuda. Operar melhor com IA exige contexto, critério, segurança, revisão, integração, documentação, processo e evolução contínua.
É menos glamouroso do que uma demo impressionante. Mas é muito mais sustentável. Também é mais honesto com a realidade.
No mundo real, uma boa resposta não basta. Precisamos de continuidade. Precisamos de responsabilidade. Precisamos de clareza. Precisamos de rastreabilidade. Precisamos de um jeito de melhorar sem recomeçar do zero toda vez que o mercado muda.
O mercado vai mudar. A operação precisa aguentar.
E o mercado vai mudar. Vai mudar muito.
Talvez os melhores modelos de hoje não sejam os melhores daqui a alguns meses. Talvez ferramentas que hoje parecem indispensáveis sejam substituídas. Talvez novas restrições apareçam. Talvez novas interfaces simplifiquem processos que hoje ainda são difíceis. Talvez agentes fiquem muito mais capazes. Talvez algumas promessas desapareçam.
Ninguém sabe com precisão.
Por isso, me parece cada vez menos inteligente apostar tudo em uma única peça desse tabuleiro.
Faz mais sentido construir capacidade de adaptação.
Para mim, esse é o melhor caminho que encontramos até agora: uma operação que aprende rápido, testa rápido, documenta o que importa, distribui contexto com cuidado, protege o que é sensível, troca ferramentas quando precisa e transforma experiência diária em método acumulado.
É assim que tenho pensado o OPS.
Não como uma ferramenta final. Não como uma resposta pronta. Mas como uma forma de manter a Tecelume preparada para evoluir junto com esse ambiente.
Uma estrutura onde as ferramentas podem entrar e sair sem que a empresa perca sua memória, seu método e sua direção.
Tecnologia deveria tecer clareza
No fundo, isso conversa muito com a própria ideia da Tecelume.
Tecnologia não deveria aumentar confusão. Tecnologia deveria tecer clareza.
Clareza para decidir. Compromisso para executar. Engenharia para sustentar. Pragmatismo para não complicar o que pode ser simples. Evolução contínua para melhorar com o uso, com o erro, com o feedback e com o tempo.
Eu não quero que a Tecelume seja definida por uma ferramenta específica de IA.
Quero que ela seja capaz de usar as melhores ferramentas disponíveis com critério, método e liberdade.
Essa liberdade não vem de ignorar dependências. Toda operação moderna depende de alguma coisa: modelos, APIs, clouds, bibliotecas, fornecedores, clientes, pessoas e processos.
A liberdade vem de saber onde está o centro da operação.
E eu não quero que esse centro esteja em uma assinatura, em uma interface, em uma memória de chat ou em uma promessa de roadmap de terceiros.
Quero que esteja em uma base clara, portátil, evolutiva e compreensível.
Uma base que permita usar modelos fortes, testar ferramentas novas, montar squads agênticas, evoluir processos e continuar aprendendo sem ficar preso ao formato de hoje.
Essa foi a reflexão que os vídeos me ajudaram a organizar melhor. E é a reflexão que o dia a dia tem confirmado.
Ferramentas passam. Método fica.
Em um mundo onde a IA muda rápido demais, talvez a maior vantagem não seja depender da ferramenta mais nova. Talvez seja ter uma operação preparada para aprender com qualquer ferramenta boa o suficiente.
Quer usar IA sem prender sua operação a uma ferramenta?
A Tecelume desenha software, automações e sistemas com IA para operações que precisam de contexto, segurança, rastreabilidade e capacidade real de adaptação.
Referências que motivaram a reflexão
- Fernando Ulrich: OpenAI e Anthropic sentem concorrência China, Trump vai intervir?. A reflexão aproveita a crítica sobre concorrência chinesa, pressão econômica nas grandes labs, clientes reagindo aos incentivos dos fornecedores e IA como disputa geopolítica.
- Lucas Montano: Nos prometeram Mythos e agora o Sol. A reflexão aproveita a leitura de que modelos de fronteira viraram infraestrutura estratégica e que dependência de uma única API ou plataforma virou risco de engenharia.
- LLM Wiki, de Andrej Karpathy.
- GBrain, repositório de Garry Tan.