O que é um agente de IA?

Quase toda página que vende um agente o apresenta como um produto indivisível: você compra, ou não compra. É cômodo para vender e enganoso para decidir, porque um agente não é um bloco. São três coisas separáveis.

O harness é o programa que roda o ciclo: prompt de sistema, gestão do contexto, limites de segurança, roteamento para as ferramentas, recuperação de erro.

O modelo é o LLM. É a camada de que todo mundo fala, e a única que realmente se troca.

As ferramentas e as skills são o que o agente pode fazer e o que ele sabe fazer. Duas coisas diferentes — já voltamos a isso.

Guarde a conclusão antes do detalhe: a camada mais comentada é a mais substituível, e as outras duas são as que pertencem a você.

Uma demonstração de agente cabe num prompt. Um agente em produção cabe no harness — e é justamente o que as demonstrações nunca mostram.

• O prompt de sistema — o papel, os limites, o tom, o que o agente não tem direito de fazer.
• O ciclo — quando chamar uma ferramenta, quando parar, quantas voltas antes de desistir.
• A gestão do contexto — uma conversa longa estoura a janela do modelo. É preciso resumir, podar, decidir o que guardar. Feito sem cuidado, o agente esquece o essencial e retém a conversa fiada.
• Os limites de segurança — o que é verificado antes de uma ação sair, e o que exige aprovação humana.
• A recuperação de erro — uma API que cai, uma ferramenta que devolve algo inesperado, um modelo que inventa um argumento. Em produção isso acontece todo dia.

Isso é software, não prompt. E é reaproveitável: o mesmo harness serve vários agentes. É também por isso que "basta uma assinatura" não é uma resposta completa — a assinatura dá o modelo, não o ciclo.

Claude, GPT, Gemini, um modelo de pesos abertos rodando atrás de um agente como o Hermes. Não são equivalentes em tudo, mas fazem o mesmo papel na arquitetura: raciocinam e decidem qual ferramenta chamar.

Trocar de modelo é a mudança mais barata — não uma mudança gratuita. Os prompts precisam de ajuste, a confiabilidade da chamada de ferramenta varia, as janelas de contexto diferem. Conte dias, não meses. Compare com reconstruir ferramentas, que se conta em semanas.

Nenhum assistente generalista embarca telefonia. Transformar um agente em atendimento telefônico exige uma operadora, transcrição, síntese de voz e um orçamento de latência que decide se o resultado é utilizável. Não é fraqueza do modelo: é uma camada de interface, e ela pede infraestrutura.

Uma ferramenta é uma função que o modelo pode chamar: ler uma agenda, emitir uma nota, consultar um banco. É determinística — o agente faz algo.

Uma skill é um procedimento escrito, carregado quando serve: como se redige um orçamento na sua empresa, em que ordem, com quais menções. Não é executável — o agente sabe como fazer.

Confundir as duas custa caro, porque aí se tenta programar o que deveria ser escrito, ou escrever o que deveria ser executado.

MCP, e por que isso muda o jogo

O Model Context Protocol é a forma padrão de ligar uma ferramenta a um agente. Os principais agentes o adotaram, e a consequência é simples: uma ferramenta escrita uma vez funciona com o próximo modelo e com o próximo harness.

Você sai do Claude para o ChatGPT, ou para um modelo aberto que você mesmo hospeda: suas ferramentas vão junto. Só o harness se reajusta, e ele é feito para isso.

É o que torna coerente uma posição que poderia parecer contraditória: dizer "não dependa de um fornecedor" enquanto se trabalha com modelos comerciais. Não vendemos um modelo. Construímos ferramentas que sobrevivem ao modelo.

Três camadas bastam para descrever um agente. São precisas mais três para ele parar de pé em produção.

Memória e conhecimento. O curto prazo é a janela de contexto. O médio, arquivos de trabalho. O longo, um banco ou um índice. Não é harness: persiste entre sessões, e é seu ativo. Quem detém a memória detém o valor.

Interface. Como se alcança o agente: um chat, o Slack, um e-mail, o telefone, uma tarefa agendada, uma API. O mesmo agente atrás de duas interfaces são dois produtos diferentes para quem usa — e é aí que mora, de verdade, a questão da voz.

Governança. Com quais credenciais o agente age, o que tem permissão de fazer, o que fica registrado, como se sabe que ainda funciona. É o que separa uma demonstração de um sistema, e é a pergunta a fazer antes de assinar: quem detém os acessos?

Não existe resposta geral. Existe um critério.

Comprar ganha quando a necessidade é padrão, quando precisa rodar esta semana, e sobretudo quando a solução embarca uma infraestrutura que você não tem — telefonia em primeiro lugar. Um produto pronto já resolveu problemas que você não quer resolver.

Construir ganha quando o processo é seu e não do setor, quando os dados não podem sair, e quando o horizonte passa de dois anos. Em três anos, uma assinatura por usuário costuma custar mais do que se teria pago uma vez só.

O critério esconde uma terceira opção, que é a mais comum na prática: comprar a base e construir o que distingue você. Você assina um modelo e investe nas ferramentas e no harness — as duas camadas que continuam suas quando o resto muda.

Compare totais, não preços de vitrine.

Produto pronto: a assinatura por usuário por mês, a configuração inicial, os conectores cobrados à parte, e o custo de saída — quanto tempo para retomar seus dados e seus processos no dia em que você sair.

Construído: o desenho, o desenvolvimento das ferramentas, a assinatura do modelo que continua devida, a hospedagem e a manutenção. O orçamento é mais pesado no começo e mais plano depois.

O número que quase ninguém calcula é o custo de saída. Não aparece no primeiro ano e decide tudo no terceiro.

Sem nós, e sem orçamento.

1. Escolha uma tarefa repetitiva e chata que alguém faz à mão várias vezes por semana. Não a mais estratégica: a mais regular.
2. Escreva o procedimento como se explicasse a alguém recém-contratado. Se você não consegue, nenhum agente vai conseguir — e você acabou de aprender algo útil.
3. Faça à mão com um assistente, copiando e colando, durante uma semana. Você verá onde trava antes de escrever uma linha de código.
4. Liste as ferramentas que precisariam ser ligadas para eliminar o copiar-colar. Essa lista é o seu escopo.

Quatro passos, algumas horas, e projetos inteiros evitados.