As quatro camadas, e o que hipotecas em cada uma
A pergunta com que chega quase toda a gente é qual é a melhor das plataformas para criar agentes de IA. Não tem resposta, porque não há uma lista de produtos: há quatro camadas, e escolher a camada decide muito mais do que escolher a marca dentro dela. De cima para baixo: o assistente do fornecedor que já pagas, o builder no-code, a framework de código e o código próprio contra a API. Quanto mais acima, mais depressa tens algo a funcionar e menos controlo tens sobre o que acontece a seguir.
| Camada | O que é | Exemplos vivos | O que hipotecas |
|---|---|---|---|
| 1 · Assistente do fornecedor | O agente vive dentro do produto que já tens contratado | ChatGPT e os seus GPTs, Microsoft Copilot Studio, Google Gemini Enterprise, Claude | A portabilidade: sais com aquilo que o fornecedor tiver decidido deixar-te exportar |
| 2 · Builder no-code | Tela visual, conectores prontos, execução alojada | n8n, Make, Zapier Agents, Relevance AI | O histórico e as ligações. O fluxo costuma sair; o resto, conforme o plano |
| 3 · Framework de código | Uma biblioteca no teu repositório; a execução pões tu | LangGraph, CrewAI, OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, Pydantic AI | Nada de licença: são todos MIT ou Apache 2.0. Hipotecas equipa |
| 4 · Código próprio | A API do modelo mais as tuas integrações | Qualquer stack + MCP | Tempo. É a mais cara de arrancar e a mais barata de abandonar |
A regra que arruma essa tabela não é técnica. É que as camadas 1 e 2 te vendem velocidade hoje a troco de um custo de saída que não aparece em nenhuma página de preços. E esse custo só se paga quando já é tarde: no mês 7, quando o agente faz algo que importa e a pessoa que o montou já não está cá.
A prova de que a camada 1 caduca: o Agent Builder durou treze meses
Isto não é um aviso de consultor. A OpenAI apresentou o Agent Builder, a sua tela visual para montar agentes, em outubro de 2025. A 3 de junho de 2026 anunciou a descontinuação e fixou o desligamento para 30 de novembro de 2026. Hoje a sua própria documentação lista-o sob a epígrafe «Legacy APIs», ao lado da Assistants API, e publica um guia de migração. Treze meses de vida útil para aquilo que durante um ano foi «a plataforma de agentes da OpenAI». Fonte: Agent Builder, documentação da OpenAI, consultada a 7 de setembro de 2026.
As três perguntas de saída
Antes de olhares para uma única feature há três perguntas cuja resposta está na documentação pública do fornecedor e que decidem quanto custa ir embora. Respondem-se em vinte minutos, não dependem da demo e não é preciso que ninguém tas responda ao telefone.
Posso levar o prompt?
No ChatGPT, não totalmente. A OpenAI documenta que carregar conversas exportadas para outra conta não transfere «custom instructions, memories, GPTs, or other account settings». Traduzido: o histórico de conversa sai, mas a definição do GPT — as instruções que custaram semanas a afinar — não está no export. E há um segundo fio: o export self-service não está disponível nos espaços Business e Enterprise, que são justamente os que uma empresa compra; aí é preciso passar pelo proprietário do workspace. Fontes: Transfer exported conversations between ChatGPT accounts e Exporting your ChatGPT history and data, OpenAI Help Center, consultadas a 7 de setembro de 2026.
No outro extremo da mesma camada está o Copilot Studio. Um agente vive dentro de uma solução da Power Platform, e as soluções exportam-se e importam-se como ZIP entre ambientes; com a CLI (pac copilot clone / pull / push / pack) podes tê-lo como ficheiros em disco e metê-lo no git. Com uma nuance que convém dizer em voz alta: isso é portabilidade dentro da Power Platform, não para fora dela. E traz uma armadilha documentada — os agentes são criados por omissão na solução predefinida, e de lá não podem ser exportados; é preciso criar de propósito uma solução personalizada. Fontes: Solutions overview (29 de abril de 2026) e pac copilot (10 de julho de 2026), Microsoft Learn.
Posso levar o histórico?
É aqui que a camada 2 mostra a costura, e a resposta honesta é quase sempre «uma parte, e durante um tempo». O Zapier garante um máximo de 60 dias de histórico de execuções e mostra até 10.000. O Make arquiva as versões de blueprint assim que passam dos 60 dias. O n8n entrega-to por API pública e, se o alojares tu, a retenção decides tu. Fontes: View and manage your Zap history, Zapier Help; Scenario blueprints, Make Developer Hub; Execution API, n8n Docs. Consultadas a 7 de setembro de 2026.
Que o histórico importe não é evidente até ao dia em que precisas dele. É o que usas para perceber porque é que o agente fez aquilo em março, para construir o seguinte sobre o que o anterior já aprendeu e para responder a uma auditoria sem inventar. Um agente sem histórico exportável é um agente sobre o qual não podes construir no ano que vem.
Posso levar as integrações?
A resposta curta é que o fluxo exporta-se e as ligações não. O Make documenta-o sem rodeios: ao importar um blueprint, o utilizador tem de voltar a criar as ligações das suas contas. E no Zapier exportar os teus próprios fluxos é diretamente uma função paga — está disponível em Team e Enterprise, e não em Free nem em Professional. Fontes: Blueprints, Make Help Center; Import and export Zap workflows, Zapier Help. Consultadas a 7 de setembro de 2026.
Quem opera isto no mês 7
Este é o critério que decide a sério e o que ninguém olha na demo: quem vai estar à frente disto daqui a sete meses. Não quem o monta. Quem o mantém quando o modelo mudar, quando o fornecedor descontinuar alguma coisa e quando o processo deixar de ser o que era.
Um exemplo concreto, com a documentação do próprio produto na mão. O n8n tem três papéis de projeto — Admin, Editor e Viewer —, mas Editor exige plano Cloud Pro e Viewer exige Enterprise. No plano de entrada, portanto, o único papel de projeto disponível é Project Admin: toda a gente que entra no projeto pode apagar tudo. A própria n8n avisa ainda que não há forma de ver quem criou um workflow concreto, e recomenda ao proprietário criar uma segunda conta com papel Member para o trabalho do dia a dia. Isso não é um defeito escondido: está escrito na sua documentação, e quase ninguém a lê antes de contratar. Fontes: Available roles e Instance roles, n8n Docs, consultadas a 7 de setembro de 2026.
A Microsoft chega à mesma conclusão pelo outro lado. No seu guia de arquitetura para cargas de trabalho de IA recomenda começar com entre 5 e 10 perfis distintos para repartir o acesso, e justifica-o com uma frase que resume o problema inteiro: ao contrário dos sistemas tradicionais, onde sabes exatamente que serviços vão ser chamados e por que ordem, os sistemas agênticos tomam decisões por sua conta em tempo de execução. Daí que sejam precisas permissões concedidas mesmo a tempo e rastos que liguem a decisão autónoma à pessoa responsável. Fonte: AI workload personas, Azure Well-Architected Framework, 1 de abril de 2026.
Essa parte — identidade própria, âmbito por tarefa, revogação testada — decide-se antes de escolher plataforma, e está desenvolvida em que permissões dar a um agente de IA. Se o agente que tens na cabeça vai mexer em sistemas de várias equipas, a ordem certa é essa: primeiro o acesso, depois a tela.
O MCP normaliza o conector, não a identidade
O argumento que mais se ouve para desdramatizar o lock-in é o MCP: se tudo fala o mesmo protocolo, mudar de plataforma é desligar e voltar a ligar. É verdade a meias, e a metade que falta é a que custa dinheiro.
O que é mesmo verdade: o MCP deixou de ser de um fornecedor. Em dezembro de 2025 a Anthropic doou-o à Agentic AI Foundation, um fundo dirigido sob a Linux Foundation, com a AWS, a Google, a Microsoft e a OpenAI entre os seus membros platina. Os quatro grandes expõem hoje os seus serviços por MCP e anunciaram-no cada um por sua conta. Fonte: MCP joins the Agentic AI Foundation, blogue oficial do MCP, 9 de dezembro de 2025.
O que não: a autorização é opcional no próprio spec, e os detalhes do servidor de autorização ficam explicitamente fora do seu âmbito; cada servidor define os seus scopes. A prova mais honesta publicou-a a AWS no seu próprio blogue ao anunciar a disponibilidade geral do seu servidor MCP: para usar as suas credenciais locais de AWS sobre MCP, que só admite OAuth 2.1, configurou o agente para chamar o servidor através de um proxy. A maior cloud do mundo precisa de um intermediário para que o seu próprio modelo de identidade fale o protocolo. Fonte: The AWS MCP Server is now generally available, AWS News Blog, 6 de maio de 2026.
E o protocolo também parte para trás: a revisão de 28 de julho de 2026 retirou a troca initialize/initialized e o cabeçalho Mcp-Session-Id, deu por descontinuado o transporte HTTP+SSE herdado e o próprio anúncio reconhece que haverá custo de migração para quem dependesse dos identificadores de sessão. O MCP baixa o custo das integrações. Não o põe a zero, e não toca no da identidade. Fonte: Spec update 2026-07-28, blogue oficial do MCP.
A letra pequena do «open source»
Se a conversa chega ao self-hosting, é altura de ler a licença e não o slogan. O n8n não é open source no sentido da OSI: a sua licença é a Sustainable Use License v1.0, que permite usar e modificar o software apenas para fins internos do teu negócio ou para uso pessoal e não comercial, e distribuí-lo apenas de forma gratuita e com fins não comerciais. Além disso, os ficheiros com .ee no nome ou no diretório ficam fora dessa licença e exigem a Enterprise, e o conteúdo dos ramos diferentes de master simplesmente não está licenciado. Fonte: LICENSE.md, repositório do n8n, consultado a 7 de setembro de 2026.
Para uma empresa que automatiza a sua própria operação isso está coberto e não há drama. Para uma agência que opera n8n para os seus clientes, ou para quem pense revender o acesso, não está: é o momento de ler a licença Enterprise em vez de supor. A própria n8n chama ao seu modelo «fair-code» e não «open source», e fá-lo precisamente por isto.
A camada 3 não tem esta conversa. LangGraph, CrewAI, o Agents SDK da OpenAI, o Microsoft Agent Framework e o Pydantic AI são MIT; o ADK da Google é Apache 2.0. Aí o custo de saída não é de licença: é de equipa. Que é exatamente o critério da secção anterior, outra vez.
Como escolher numa tarde
- Escreve a frase do agente: o que faz, sobre que sistemas e quem fica a saber quando falha. Se não cabe numa frase, não escolhas plataforma ainda — escolhe processo.
- Põe nome e apelido a quem o vai operar no mês 7. Se essa pessoa não sabe ler código, a camada 3 não é uma opção por muito que seja a mais limpa de licença.
- Responde às três perguntas de saída com a documentação pública do candidato, não com o comercial dele: prompt, histórico, integrações.
- Verifica os papéis do plano que vais contratar, não os do plano enterprise do comparador. Se no teu plano toda a gente é administrador, já sabes o que vai acontecer no dia em que alguém se enganar.
- Exporta no primeiro dia, não no dia em que precisares. No dia em que a coisa funcionar, tira o export e guarda-o onde guardas tudo o resto.
Nenhum dos cinco passos fala de features, e é esse o ponto. As features de uma plataforma de agentes parecem-se cada vez mais umas com as outras de seis em seis meses; o que não converge é quem a pode operar e o que te deixam levar. Escolher pelo primeiro é escolher pelo que vai mudar. Escolher pelo segundo é escolher pelo que te vai limitar.
Nós montamos a parte que decide tudo isto: a infraestrutura sobre a qual o agente corre, com identidade própria, export desde o dia um e uma pessoa identificada que o opera — é a infraestrutura de IA empresarial que sustenta qualquer agente que trabalhe a sério. E se o que tens à frente ainda é a decisão anterior, comprar ou construir, está resolvida em comprar agentes de IA ou construí-los. Não vendemos plataforma. Cobramos por a que escolheres não te prender.