Delphi na Era dos Agentes

Capítulo 1 - Delphi na era dos agentes

Uma gerente precisa saber quais produtos estão abaixo do estoque mínimo e quais fornecedores costumam atender esses itens. Em muitos sistemas corporativos, responder exige abrir telas diferentes, exportar relatórios, aplicar filtros e interpretar dados antes de tomar qualquer providência. O processo funciona, mas depende de alguém conhecer o caminho exato dentro do Enterprise Resource Planning (ERP), o sistema integrado de gestão da empresa.

Agora imagine a mesma pergunta feita em uma interface de linguagem natural. A resposta não deveria nascer de uma consulta solta ao banco de dados, nem de uma Inteligência Artificial (IA) que tenta adivinhar tabelas, campos e regras fiscais. Ela precisa resultar de capacidades que o sistema já reconhece: consultar estoque, localizar fornecedor, recuperar histórico de compra e preparar uma cotação. A diferença parece sutil, mas muda o ponto em que a IA encontra o software.

Durante muito tempo, a principal fronteira de um ERP foi a tela. O usuário humano navegava pelos menus, preenchia campos e confirmava operações. Depois, uma interface de programação de aplicações (API) passou a permitir que outros programas usassem parte dessas funções por contratos definidos. Na era dos agentes, surge uma nova fronteira: um agente de IA pode descobrir capacidades declaradas pelo sistema, usar contexto fornecido por ele e solicitar ações dentro de limites definidos. O sistema continua responsável pelas regras; o agente passa a ser uma nova forma de interação e orquestração.

Este livro trata dessa mudança no contexto de aplicações Delphi. A proposta não é substituir uma aplicação corporativa por um modelo de linguagem, nem permitir que um modelo escreva comandos contra um banco de produção. É construir uma camada explícita entre o agente e as regras de negócio, para que o ERP seja útil a novos fluxos sem deixar de ser governável.

Uma aplicação Delphi que atende uma empresa normalmente concentra conhecimento de negócio acumulado por anos. Há regras de desconto, limites de crédito, regras tributárias, aprovações, cadastros e exceções que não aparecem inteiramente na estrutura física do banco. Em um sistema bem organizado, esse conhecimento não pertence ao formulário nem à consulta escrita em Structured Query Language (SQL), a linguagem usada para consultar e alterar bancos relacionais: ele pertence aos serviços e às regras que a aplicação executa.

Quando uma pessoa usa uma tela de pedido, a própria interface impõe uma sequência. Ela escolhe o cliente, informa os itens, vê o limite de crédito, confirma os valores e, se tiver permissão, conclui a operação. Um agente não enxerga automaticamente essa sequência. Para atuar com segurança, ele precisa receber uma descrição inequívoca do que pode pedir ao sistema e do que cada pedido significa.

É útil separar três formas de integração:

Uma capacidade de negócio descreve uma ação que faz sentido para a empresa. consultarestoquebaixo informa um problema que a área de compras reconhece. prepararcotacaocompra gera uma proposta que ainda será avaliada. Já uma ferramenta como executarsql transfere para o agente uma decisão que deveria continuar sob responsabilidade do sistema: quais dados podem ser lidos, quais filtros são obrigatórios e quais efeitos uma alteração produz.

Essa separação não elimina a necessidade de APIs. Pelo contrário: uma boa camada orientada a agentes costuma apoiar-se em serviços já existentes. A diferença é que ela não expõe o ERP como um conjunto indiferenciado de tabelas ou endpoints. Ela apresenta operações na linguagem do negócio, valida parâmetros e preserva autorização, registro e aprovação.

Um agente de IA recebe um objetivo, seleciona informações e ferramentas disponíveis e pode executar uma sequência de chamadas para chegar a uma resposta ou a uma ação. Nesse processo, um modelo de linguagem ajuda a interpretar o pedido do usuário e a decidir qual capacidade usar. Isso não significa que o modelo deva ganhar autorização para fazer qualquer coisa que consiga formular em texto.

O Model Context Protocol (MCP) padroniza a comunicação entre aplicações de linguagem e serviços que oferecem contexto e capacidades. Na arquitetura do protocolo, uma aplicação hospedeira mantém a conexão, clientes atuam como conectores e servidores oferecem recursos, prompts e ferramentas. As ferramentas representam funções que o modelo pode solicitar; por isso precisam ser tratadas com cautela e sob controle explícito do usuário e do sistema (MODEL CONTEXT PROTOCOL, 2026).

Neste livro, a palavra agente designa