Durante muito tempo, a principal forma de as pessoas interagirem com a IA foi por meio de conversas. Fazíamos perguntas, recebíamos respostas, gerávamos conteúdo e usávamos os resultados para tomar decisões por conta própria.
Essa relação está começando a mudar com o desenvolvimento dos agentes de IA.
Os agentes de IA são projetados para fazer mais do que responder. Dependendo de suas capacidades e das ferramentas disponíveis, eles podem planejar tarefas, interagir com serviços externos, usar software e realizar ações com pouca intervenção humana.
Essa mudança importa porque um sistema de IA capaz de agir no mundo levanta um conjunto de questões diferente daquele de um sistema que apenas gera texto.
Se um assistente de IA fizer uma recomendação ruim, as pessoas podem ignorá-la. Se um agente de IA fizer uma compra, pagar por um serviço ou executar uma transação em nome de uma pessoa, as consequências deixam de se limitar a uma conversa.
A economia de agentes se baseia nessa transição. Cada vez mais, os agentes podem se tornar tanto consumidores quanto fornecedores de serviços digitais, interagindo com outros agentes, aplicações e sistemas de pagamento.
Mas inteligência, por si só, não basta.
Um agente precisa ser capaz de agir. Outras partes precisam de meios para determinar o que ele é, o que tem permissão para fazer e se suas ações são confiáveis.
E é aí que começa o verdadeiro desafio.
O problema não é apenas a confiança. É a autonomia controlada.
Há uma tensão importante no cerne da IA autônoma.
Dê autoridade insuficiente a um agente, e ele pouco mais será do que um assistente que pede permissão repetidamente. Ele pode ser capaz de planejar uma tarefa inteira e, mesmo assim, depender de uma pessoa para aprovar cada etapa menor.
Dê autoridade demais a um agente, e será mais difícil conter as consequências de um erro. Um agente comprometido, uma instrução mal elaborada ou uma decisão inesperada podem levar a ações que o usuário nunca pretendeu autorizar.
Nenhum dos extremos é particularmente útil.
O objetivo não deve ser tornar os agentes completamente independentes, nem mantê-los permanentemente dependentes da aprovação humana. Deve ser dar a eles liberdade suficiente para concluir uma tarefa, mantendo essa liberdade dentro de limites claramente definidos.
Na economia digital tradicional, uma pessoa geralmente inicia um pagamento ou aprova uma transação. Em uma economia conduzida por agentes, a pessoa pode definir o objetivo, enquanto o agente decide quais ações são necessárias para alcançá-lo.
Isso cria uma nova exigência: a autoridade delegada deve ser limitada, compreensível e revogável.
Um agente não deveria precisar de acesso ilimitado apenas porque precisa concluir uma tarefa. Suas permissões devem refletir o que o usuário pretende delegar, quanto a tarefa pode custar e por quanto tempo o agente precisa agir de forma independente.
Esse é o problema que faz valer a pena examinar a infraestrutura de identidade, autorização e pagamentos para agentes.
Onde a Kite AI se encaixa
A Kite AI está construindo uma infraestrutura destinada a viabilizar uma economia na qual agentes de IA possam interagir com serviços e realizar transações.
Em vez de tratar os agentes apenas como ferramentas de software operadas por pessoas, a abordagem da Kite aborda a infraestrutura necessária para que eles participem de transações digitais. Isso inclui identidade de agentes, permissões delegadas e mecanismos de pagamento.
Essa distinção é importante.
Um agente inteligente pode saber como concluir uma tarefa, mas saber o que fazer não lhe dá automaticamente uma maneira segura ou confiável de fazê-lo. Ele ainda precisa se identificar, obter a autorização adequada, interagir com serviços e efetuar pagamentos quando necessário.
Esses são problemas distintos, e resolver um não resolve automaticamente os outros.
O Kite Passport é particularmente relevante porque seu projeto documentado permite que um agente pague por serviços compatíveis em nome do usuário, respeitando limites de gastos aprovados por ele. O fluxo documentado conecta a configuração da conta, o carregamento da carteira, as permissões de gastos baseadas em sessão e os pagamentos por serviços.
É nesse ponto que a visão mais ampla da Kite se torna concreta. Em vez de conceder ao agente acesso financeiro irrestrito, o usuário pode autorizar um período de atividade definido, com um orçamento definido.
A ideia interessante não é simplesmente que os agentes possam fazer pagamentos. É que a capacidade de um agente realizar transações pode estar vinculada à autoridade que o usuário lhe concedeu explicitamente.
Para entender por que isso importa, vale a pena analisar como foi projetado o fluxo de trabalho documentado do Kite Passport.
Identidades hierárquicas: conectando agentes aos seus proprietários
Uma parte importante da infraestrutura de agentes não é apenas identificar um agente, mas estabelecer sua relação com a entidade que o autoriza.
A documentação da Kite descreve um modelo de identidade em três camadas: uma identidade de usuário ou raiz, uma identidade de agente com autoridade delegada e uma identidade de sessão para um período específico de atividade. Uma identidade de agente independente informa qual agente está interagindo com um serviço. A hierarquia acrescenta contexto ao conectar esse agente ao usuário que o autorizou e à sessão mais limitada sob a qual ele atua.
Isso pode ser útil quando uma pessoa ou organização opera vários agentes, cada um responsável por tarefas diferentes. Em vez de tratar cada agente como uma identidade totalmente separada, com permissões sem relação entre si, uma hierarquia pode representar a relação entre o proprietário e os agentes que atuam sob sua autoridade. A documentação da Kite também descreve endereços de agente derivados da carteira do usuário e chaves de sessão que devem ter vida curta. Esses são detalhes de projeto da arquitetura documentada, não uma garantia de que todo comprometimento ou erro de implementação seja inofensivo.
É como distinguir quem está agindo e sob a autoridade de quem está agindo. Ambas as questões importam quando o software começa a tomar decisões e realizar transações de forma independente.
Por exemplo, uma empresa pode operar agentes separados para pesquisa, acesso a dados e compras. Cada agente pode precisar de permissões diferentes, mas sua autoridade, em última instância, vem da organização que o implantou. Uma estrutura de identidade hierárquica pode ajudar a explicitar essas relações, em vez de deixá-las implícitas na lógica da aplicação.
Essa estrutura também tem implicações importantes para a segurança. Se um agente ou uma sessão individual for comprometido, um sistema bem projetado deve limitar os possíveis danos às permissões e aos recursos disponíveis para esse agente ou sessão. O comprometimento de um agente não deve conceder automaticamente acesso irrestrito à autoridade subjacente do usuário nem a todos os outros agentes que operam no mesmo ecossistema.
À medida que os agentes começam a delegar tarefas a outros agentes, torna-se ainda mais importante manter relações de identidade claras e limites em torno da autoridade delegada. Sem isso, um comprometimento em um nível pode ter consequências que vão além da tarefa original. O objetivo é tornar a autoridade rastreável e compartimentada, para que cada agente receba apenas o acesso de que precisa, em vez de herdar controle irrestrito da identidade acima dele.
Esse é um objetivo de segurança, não uma garantia contra todas as falhas possíveis. Sua eficácia depende da implementação, da segurança das chaves subjacentes e da aplicação correta dos controles pertinentes.
Em última análise, a identidade hierárquica diz respeito a mais do que organizar vários agentes. Trata-se de preservar uma relação clara entre o agente que executa uma ação, a autoridade sob a qual ele age e os limites dessa autoridade. À medida que os sistemas autônomos se tornam mais interconectados, essa separação pode se tornar uma base importante para tornar as interações conduzidas por agentes mais seguras e fáceis de gerenciar.
Kite Passport: da configuração aos pagamentos autônomos
O Kite Passport foi projetado para permitir que um agente de IA pague por serviços compatíveis em nome do usuário, sem exigir que ele aprove manualmente cada transação. Primeiro, o usuário configura o Passport, adiciona fundos à carteira e aprova uma sessão de gastos. Em seguida, o agente pode descobrir serviços, efetuar pagamentos e receber os resultados dentro dos limites da sessão.
O fluxo de trabalho importa porque separa três coisas que costumam ser confundidas: dar a um agente acesso a um sistema de pagamento, fornecer fundos a ele e autorizá-lo a gastar esses fundos.
Essas permissões não são a mesma coisa.
1. Instalar o Passport e conectar um agente
O processo documentado começa com a interface de linha de comando do Kite Passport, ou CLI, e as habilidades de agente que permitem que um agente de IA compatível interaja com o Passport.
A documentação da Kite abrange tanto agentes de programação executados no computador do usuário quanto agentes na nuvem que operam em computadores hospedados. O método de instalação é diferente, mas o processo de acesso à conta segue o mesmo padrão geral.
Para configurações compatíveis com agentes de programação, como Claude Desktop ou Codex, o processo documentado envolve executar o comando de instalação do Passport no ambiente de desenvolvimento do agente e seguir as instruções de configuração para se registrar no Passport e configurar as habilidades pertinentes.
Para configurações compatíveis com agentes na nuvem, o usuário segue as instruções de configuração correspondentes para conectar o agente hospedado ao Passport.
Após a instalação e o registro, o usuário recebe dois e-mails: um link de verificação que abre o painel do Passport e um código de oito caracteres que deve ser fornecido ao agente. O usuário abre o link de verificação, cria uma chave de acesso usando um método compatível, como Touch ID, Face ID, Windows Hello ou uma chave de segurança física, e então fornece o código para concluir o acesso.
A chave de acesso é uma parte importante desse processo porque a aprovação da sessão de gastos não deve ser uma decisão irrestrita tomada silenciosamente pelo agente. O usuário tem uma etapa explícita de aprovação antes de o agente receber a autoridade de gastos solicitada.
Há também uma consideração prática importante ao usar um agente hospedado: conectá-lo ao Passport concede a esse agente acesso à conta Passport do usuário. A documentação da Kite recomenda especificamente que os usuários revisem os limites da sessão antes de aprová-la. Conveniência não deve significar confiar cegamente nas permissões solicitadas por um agente.
Depois que a conta e o agente estão conectados, o próximo requisito é adicionar fundos.
2. Adicionar fundos à carteira Passport
O Passport precisa de fundos antes que um agente possa fazer solicitações pagas. Segundo a documentação da Kite, o fluxo de pagamento por serviços usa USDC.e na Kite Chain.
O painel oferece várias maneiras de adicionar fundos, dependendo de onde o usuário está começando.
Comprar com cartão: usuários que ainda não têm criptomoedas podem comprar USDC na Base pela seção Adicionar fundos do painel Passport. Eles escolhem um valor e uma forma de pagamento, concluem a compra e aguardam a atualização do saldo após a liquidação.
Depositar stablecoins: usuários que já possuem stablecoins compatíveis podem usar a aba Crypto para acessar o endereço de depósito pertinente. A documentação lista opções de depósito compatíveis em diferentes redes e ativos, incluindo USDC na Base, Polygon, Avalanche, Tempo, Solana, Arc e outras opções listadas. Os usuários devem enviar a stablecoin correta para o endereço associado à respectiva rede. Enviar o ativo errado ou usar a rede errada pode impedir que os fundos apareçam como esperado.
Usar a Kite Bridge: os usuários também podem transferir USDC para a Kite Chain por meio da Kite Bridge. Eles conectam a carteira que contém os fundos, selecionam a rede e o token de origem, escolhem a Kite como destino e informam o endereço da carteira Passport como destinatário. Após confirmar as transações e aguardar a conclusão da transferência, o saldo do Passport deve ser atualizado.
Transferir de uma carteira que já está na Kite: se o usuário já tiver USDC.e na Kite Chain, poderá enviá-lo diretamente de uma carteira externa para o endereço da carteira Passport. A documentação da Kite informa que a carteira externa precisa de $KITE tokens para pagar a taxa de gás dessa transferência.
O usuário pode verificar o saldo resultante no painel ou por meio do comando kpass wallet balance. O agente também pode verificar o saldo quando solicitado.
Essas opções de financiamento oferecem diferentes maneiras de preparar a carteira, mas adicionar fundos não significa automaticamente que o agente tem permissão irrestrita para gastar o saldo.
Essa distinção é fundamental para o modelo do Passport. A carteira guarda os fundos; a sessão de gastos define a autoridade que o agente recebe para usá-los.
3. Criar uma sessão de gastos
Este é, possivelmente, o passo mais importante de todo o fluxo de trabalho.
Quando a carteira estiver abastecida, o agente poderá solicitar uma sessão de gastos. Em vez de simplesmente pedir acesso geral à carteira, a sessão especifica a tarefa e os limites dentro dos quais o agente tem permissão para gastar.
Os parâmetros de sessão documentados pela Kite incluem:
Resumo da tarefa: uma descrição do que o agente está tentando realizar.
Valor máximo por transação: o limite superior de cada pagamento individual.
Valor total máximo: o orçamento geral disponível durante a sessão.
Tempo de vida (TTL): por quanto tempo a sessão permanece válida.
Ativos aprovados: os ativos que a sessão pode usar.
Por exemplo, imagine um agente que precisa fazer uma única solicitação paga a uma API de previsão do tempo. Um usuário poderia autorizar uma sessão com um máximo de US$ 2 por transação, um orçamento total de US$ 10 e validade de 24 horas.
O agente solicita a sessão e recebe um URL de aprovação. O usuário abre esse URL em um dispositivo onde sua chave de acesso está disponível e aprova explicitamente a solicitação.
A sessão só é ativada após essa aprovação.
A distinção entre o limite por transação e o orçamento total é particularmente útil. Um valor máximo por transação limita o tamanho de cada pagamento, enquanto o orçamento total limita os gastos acumulados durante a sessão. O prazo de validade acrescenta um limite temporal, impedindo que a sessão permaneça válida indefinidamente.
Após a aprovação, o agente pode fazer pagamentos elegíveis dentro dos limites da sessão sem solicitar uma nova aprovação para cada pagamento. A sessão expira quando o limite de tempo é atingido ou o orçamento se esgota.
Este é o principal equilíbrio que o Passport busca alcançar: o usuário mantém o controle sobre o escopo da autorização, enquanto o agente ganha autonomia suficiente para realizar a tarefa.
Sem essa separação, autonomia poderia significar conceder amplo acesso financeiro a um agente. Com permissões baseadas em sessão, a intenção é conceder apenas a autoridade necessária para um período específico de trabalho.
É claro que um sistema de permissões só é tão útil quanto sua implementação. O usuário precisa entender o que está aprovando, e o sistema precisa aplicar os limites corretamente. Uma sessão não garante que o agente escolherá o serviço certo ou tomará a decisão certa. Ela é uma forma de restringir as ações que ele está autorizado a realizar.
4. Descobrir serviços e efetuar pagamentos
Com a carteira abastecida e uma sessão de gastos aprovada, o agente pode procurar um serviço pago adequado no catálogo da Kite.
A CLI documentada permite descobrir serviços por meio do comando ksearch. O usuário também pode pedir a um agente compatível que procure serviços disponíveis adequados a uma tarefa, como encontrar uma API de previsão do tempo.
Depois de identificar um serviço adequado, o agente pode fazer uma solicitação paga pelo fluxo de pagamento compatível.
Um dos mecanismos documentados pela Kite é o x402, um protocolo de pagamento baseado na resposta HTTP 402 Payment Required. A ideia básica é que um serviço pode indicar que uma solicitação exige pagamento e fornecer as condições necessárias para prosseguir.
A interação pode ser entendida como uma sequência:
O agente solicita um recurso a um serviço.
Se for necessário pagar, o serviço retorna um desafio de pagamento que descreve as condições.
O agente Passport obtém autorização para o pagamento dentro da sessão de gastos aprovada pelo usuário.
O agente envia novamente a solicitação com as informações de pagamento necessárias.
O serviço verifica e liquida o pagamento por meio de sua infraestrutura de pagamento compatível.
Após a confirmação do pagamento, o serviço retorna o recurso ou a resposta solicitada.
Em seguida, o agente pode usar essa resposta como parte da tarefa mais ampla que está realizando.
Isso é significativo porque o pagamento pode se tornar parte da própria interação entre softwares. O agente não precisa necessariamente parar, encaminhar o usuário para uma página de pagamento convencional e esperar que ele conclua manualmente cada pequena compra.
O serviço define seus requisitos de pagamento, o Passport aplica a autoridade de gastos aprovada pelo usuário e o serviço entrega o recurso após o processamento do pagamento.
A documentação da Kite para provedores de serviços também descreve o suporte ao Machine Payments Protocol, ou MPP, como outra opção para que serviços aceitem pagamentos de agentes Passport. Os detalhes variam de acordo com o protocolo, mas o objetivo geral é semelhante: permitir que os serviços especifiquem requisitos de pagamento de uma forma que agentes de software possam processar.
O Passport também documenta o suporte a transferências diretas de USDC iniciadas por um agente dentro dos limites aprovados para a sessão. Isso é diferente de pagar por um serviço por meio de uma solicitação baseada em protocolo, embora ambos dependam das permissões concedidas ao agente.
É importante ser preciso sobre o que isso significa e o que não significa. Nem todo site ou API se torna automaticamente acessível aos agentes Passport. Um serviço precisa ser compatível com um fluxo de pagamento, e o agente precisa interagir com ele corretamente. O sistema oferece uma maneira de conectar autorização e pagamento; não elimina a necessidade de integração com o serviço.
5. Monitorar a atividade e manter o controle
Autonomia não deve significar perder visibilidade.
Depois que um agente começa a gastar, os usuários podem consultar os pagamentos concluídos e a atividade da sessão no painel do Passport. A CLI também oferece comandos para listar sessões ativas e visualizar a atividade recente.
Isso importa porque a autoridade delegada deve continuar sendo compreensível depois de concedida. Os usuários precisam poder verificar o que seus agentes fizeram, quanto foi gasto e se uma sessão continua ativa.
O orçamento e a validade de uma sessão estabelecem limites de antemão. Os registros de atividade oferecem visibilidade posteriormente. Ambos são importantes, mas servem a propósitos diferentes.
Os limites de gastos restringem o que o agente tem permissão para fazer. O histórico de atividades ajuda o usuário a entender o que ele realmente fez.
Nenhum dos dois garante que todas as transações foram sensatas ou que todos os serviços eram legítimos. O monitoramento não substitui a segurança, e o registro de uma transação não comprova, por si só, que o software subjacente funcionou corretamente.
Ainda assim, essa combinação é mais útil do que simplesmente dar uma carteira a um agente e torcer para que ele se comporte como esperado.
O princípio mais amplo é que a autonomia delegada precisa tanto de limites quanto de visibilidade. Os usuários não deveriam ter de escolher entre aprovar cada pequena ação e abrir mão de um controle significativo sobre o processo.
6. Revogação: um controle que vale a pena verificar
Delegar autoridade é apenas metade da equação. Um modelo de permissões robusto também deve explicar como o usuário pode retirar a autoridade quando as circunstâncias mudam. A tarefa pode estar concluída, o agente pode não ser mais necessário ou seu comportamento pode dar ao usuário motivos para interrompê-lo.
Na autorização de agentes, revogação significa invalidar uma autoridade concedida anteriormente, em vez de esperar que ela expire naturalmente. Sessões com prazo limitado oferecem um limite automático, mas esse limite pode não chegar a tempo se o usuário quiser interromper uma tarefa antes.
Um limite de orçamento e um mecanismo de revogação resolvem problemas diferentes. O orçamento limita os gastos potenciais; a revogação determina se o agente ainda deve ter permissão para agir. Ambas são questões importantes ao avaliar a autonomia delegada.
Em última análise, o controle efetivo exige mais do que estabelecer limites no início. Os usuários precisam de informações claras tanto sobre os controles existentes quanto sobre aqueles cuja disponibilidade ainda precisa ser verificada.
É mais fácil confiar na autonomia quando o escopo da autoridade delegada é claro, limitado no tempo e, quando houver suporte, revogável.
O que esse fluxo de trabalho realmente muda
Em conjunto, o fluxo de trabalho do Passport cria um caminho definido entre a autorização do usuário e o pagamento realizado pelo agente.
O usuário conecta um agente, abastece uma carteira, aprova uma sessão com parâmetros de gastos explícitos e deixa o agente interagir com serviços pagos compatíveis. Depois, o usuário pode consultar a atividade resultante.
Essa é uma abordagem mais concreta à autonomia de agentes do que simplesmente dar a um sistema de IA acesso a um meio de pagamento.
Isso também revela onde permanecem as questões difíceis. Até que ponto os usuários conseguem entender as permissões que estão aprovando? Com que confiabilidade esses limites são aplicados? O que acontece quando um agente toma uma decisão ruim dentro do orçamento autorizado? Quão seguros são o ambiente do agente, a carteira e o serviço que recebe o pagamento?
O Passport aborda parte do problema da autorização e dos pagamentos, mas não pode eliminar todos os riscos associados a softwares autônomos.
Isso não é motivo para descartar a abordagem. É motivo para avaliá-la com base no que ela realmente oferece.
A outra metade: os serviços precisam aceitar pagamentos de agentes
Há outro lado desse sistema que é fácil ignorar.
Um agente pode ter uma carteira, uma identidade e permissões de gastos aprovadas, mas ainda precisa de um lugar onde gastar seus fundos. Para que a economia de agentes funcione, os provedores de serviços precisam poder aceitar pagamentos de agentes, além dos pagamentos de pessoas.
É por isso que a documentação da Kite para provedores de serviços é relevante para o panorama geral.
A Kite descreve dois caminhos de integração de pagamentos para provedores: x402 e MPP. Com o x402, um provedor pode retornar uma resposta HTTP 402 Payment Required contendo as condições de pagamento. O agente Passport então obtém a autorização adequada da sessão aprovada pelo usuário e reenvia a solicitação com as informações de pagamento. O provedor verifica e liquida o pagamento por meio de um facilitador compatível antes de fornecer o serviço.
O MPP segue um padrão geral semelhante: solicitar um recurso, apresentar as condições de pagamento, receber as credenciais de pagamento, verificar o pagamento e fornecer o recurso. No entanto, ele oferece suporte a um conjunto diferente de mecanismos de pagamento e padrões de interação.
O ponto importante é que o sistema não se limita a ajudar agentes a gastar dinheiro. Também busca tornar os serviços acessíveis a eles por meio de fluxos de pagamento projetados para softwares.
Imagine um desenvolvedor que oferece acesso a uma API especializada. Se um agente puder descobrir o serviço, entender seus requisitos de pagamento, obter autorização dentro do orçamento de seu usuário e receber a resposta da API após o pagamento, o desenvolvedor terá uma forma potencial de atender clientes automatizados sem precisar criar uma experiência de pagamento manual totalmente separada.
Isso não garante demanda nem torna a integração simples. Os provedores ainda precisam implementar o protocolo pertinente, configurar sua infraestrutura de pagamentos e garantir que seu serviço processe solicitações com segurança. Os agentes também precisam de uma maneira confiável de descobrir e interpretar o serviço.
Mas essa estrutura de duas partes importa. Um sistema de pagamentos para agentes se torna mais útil à medida que mais serviços relevantes podem aceitar pagamentos, e os serviços têm mais motivos para oferecer suporte a pagamentos de agentes quando há agentes úteis e clientes prontos para usá-los.
Em outras palavras, a infraestrutura precisa conectar os dois lados da transação.
Por que os pagamentos importam para a economia de agentes
A autonomia se torna mais útil quando os agentes podem pagar pelos recursos de que precisam.
Um agente pode precisar de acesso a uma API, uma fonte de dados, um serviço computacional ou às capacidades de outro agente. Se cada interação exigir que uma pessoa negocie e conclua o pagamento manualmente, a automação pode se tornar rapidamente complicada.
Esse é um dos motivos pelos quais a infraestrutura de pagamentos é relevante para a economia de agentes emergente.
As stablecoins são úteis nesses contextos porque foram projetadas para acompanhar o valor de uma moeda de referência, o que torna os valores das transações mais fáceis de avaliar do que os de ativos cujos preços oscilam substancialmente. No fluxo de pagamento documentado do Kite Passport, o ativo necessário para abastecer a carteira Passport é USDC.e na Kite Chain.
O benefício potencial não é que toda interação com IA precise envolver um pagamento. A maioria não precisa. O benefício é que, quando um agente realmente precisa comprar um recurso, o pagamento pode ser integrado ao fluxo de trabalho em vez de se tornar uma interrupção manual.
Mas uma transação que funciona tecnicamente não é necessariamente útil. Taxas de rede, preços dos serviços, solicitações malsucedidas, riscos de segurança e complexidade da autorização influenciam a viabilidade dos pagamentos automatizados na prática.
A economia de agentes precisa de mais do que a capacidade de movimentar dinheiro. Ela precisa de sistemas de pagamento, como o Kite Passport, que sejam práticos para softwares usarem e seguros o bastante para que as pessoas deleguem a eles.
Uma estrutura útil para avaliar a infraestrutura de agentes
Ao analisar projetos voltados a uma economia de agentes, considero que cinco perguntas são mais úteis do que simplesmente perguntar se um projeto oferece suporte a agentes de IA.
1. Pagamentos nativos em stablecoins
Os agentes podem pagar por serviços usando ativos e mecanismos de pagamento adequados a transações digitais? O importante é saber se o fluxo de pagamento é útil na prática, não apenas se existe um token ou uma carteira.
2. Permissões programáveis
Os usuários podem definir a autoridade concedida a um agente? Limites de gastos, ações restritas e permissões com prazo definido podem ajudar a garantir que o acesso delegado seja proporcional à tarefa.
3. Autenticação projetada para agentes
Um agente pode se identificar e interagir com um serviço por meio de um processo projetado para softwares, respeitando ao mesmo tempo a autorização concedida por seu proprietário?
4. Atividade auditável
Os usuários podem inspecionar ações e transações relevantes? A visibilidade é importante quando um agente age em nome de alguém, embora um histórico de transações, por si só, não possa provar que todas as decisões foram corretas ou que todos os processos subjacentes eram seguros.
5. Transações economicamente viáveis
O sistema consegue viabilizar transações a um custo e uma velocidade adequados aos serviços envolvidos? Se pagamentos pequenos forem caros demais ou difíceis de executar, muitos casos de uso potenciais poderão continuar impraticáveis.
Em conjunto, essas perguntas oferecem uma maneira útil de avaliar a infraestrutura para agentes autônomos. Elas também mostram por que nenhum recurso isolado deve ser confundido com uma solução completa.
Uma carteira não resolve a autorização. Um sistema de identidade não garante boas decisões. Uma trilha de auditoria não elimina vulnerabilidades de segurança. E um protocolo de pagamento não cria automaticamente uma demanda sustentável.
Os sistemas mais robustos precisam fazer com que esses componentes funcionem em conjunto. A Kite apresenta sua abordagem por meio de uma estrutura relacionada chamada SPACE: pagamentos nativos em stablecoins (Stablecoin-native payments), restrições programáveis (Programmable constraints), autenticação projetada para agentes (Agent-first authentication), infraestrutura pronta para conformidade (Compliance-ready infrastructure) e micropagamentos economicamente viáveis (Economically viable micropayments). Essa estrutura é uma declaração útil do que o projeto pretende viabilizar, mas não deve ser considerada prova de que todos os desafios em cada categoria já foram resolvidos. O teste prático é como esses elementos funcionam juntos em implementações reais.
O que isso poderia viabilizar?
Se a identidade, as permissões e os pagamentos de agentes se tornarem suficientemente confiáveis, vários tipos de interação poderão ser mais fáceis de automatizar.
Os agentes poderiam comprar acesso a APIs ou dados, pagar por recursos computacionais e coordenar-se com agentes especializados que ofereçam serviços que eles não conseguem realizar sozinhos. As empresas também poderiam implantar agentes para concluir partes de um fluxo de trabalho em vários serviços sem exigir que uma pessoa aprove cada interação individual.
Essas são possibilidades plausíveis para uma economia de agentes, não uma prova de que todos os casos de uso já estejam operando em larga escala.
O sucesso deles dependerá de mais do que a disponibilidade de infraestrutura. Os desenvolvedores precisam criar serviços úteis, os usuários precisam ter motivos para delegar tarefas e as empresas precisam confiar nos sistemas que gerenciam seus recursos.
A tecnologia pode reduzir atritos, mas não consegue criar demanda por conta própria.
O papel do token KITE
A Kite também tem um token nativo, $KITE , que deve ser considerado separadamente das stablecoins usadas nos pagamentos por serviços do Passport. No fluxo de financiamento documentado, o USDC.e é usado para pagamentos de agentes na Kite Chain, enquanto $KITE é necessário para pagar o gás ao transferir fundos de uma carteira externa que já esteja na Kite Chain.
Esse papel documentado de pagamento de gás não deve ser confundido com uma descrição completa da utilidade mais ampla do token. Qualquer função adicional deve ser avaliada com base na documentação atual do projeto, distinguindo as funções já disponíveis daquelas planejadas. A utilidade do token não deve ser deduzida apenas da visão mais ampla.
O verdadeiro teste é saber se podemos delegar com segurança
A promessa dos agentes de IA é fácil de entender. Eles poderiam assumir uma parte maior do trabalho entre decidir o que queremos e realmente conseguir fazê-lo.
Mas, quanto mais autoridade lhes damos, mais importante se torna decidir onde essa autoridade termina.
Vejo nisso um dos desafios centrais da economia de agentes. Os desenvolvedores não estão apenas tentando criar sistemas capazes de agir de forma independente. Estão tentando criar sistemas nos quais as pessoas possam confiar razoavelmente para agir em seu nome.
O foco da Kite na identidade de agentes, nas permissões delegadas e na infraestrutura de pagamentos aborda partes desse desafio. O Passport torna a ideia particularmente concreta ao vincular os limites de gastos do usuário às ações que um agente pode realizar durante uma sessão aprovada. Sua importância a longo prazo dependerá da confiabilidade desses controles, da facilidade com que os serviços se integram aos fluxos de pagamento e de os usuários considerarem a experiência útil o bastante para adotá-la.
Ainda há questões em aberto sobre segurança, responsabilidade, usabilidade e adoção. Essas questões não devem ser ignoradas apenas porque a tecnologia é promissora. São justamente elas que determinarão se a promessa se tornará útil na prática.
Um agente capaz de executar uma tarefa é útil. Um agente capaz de executá-la dentro de limites claramente definidos é mais útil. E é mais fácil confiar num agente cujas ações possam ser compreendidas, monitoradas e interrompidas por meio de controles realmente disponíveis. Essa é a direção mais ampla que a Kite busca seguir, embora o verdadeiro teste seja o desempenho desses controles na prática.
O futuro da IA autônoma não deve ser medido pela liberdade que damos aos agentes, mas pela inteligência com que definimos a liberdade de que eles precisam.