Como operar diferentes harnesses, modelos e agentes em um mesmo ambiente de desenvolvimento
Há algumas semanas, apresentei o Omnigent em um Databricks User Group. Desde então, o produto continuou recebendo atualizações frequentes, mas o problema que motivou a conversa permanece: cada agente de código está preso ao seu próprio harness.
Hoje podemos escolher entre Claude Code, Codex, Cursor, OpenCode e várias outras ferramentas. Essa variedade é positiva, mas também cria uma fragmentação. Cada agente tem uma interface, uma configuração, uma forma de autenticação e um modo diferente de lidar com custos, permissões e execução.
O Omnigent aparece nesse cenário como uma camada comum acima desses agentes. Ele não pretende substituir o Claude Code, o Codex ou qualquer outro harness. A ideia é operar essas ferramentas em um mesmo ambiente, com composição, governança, colaboração e acompanhamento.
Antes de falar do Omnigent, vale separar alguns conceitos. Um modelo de linguagem é o recurso que gera as respostas. O harness é a estrutura construída ao redor do modelo para realizar uma tarefa de desenvolvimento: interpretar o pedido, conversar com o usuário, acessar ferramentas, executar comandos, verificar resultados e continuar trabalhando até alcançar o objetivo.
É nesse nível que surgiram ferramentas como Claude Code, Codex, Cursor e OpenCode. Cada uma oferece uma experiência própria e pode funcionar muito bem. O problema começa quando uma empresa quer usar mais de uma delas.
Um desenvolvedor pode preferir Codex para planejar uma solução e Claude Code para implementá-la. Outra pessoa pode trabalhar melhor com Cursor. O time não deveria precisar escolher uma única experiência para todos os casos, nem aceitar que cada agente opere como uma ilha.
O Omnigent entra acima dos harnesses como um metaharness. Ele coordena os agentes, aplica políticas e acompanha o que está acontecendo em cada sessão.
Na prática, isso permite usar diferentes harnesses em uma mesma ferramenta. A pessoa pode alternar entre eles sem sair do ambiente, mantendo uma experiência semelhante de desenvolvimento. O terminal, os arquivos modificados, o histórico, as sessões e o fluxo de revisão continuam disponíveis no mesmo contexto.
Essa camada também permite compor agentes para funções específicas. Em vez de apenas escolher um agente pronto, uma empresa pode criar um agente com instruções, habilidades e regras próprias. Foi o que demonstrei com um agente baseado na identidade visual da DEX: ele podia produzir apresentações e conteúdos respeitando as cores, o estilo e as regras definidas pela empresa.
O objetivo não é tirar a liberdade das equipes. É permitir que a liberdade venha acompanhada de um padrão operacional.
As áreas de negócio já estão experimentando agentes e criando aplicações com eles. Tentar impedir esse movimento tende a gerar ferramentas paralelas, sem visibilidade e sem governança. Para a TI, o desafio passa a ser oferecer liberdade com controles suficientes para que a inovação possa acontecer de forma segura.
O Omnigent ajuda a tratar alguns pontos que ficam dispersos quando cada pessoa usa uma ferramenta diferente:
O custo é um exemplo importante. Em vez de contratar uma licença fixa para cada pessoa, a organização pode disponibilizar diferentes modelos por meio de API, assinatura ou gateway e acompanhar o consumo de tokens. Essa escolha depende do cenário, mas a camada de governança passa a existir.
O Omnigent também pode aplicar limites e políticas para controlar sessões, custos e ações permitidas. Isso não significa que ele escolha automaticamente o modelo mais barato em toda situação. O modelo, o nível de esforço e as credenciais continuam fazendo parte da configuração da sessão. A governança pode definir limites e regras para esse uso.
Uma implantação corporativa separa o servidor do ambiente que executa o agente. O servidor é a interface e o ponto de coordenação das sessões, usuários e políticas. O host é o ambiente conectado ao servidor que executa o harness; ele funciona como runner.
No meu ambiente, usei uma máquina específica para essa função. Assim, os agentes e suas ferramentas ficam instalados no runner, e não necessariamente no computador de cada colaborador. Também é possível conectar o próprio computador como host, dependendo do nível de controle e isolamento desejado.
O runner pode trabalhar com um serviço de Sandbox. A ideia é executar comandos e código em um ambiente isolado, reduzindo o risco de uma biblioteca ou operação do agente afetar diretamente a máquina principal. O Omnigent possui integrações com provedores de Sandbox, incluindo o Databricks Sandbox.
Cenário ilustrativo baseado na arquitetura apresentada na documentação do Databricks Sandbox.
Esse cenário pode substituir a necessidade de manter uma máquina virtual dedicada para cada caso de uso. O servidor continua coordenando a experiência, enquanto o Sandbox fornece um ambiente isolado para a execução. A configuração concreta depende da infraestrutura, da rede e das políticas da organização.
No fluxo básico de conexão, os comandos apresentados foram:
# Autentica no servidor, quando a autenticação está habilitada
omni login <server-url>
# Registra o host que executará os agentes
omni host <server-url>O Omnigent também pode ser usado para criar agentes reutilizáveis. Um agente pode carregar conhecimentos e instruções de uma área específica, como marca, marketing, vendas, engenharia ou suporte.
Na demonstração, além do agente de identidade visual, mostrei uma automação que buscava novidades no blog da Databricks, traduzia o conteúdo e preparava uma análise sobre sua relevância para clientes da DEX. A mesma lógica pode ser aplicada a tarefas recorrentes de pesquisa, revisão e produção de conteúdo.
O agente não precisa trabalhar sozinho. Também é possível criar fluxos em que diferentes agentes analisam um problema, revisam as respostas uns dos outros ou discutem alternativas de implementação. Esse tipo de colaboração é uma das possibilidades mais interessantes quando deixamos de pensar em um único agente respondendo a uma pessoa.
A experiência de desenvolvimento continua próxima do que já existe nos harnesses. O agente pode acessar o terminal, alterar arquivos, mostrar diffs, executar validações e trabalhar em uma branch. O Omnigent acrescenta a possibilidade de acompanhar esse trabalho e integrá-lo ao fluxo de Git.
Na apresentação, mostrei integrações com GitHub, Azure DevOps e GitLab. A ideia é revisar as alterações, criar ou acompanhar pull requests e manter o trabalho do agente conectado ao processo de engenharia da empresa.
Isso não elimina a revisão humana. Pelo contrário: torna mais importante que a empresa tenha políticas claras sobre permissões, aprovações, custos e acesso aos repositórios.
O Omnigent é um projeto open source da Databricks. Ele pode ser instalado e executado pela organização, com diferentes opções de infraestrutura e de acesso aos modelos. A conexão pode envolver assinatura, API key ou um gateway corporativo, como o Databricks Model Serving e o Databricks AI Gateway, conforme a configuração adotada.
O ponto central é a abstração: a empresa não precisa obrigar todos a usar o mesmo harness para conseguir governar o uso de agentes. Pode oferecer diferentes opções, aplicar políticas comuns e acompanhar o trabalho em um ambiente compartilhado.
Agentes de código não são apenas uma nova interface para modelos de linguagem. Eles estão se tornando uma parte do processo de engenharia e, por isso, precisam de identidade, isolamento, observabilidade, controle de custos e colaboração. O Omnigent é uma proposta para organizar essa camada que surgiu ao redor dos agentes.