A IA muda a cada trimestre. Suas conexões não deveriam.

Na terça, um time migra do ChatGPT para o Claude. A assinatura leva trinta segundos. A configuração leva três semanas.

Não porque o Claude seja difícil. Porque onze apps estavam conectados dentro do ChatGPT, cada um com seu grant OAuth, seus escopos, seu pedacinho de memória institucional. O novo assistente começa sem nada disso. Alguém reautoriza Gmail, Slack, Notion, Stripe e o banco interno. Alguém descobre que o assistente antigo tinha um escopo de calendário mais amplo do que o novo permite. Alguém pergunta por que a trilha de auditoria tem um buraco no dia da troca, e ninguém tem uma boa resposta.

A fatura do modelo é visível. A fatura da troca não é, e costuma ser maior.

Eu criei o Vinkius, e este é o padrão que vejo em quase todo time que usa IA a sério. O assistente é tratado como o lugar onde o trabalho acontece, então as conexões são construídas ali. Mas o assistente é a camada menos durável da pilha. Modelos mudam a cada trimestre. Clientes mudam o modelo de conector, a tela de configuração, o preço. Os apps que você conecta são a parte estável. A relação entre as suas pessoas e esses apps é o ativo.

O erro é arquitetural, não tático. Padronizamos a chamada de ferramenta com o MCP e depois deixamos cada cliente ser dono da conexão que a produz. O resultado é uma camada de conexão duplicada por assistente, por usuário, por dispositivo, e impossível de auditar como um sistema só.

Trocar de IA deveria ser um paste, não uma migração.

A fatura que você não vê

Toda troca tem um custo visível e um custo escondido. O visível é a assinatura, o número de assentos, o email de migração. O escondido é o trabalho de reconstruir a relação entre o seu time e os seus apps, uma tela de consentimento por vez.

O que uma troca realmente custa	O que acontece	Por que se acumula
Reautenticação	Cada app pede consentimento de novo, por cliente	Cada grant cria um token novo, com expiração e escopo próprios
Deriva de permissão	O novo cliente expõe um modelo de permissão diferente	A política mora na interface, então é recriada à mão
Descontinuidade de auditoria	Os logs ficam com o provedor antigo	Não existe uma linha do tempo única atravessando a troca
Reconstrução de integração	Cada cliente tem seu formato de conector	O trabalho se repete para cada app e cada cliente
Confusão de identidade	Contas pessoais e de trabalho se misturam	A conta errada pode agir com a intenção certa
Perda de contexto	Prompts, favoritos e rotinas ficam para trás	O assistente esquece como o seu time trabalha

Nada disso aparece em benchmark. Tudo isso aparece no primeiro mês.

Três camadas de lock-in

O lock-in de modelo é o que todo mundo discute. É real, mas tem preço. Você pode medir, negociar, desviar por um segundo provedor, e o mercado segue empurrando o preço para baixo.

O lock-in de cliente é o que todo mundo sente. É o hábito, o atalho de teclado, a convenção do time, o projeto que já mora numa barra lateral. Também é real, mas é sobretudo um problema de UX, e problemas de UX têm o costume de serem resolvidos no próximo release.

O lock-in de conexão é o que ninguém nomeia. É o custo de reconstruir a relação entre as suas pessoas e os seus apps toda vez que a interface muda. Não aparece em contrato. Aparece como três semanas de configuração e um buraco na trilha de auditoria.

Desenhe a matriz. Cinco assistentes nas colunas, doze apps nas linhas. Sessenta células. Cada célula precisa de um fluxo de autenticação, uma credencial, um escopo, uma política e uma linha de log. Agora adicione um segundo usuário, um segundo dispositivo, um segundo framework de agentes. A matriz multiplica, e cada célula é mantida por alguém que não a construiu.

Uma camada de conectividade colapsa a matriz. Os apps são conectados uma vez. Cada cliente recebe um link. A política e o registro moram na camada, não na célula.

O que quebra quando a conexão mora dentro do cliente

A credencial herda a postura de segurança do cliente. O jeito mais rápido de conectar um app a um assistente é colar um token na configuração dele. Agora o token está no armazenamento do cliente, nos logs dele, sob a política de retenção dele, e na janela de contexto de um modelo que você não controla. Uma conexão que mora no cliente herda a postura de segurança do cliente, o que não é uma frase que qualquer time de segurança queira assinar.

O modelo de permissão é recriado à mão. Cada cliente tem sua própria ideia do que um conector pode fazer. Uma permissão que existe em um assistente pode não existir no próximo, e a política cuidadosamente desenhada na segunda é reconstruída de memória na quarta. A deriva é invisível até uma ação que deveria ter sido bloqueada dar certo.

A trilha de auditoria se parte na troca. Quando a chamada é feita pelo cliente, o registro é feito pelo cliente. Troque de cliente e a linha do tempo se divide em duas. A pergunta depois de um incidente não é "o que o modelo disse", mas "quem autorizou esta ação, para qual conta, a que horas". Um log por cliente não responde isso entre clientes.

A manutenção nunca acaba. Cada cliente lança um formato novo de conector, uma tela nova de configuração, um JSON novo. Cada app muda sua API, seus escopos, seu fluxo OAuth. O trabalho de integração não desaparece quando você passa para um conector gerenciado. Ele passa para quem mantém o conector, e se essa pessoa é você, ele volta todo trimestre.

A identidade vira compartilhada. Um link colado num canal do time é uma identidade compartilhada. Um token commitado num repositório é uma identidade compartilhada. Uma conexão que deveria pertencer a uma pessoa agora pertence a todo mundo que consegue ler o canal. A conexão precisa estar presa a uma pessoa, não a uma janela de chat.

Portabilidade é arquitetura, não botão de exportar

A palavra portabilidade costuma significar um botão que exporta seus dados. Isso não basta. Um CSV das suas conexões não as reautentica, não carrega permissões, não preserva a trilha de auditoria e não faz o próximo cliente funcionar. Portabilidade é uma propriedade do caminho, não de um arquivo.

Uma conexão é portátil quando atende a oito requisitos:

Requisito	O que significa na prática
Endpoint estável	Uma URL por usuário que não muda quando o cliente muda
Presa à identidade	O endpoint carrega a pessoa, não a janela de chat ou o dispositivo
Protocolo aberto	A fronteira fala MCP, então qualquer cliente compatível encaixa
Credenciais externas	Segredos moram num cofre, nunca no cliente ou no contexto do modelo
Política externa	A autorização é avaliada por ação, fora da interface do cliente
Auditoria externa	Toda chamada é registrada na camada, numa linha do tempo só
Token revogável	O link pode ser revogado e reemitido sem reconstruir os apps
As mesmas capacidades em todo lugar	Chat, IDE, terminal e seus próprios agentes veem o mesmo catálogo

Se uma conexão morre quando o cliente é desinstalado, ela nunca foi sua.

Como um link faz isso

A unidade é um link de Connector, uma URL no formato https://edge.vinkius.com/vk_YOUR_TOKEN/mcp. Ele carrega a sua identidade para a camada. Você cola no ChatGPT, Claude, Gemini, Copilot, Perplexity, Grok, DeepSeek, Cursor, VS Code, Windsurf, JetBrains, Claude Code, Cline, Lovable, Antigravity, OpenClaw/ClawX, Goose, Claude Desktop ou qualquer cliente compatível com MCP. Para agentes que você constrói, as mesmas capacidades chegam pelo AI Connect SDK, com adaptadores para Vercel AI SDK, OpenAI Agents, Anthropic, Google ADK, LangChain, CrewAI, Semantic Kernel e AutoGen.

Um link, uma identidade, todos os clientes.

O catálogo é just-in-time. O modelo não precisa decorar 9.268 nomes de Connectors. Ele busca pela tarefa, inspeciona as capacidades, conecta e executa. Hoje o catálogo carrega 9.268 Connectors gerenciados e 63.133 capacidades, e o número se move conforme o catálogo sincroniza.

As credenciais dos apps não estão no cliente. Ficam criptografadas em repouso e nunca voltam para o modelo. A política é avaliada por ação. A trilha de auditoria é escrita na camada, então sobrevive à troca. O link é um bearer token: trate como uma chave, mantenha fora de repositórios e revogue no console se vazar. Um token novo é emitido em segundos, e o antigo para de funcionar.

O mesmo link funciona numa IDE ou num cliente desktop. O Claude Desktop o lê do arquivo de configuração:

{
  "mcpServers": {
    "vinkius-ai-connections": {
      "url": "https://edge.vinkius.com/vk_YOUR_TOKEN/mcp"
    }
  }
}

O cliente muda. A configuração muda. O link não.

Uma migração para rodar nesta semana

Faça o inventário das conexões. Liste os apps, o dono de cada conta, os escopos em uso e a última vez que cada um foi chamado. Não comece pelos apps fáceis. Comece pelos que doeriam se estivessem conectados à conta errada.

Conecte uma vez na camada. Autorize cada app uma vez, num lugar só. O trabalho é por app, não por app por cliente. É toda a diferença entre uma matriz e uma lista.

Cole o link num segundo cliente e rode três tarefas reais. Uma leitura, uma escrita e uma que deveria ser bloqueada. O terceiro teste é o importante. Portabilidade sem um "não" é só conveniência.

Leve a política para a camada. Aprovação por ação para operações destrutivas, padrões de prevenção de perda de dados para PII e campos financeiros, um teto de gasto e um interruptor que para todos os agentes. A política vale para todos os clientes ao mesmo tempo porque não mora em nenhum deles.

Aposente os tokens antigos por cliente. A migração não termina quando o cliente novo funciona. Termina quando o caminho antigo é fechado. Revogue os tokens que foram colados nas configurações dos clientes e confira se nada ainda depende deles.

Documente o dono e a rotação. Um bearer token sem dono é um incidente esperando uma data. Coloque o link sob a mesma disciplina de qualquer outro segredo de produção.

A objeção do lock-in

Toda conversa de arquitetura chega nesta pergunta: você não está só trocando um lock-in por outro?

É uma pergunta justa, e a resposta é uma distinção. Lock-in por refém significa que sair custa a sua capacidade de trabalhar. Lock-in por valor significa que sair custa um produto melhor, mas você ainda consegue trabalhar. O primeiro é armadilha. O segundo é escolha.

Uma camada de conectividade deve tornar a saída barata de propósito. O protocolo é aberto. O link é seu. O token pode ser revogado e reemitido. As conexões não ficam guardadas num cliente que pode descontinuá-las. Se a camada desaparecesse amanhã, você perderia conveniência, não os seus apps ou as suas contas. É essa a régua com que quero ser medido.

Portabilidade não é um recurso que se adiciona no fim. É a razão de a camada existir.

Segurança é o pré-requisito

Um link que alcança todos os apps é uma chave mestra, e uma chave mestra sem controle é pior do que dez tokens espalhados. Portabilidade e governança são o mesmo desenho: as duas exigem que a conexão more num caminho que você controla.

Os controles não são extras opcionais. São o que torna o link seguro de carregar:

• Autorização por ação, avaliada antes de a chamada sair, em vez de um escopo amplo de token.
• Isolamento de credencial, com segredos criptografados em repouso, autenticados por assinatura e nunca colocados no caminho do modelo.
• Padrões de prevenção de perda de dados casados em memória antes de a resposta chegar ao modelo.
• Uma trilha de auditoria à prova de adulteração, em que cada registro é encadeado ao anterior e assinado.
• Tetos de gasto e um circuit breaker que para um loop antes da fatura.
• Um interruptor de emergência que desativa todos os Connectors, revoga todos os tokens e encerra todas as sessões.

Como os controles moram na camada, valem para todos os clientes ao mesmo tempo. É o segundo benefício da portabilidade: você corrige uma política uma vez, e ela vale no ChatGPT, no Claude, no Cursor e no agente que você vai colocar no ar mês que vem.

O argumento mais longo para cada controle está em O Plano de Controle da Era dos Agentes e em Governança de IA.

Perguntas frequentes

Trocar de cliente perde meu histórico de chat? O histórico de chat pertence ao cliente e fica lá. O que te acompanha é a conexão: os apps, as credenciais, as permissões e o registro de execução. São ativos diferentes, e só um deles deveria estar amarrado ao assistente.

Todos os clientes de IA suportam isso? Qualquer cliente compatível com MCP pode colar o link. Mais de 20 clientes são cobertos hoje, incluindo os principais apps de chat, IDEs e agentes de código. Para clientes sem MCP, ou para os seus próprios agentes, o AI Connect SDK expõe as mesmas capacidades por adaptadores de framework.

Um link só é seguro? É um bearer token, então é tão seguro quanto o manuseio dele. Mantenha fora do controle de versão, preso a uma identidade, revogue se vazar e rotacione em um cronograma. A camada aplica política por ação mesmo quando o link é válido, então um link vazado não significa automaticamente mão livre.

Dois clientes podem usar o mesmo link ao mesmo tempo? Sim. Cada chamada é atribuída à mesma identidade e registrada na mesma trilha. Se você precisa de identidades separadas, emita links separados.

E os meus próprios agentes? O mesmo catálogo está disponível pelo SDK, com conectores e credenciais por usuário. O runtime do modelo muda; a conexão não.

Isso é só para MCP? MCP é a fronteira que padronizamos porque é o plugue mais largo. A camada em si é agnóstica de protocolo, e os adaptadores do SDK cobrem frameworks que não falam MCP diretamente.

O assistente é uma aba

O assistente é uma aba. O modelo é um número de versão. A conexão é o trabalho.

Modelos vão continuar mudando. Clientes vão continuar lançando telas novas de configuração. Os apps em que o seu time roda vão permanecer mais ou menos os mesmos, e a relação entre as suas pessoas e esses apps não deveria ser reconstruída toda vez que a interface for.

Configure uma vez. Cole o mesmo link na próxima IA que você usar. Troque de IA. Mantenha as conexões.