Há um ano, fizemos a seguinte pergunta: “como construiríamos nossa plataforma se começássemos do zero hoje?”

A pergunta surgiu naturalmente. Fundamos a Digibee para aproveitar ao máximo a tecnologia em nuvem em um momento em que ela estava transformando o que era possível para softwares B2B. Na época, a maioria das plataformas iPaaS legadas se apresentava como cloud-native (mas ainda operava no modelo “lift-and-shift”).

Até hoje, nossos clientes veem e sentem essa diferença. E não aceitaremos nada menos do que isso na era da IA.

Veja o que construímos para tornar a Digibee AI-native, e o raciocínio por trás dessa decisão.

O trabalho de engenharia por trás do conceito

Reavaliamos a Digibee a partir dos primeiros princípios. Nosso objetivo sempre foi permitir que profissionais de integração utilizassem a Digibee para criar workflows de nível corporativo (com gerenciamento de credenciais, segurança e infraestrutura em nuvem com escalabilidade automática) o mais rápido que a tecnologia disponível permitisse. Com a chegada da IA agêntica, o trabalho deixa de estar centrado na execução e passa a focar em delegação e estratégia.

Para transformar essa nova visão em realidade, precisávamos enfrentar alguns desafios importantes:

1. Tornar a experiência da plataforma tão intuitiva para agentes quanto já é para pessoas
2. Especializar e capacitar agentes de IA para atuarem como engenheiros de integração experientes
3. Evoluir a forma como as pessoas trabalham com essa nova força de trabalho digital

Veja como resolvemos cada um desses desafios.

Como agentes (e não humanos) acessariam os recursos da plataforma?

Pessoas precisam de interfaces visuais para interagir com softwares. Precisam de menus. Precisam de botões. Precisam de campos de formulário.

A IA precisa de pontos de interação atomizados e autoexplicativos. Isso é semelhante ao surgimento de suítes de APIs durante a ascensão da arquitetura de microsserviços. Mas essas APIs precisavam ser escritas e documentadas para desenvolvedores humanos, capazes de acompanhar estruturas hierárquicas de informação, transferir conhecimento entre endpoints e interpretar nomes ambíguos.

LLMs não funcionam dessa forma. Diante de vários endpoints com nomes ambíguos, eles seguem confiantes por qualquer um deles.

Nossa resposta
Criamos APIs e ferramentas MCP documentadas com uma linguagem clara e autocontida.

O que é útil para agentes (mas não para pessoas)?

Quando usuários criam e evoluem integrações no canvas da Digibee, a plataforma exibe a mensagem de erro do conector que falhou. Poderíamos fornecer todo o log de execução do workflow, mas optamos deliberadamente por não fazer isso. Os usuários não precisam dele, e apresentar o log completo apenas tornaria mais lenta a busca pela informação realmente relevante.

Já os LLMs se beneficiam de analisar todo o log de execução. O agente não necessariamente entende qual era a função de cada etapa anterior à falha, e disponibilizar o log completo adiciona contexto.

Esse é um exemplo específico, mas o princípio se repete em diversos outros cenários. Usuários humanos acumulam contexto por diferentes meios, como a representação visual da integração e sua experiência com integrações semelhantes. Agentes obtêm contexto apenas a partir das informações que recebem durante a execução.

Nossa resposta
Desenvolvemos serviços voltados para agentes capazes de fornecer contexto profundo, estruturado para o consumo ideal por LLMs.

Como fazemos LLMs se comportarem como engenheiros de integração experientes?

Como já explicamos em outros conteúdos, agentes de código genéricos não conseguem construir integrações corporativas. Eles são excelentes trabalhando dentro de uma base de código. O trabalho de integração existe em um nível de conhecimento organizacional.

Os sistemas com os quais integrações precisam interagir frequentemente não possuem documentação adequada. Os dados de treinamento dos LLMs (nos quais os agentes podem se apoiar, mesmo quando recebem documentação) contêm pouquíssimos exemplos de como conectar sistemas corporativos pouco conhecidos, especialmente sistemas legados.

Essa limitação também se aplica ao conhecimento sobre integração. A Digibee codifica conhecimento e lógica de integração em um documento chamado “flowspec”. Eu me surpreenderia se os dados de treinamento da Anthropic ou da OpenAI tivessem visto mais de 10 exemplos desse tipo.

Há ainda outra complicação: gerenciamento de contexto. Construir um workflow de integração exige várias subtarefas diferentes. Tentar fazer um único agente lidar com tudo isso tende a comprometer os resultados. O contexto cresce demais e o agente começa a se confundir.

Nossa resposta
Transformamos nosso conhecimento sobre flowspecs e sobre a forma correta de construir integrações em templates de prompts especializados. Escrevemos, revisamos e reescrevemos uma verdadeira biblioteca deles. Nos bastidores, distribuímos esses templates entre subagentes especializados, que entregam resultados em nível de especialista.

O usuário não vê nada disso. Ele interage com um único trabalhador digital principal, que reúne o trabalho dos subagentes e entrega um projeto completo de ponta a ponta.

Como o trabalho dos nossos usuários (humanos) evolui?

Nossa nova abordagem utiliza IA para elaborar projetos e workflows, mas faz isso em colaboração com o usuário. O usuário define os objetivos, conduz o projeto e valida o resultado. O papel do especialista em integração não desaparece, mas muda, exatamente como Daniela Amodei, presidente e cofundadora da Anthropic, prevê para diversas profissões. 

Para tornar essa mudança possível, precisávamos criar interfaces para duas tarefas:

1. Definir a especificação do workflow
2. Validar o que o trabalhador digital construiu

Nossa resposta
Criar uma interface para que o usuário revisasse e ajustasse o resultado do trabalhador digital foi simples. O canvas da Digibee já existia.

Para possibilitar a colaboração durante o planejamento, desenvolvemos uma interface totalmente nova. Ela combina uma janela de chat com um documento vivo organizado em múltiplas abas. O usuário começa descrevendo seu objetivo em alto nível. Depois, trabalha em conjunto com o trabalhador digital para construir uma especificação detalhada do projeto, incluindo casos de borda, condições de disparo e tratamento de erros.

Integração em um nível mais estratégico

Para os usuários da Digibee, AI-native significa trabalhar em um nível mais estratégico. Embora continuem revisando e ajustando o que o trabalhador digital cria no canvas, eles deixam de montar manualmente cada componente por meio de drag-and-drop. Nos primeiros testes realizados com parceiros de design, os usuários concluíram workflows até 20 vezes mais rápido.

Esse avanço chega em um momento importante para as equipes de integração. A IA aumentou a demanda por integrações, à medida que usuários de empresas inteiras criam agentes que precisam acessar sistemas corporativos. Além de reduzir o backlog, isso libera especialistas em integração para pensar de forma mais estratégica. Quais processos podem ser centralizados em cápsulas para facilitar a manutenção? Que oportunidades de impacto para o negócio ainda não identificamos?

Historicamente, essas são perguntas para as quais as equipes de integração nunca tiveram tempo.

Pergunte sobre o chatbot

“Lift-and-shift” era o teste mais simples para identificar cloud-washing. O equivalente para AI-native é ainda mais simples: pergunte a qualquer fornecedor se ele redesenhou seu produto para agentes ou apenas adicionou um chatbot.

Adicionar IA sobre produtos existentes cria exatamente os mesmos problemas que o lift-and-shift criou. Isso impede que você aproveite tudo o que uma reconstrução genuína torna possível e mantém sua empresa em um estado intermediário por muito mais tempo do que deveria.

A mesma lógica vale internamente. Os maiores ganhos não vêm de acelerar workflows existentes. Eles surgem quando você questiona quais desses workflows realmente deveriam continuar existindo da forma como existem hoje.

[Tenha acesso antecipado à primeira plataforma de integração AI-native →]