Há um ano, nos fizemos uma pergunta: “Como construiríamos nossa plataforma se começássemos do zero hoje?”

Clique e saiba mais

A pergunta surgiu naturalmente. Fundamos a Digibee para aproveitar todo o potencial da 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 legadas de iPaaS se apresentava como cloud-native, embora ainda operasse em modelos de lift-and-shift.

Até hoje, nossos clientes percebem essa diferença. E não aceitaríamos nada menos na era da IA.

Veja o que construímos para tornar a Digibee AI-native e o raciocínio por trás dessas decisões.

O trabalho de engenharia por trás do AI-native

Reavaliamos a Digibee a partir de seus princípios fundamentais. Nosso objetivo sempre foi permitir que profissionais de integração usassem a Digibee para criar fluxos de nível corporativo, com gerenciamento de credenciais, segurança e infraestrutura em nuvem com escalabilidade automática, na maior velocidade que a tecnologia disponível permitisse.

Com a chegada da IA agêntica, o trabalho deixa de estar concentrado na execução e passa a envolver mais delegação e estratégia.

Para tornar essa nova abordagem possível, tivemos que enfrentar alguns desafios importantes:

1. Tornar a experiência da plataforma tão intuitiva para agentes quanto para pessoas
2. Especializar e usar o Harness de agentes de IA para que atuem 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 deles.

Como agentes, e não pessoas, acessariam os recursos da plataforma?

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

A IA precisa de pontos de interação independentes, granulares e autoexplicativos. É algo semelhante ao que aconteceu com a criação de conjuntos de APIs durante a ascensão dos microsserviços. Mas essas APIs precisavam ser escritas e documentadas para desenvolvedores humanos, capazes de acompanhar estruturas hierárquicas de informação, transferir conhecimento de outros endpoints e interpretar nomes ambíguos.

LLMs não funcionam dessa forma. Diante de vários endpoints com nomes ambíguos, podem simplesmente escolher um deles e seguir em frente com confiança.

Nossa resposta

Criamos APIs e ferramentas MCP documentadas com uma linguagem clara, completa e independente de contexto adicional.

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

Quando usuários criam e iteram no Canvas da Digibee, a plataforma exibe a mensagem de erro do conector que apresentou a falha. Poderíamos mostrar o log de execução de todo o fluxo, mas optamos por não fazer isso. Os usuários não precisam de toda essa informação, e exibi-la apenas tornaria mais demorada a busca pelo que realmente importa.

LLMs, por outro lado, se beneficiam da análise do log completo de execução. O agente não necessariamente entende o que cada etapa anterior à falha deveria fazer, e incluir o log completo oferece mais contexto.

Esse é um exemplo específico, mas o mesmo princípio aparece em outras situações. Usuários humanos acumulam contexto de diversas formas, como pela representação visual e pela experiência com integrações semelhantes. Agentes constroem contexto apenas a partir das informações fornecidas durante a execução.

Nossa resposta

Criamos serviços voltados para agentes capazes de fornecer contexto aprofundado e estruturado para ser facilmente processado por LLMs.

Como fazer LLMs atuarem como engenheiros de integração experientes?

Como já discutimos em outros conteúdos, agentes de código generalistas não conseguem criar integrações corporativas. Eles são excelentes em tarefas realizadas dentro de uma base de código. O trabalho de integração, porém, depende de conhecimento organizacional.

Os sistemas com os quais as integrações precisam interagir muitas vezes sequer estão documentados. Os dados de treinamento das LLMs, aos quais os agentes podem recorrer mesmo quando recebem documentação específica, incluem pouquíssimos exemplos de como conectar sistemas corporativos menos conhecidos, especialmente sistemas legados.

Essa limitação dos dados de treinamento também se aplica ao conhecimento especializado em integração. A Digibee estrutura conhecimento e lógica de integração em um documento chamado flowspec. Eu ficaria surpreso se os dados de treinamento da Anthropic ou da OpenAI tivessem mais de dez exemplos desse tipo.

Há ainda outra complicação: o gerenciamento de contexto. Criar um fluxo de integração envolve diversas subtarefas diferentes. Tentar fazer um único agente cuidar de tudo pode prejudicar os resultados. O contexto fica longo demais e o agente começa a se perder.

Nossa resposta

Transformamos nosso conhecimento sobre flowspecs e sobre como integrações devem ser construídas em templates de prompts específicos. Escrevemos e reescrevemos tantos que dariam para encher uma estante inteira.

Nos bastidores, distribuímos esses templates entre subagentes especializados, capazes de entregar resultados com nível de especialista.

O usuário não vê nada disso. Ele interage com um único Digital Worker principal, que reúne o trabalho dos subagentes e cria um projeto completo e coeso, do início ao fim.

Como evolui o trabalho dos nossos usuários?

Nossa nova abordagem usa IA para criar versões iniciais de projetos e fluxos em colaboração com o usuário. As pessoas definem e orientam o projeto e, depois, validam o resultado.

O trabalho do especialista em integração não desaparece, mas muda, como Daniela Amodei, presidente e cofundadora da Anthropic, prevê que acontecerá com muitas profissões.

Para viabilizar essa mudança, precisávamos de interfaces para duas tarefas:

1. Definir a especificação do fluxo
2. Revisar o que o Digital Worker criou

Nossa resposta

Criar um ambiente para que o usuário pudesse revisar e ajustar o resultado do Digital Worker foi simples: já tínhamos o Canvas da Digibee.

Para permitir a colaboração durante o planejamento, criamos uma interface completamente nova. Ela combina uma janela de chat com um documento dinâmico dividido em várias abas.

O usuário começa descrevendo seu objetivo em alto nível. Depois, trabalha com o Digital Worker para criar uma especificação detalhada do projeto, incluindo casos de exceção, condições de acionamento e tratamento de erros.

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

Para os usuários da Digibee, ser AI-native significa trabalhar em um nível mais estratégico. Eles ainda revisam e ajustam no Canvas o que o Digital Worker cria, mas não precisam mais arrastar e soltar cada componente.

Nos primeiros testes com design partners, os usuários concluíram fluxos até 20 vezes mais rápido.

E esse avanço chega em um momento importante para os times de integração. A IA aumentou a demanda por integrações à medida que pessoas em toda a empresa criam agentes que precisam acessar sistemas corporativos.

Além de ajudar a reduzir o backlog, essa abordagem 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? Quais oportunidades de gerar impacto para o negócio ainda não foram exploradas?

Historicamente, os times de integração não tinham tempo para responder a essas perguntas.

Pergunte sobre o chatbot

Lift-and-shift era uma forma simples de identificar o cloud-washing. Para AI-native, o teste é ainda mais simples: pergunte ao fornecedor se ele redesenhou sua plataforma para agentes ou apenas adicionou um chatbot.

Adicionar IA a produtos existentes cria os mesmos problemas que o lift-and-shift criou. Isso limita o que uma reconstrução genuína pode oferecer e mantém a empresa em um estágio intermediário por mais tempo do que o esperado.

A mesma lógica vale internamente. Os maiores ganhos não vêm apenas de acelerar os fluxos existentes. Eles surgem quando questionamos quais desses fluxos ainda deveriam existir da forma como existem hoje.

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

‍