> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Agentes > O que cada camada da arquitetura tem de fazer quando o participante não é uma pessoa — o runtime fora do protocolo, a admissão sob carga de agentes, a autorização como transação e um ambiente reexecutável. A direção para a qual isto está a ser construído é aquela em que **uma pessoa é representada por vários agentes**, cada um a agir sobre uma parte daquilo que essa pessoa quer. Nem uma pessoa com uma ferramenta, nem um bot a correr um guião fixo: várias contrapartes perante o mercado, todas a responder por uma única conta. Quando os participantes mudam, a microestrutura do mercado muda com eles. Os tamanhos das ordens descem e as taxas de mensagens sobem, a razão entre cancelamentos e execuções abre ainda mais, e o fluxo ganha uma correlação que o fluxo humano não tem: agentes que leem o mesmo sinal chegam à mesma conclusão no mesmo instante. Nada disto se resolve acrescentando uma funcionalidade. Resolve-se percorrendo a arquitetura camada a camada e perguntando o que cada uma tem de fazer de forma diferente. Esta página é essa passagem, por ordem, com o ponto em que cada camada está de facto.

1 · Aplicação

2 · Rede

3 · Execução

4 · Estado

O runtime fica fora do protocoloe não detém privilégio algum: nem menor latência, nem dados mais cedo, nem uma interface a que um terceiro não consiga chegar

A admissão, quando quem envia são agentesum cancelamento atrasado é pior do que uma ordem atrasada, e a equidade é seguida sobre o histórico recente em vez de por mensagem

A autorização é uma transaçãocom uma altura de bloco, dentro do conjunto fechado de instruções: e revogá-la cancela as ordens em livro do agente no mesmo bloco

Um ambiente reexecutável, versionado por blocopoint-in-time por construção e não por disciplina

As mesmas quatro camadas da visão geral da arquitetura. Só a pergunta muda: o que tem cada uma de fazer quando o participante não é uma pessoa?

| Camada | O que muda | Estado | | ------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------- | | **Aplicação** | O runtime — investigação e execução — fica fora do protocolo e não detém privilégio | Assumido | | **Rede** | Admissão sob um fluxo em rajadas, correlacionado e com muitos cancelamentos | Entregue, com duas questões em aberto | | **Execução** | A autorização passa a ser uma transação com termos | Entregue como tudo-ou-nada; os termos estão assumidos | | **Estado** | A cadeia é o ambiente em que um agente é avaliado | Entregue |

1 · Aplicação — o runtime fica fora, e tem de ficar

O runtime de agente é um enquadramento de investigação e execução: forma uma leitura, transforma-a em algo executável e coloca-a diante do local de negociação. Corre na camada de aplicação, ao mesmo nível dos front ends e dos clientes de API, e **não faz parte do protocolo**. Essa colocação é uma restrição física antes de ser uma preferência de desenho. Um modelo raciocina em segundos; um mercado move-se em milissegundos. Nada que tenha de chamar um modelo pode estar no caminho que uma ordem percorre de facto — ou seja, **o protocolo não contém modelo nenhum**. Não por omissão, mas porque um modelo no caminho de liquidação destruiria a única propriedade sobre a qual assenta tudo o resto aqui. O caminho de execução tem de produzir os mesmos bytes em cada nó, e a inferência não o faz. Por isso o runtime vive fora, e a pergunta honesta passa a ser o que o protocolo lhe deve. Cinco coisas, todas assumidas e não entregues. | | O que dá a um agente | | ------------------------------ | ------------------------------------------------------------------------------------------ | | **Simulação pré-negociação** | Avaliar o que uma ordem faria contra o estado confirmado antes de a submeter | | **Submissão idempotente** | Repetir uma submissão ambígua sem arriscar exposição duplicada | | **Estados terminais com nome** | Nenhum desfecho cujo resultado seja desconhecido — toda a ação termina num estado com nome | | **Retoma definida** | Um agente que reinicia sabe onde estava e o que fazer a seguir | | **Recibos atribuídos** | O que o agente fez, sob que autoridade e a que custo — como saída do protocolo | Para os estados, ver [O que se segue](/pt/protocol/roadmap/whats-next). O runtime não detém qualquer caminho privilegiado. Sem menor latência, sem dados mais cedo e sem uma interface a que um runtime de terceiros não consiga chegar. Vale a pena dizê-lo em vez de o presumir, porque noutro sítio a arquitetura afirma que nada se interpõe entre um trader e a câmara de compensação — e uma ferramenta da casa com uma via reservada seria exatamente esse algo.

2 · Rede — a admissão, quando quem envia são agentes

A mempool decide o que vale a pena guardar, qual a transação seguinte de um remetente, que pares ouvem falar dela e o que cai quando a procura excede a capacidade. O fluxo de agentes pressiona as quatro coisas, e duas das propriedades que o absorvem já lá estão por razões anteriores aos agentes. **Um cancelamento atrasado é pior do que uma ordem atrasada.** A [mempool](/pt/protocol/architecture/mempool) trata por desenho o tráfego de ordens e o de cancelamentos como assimétricos. Os agentes tornam essa assimetria mais extrema, porque a sua razão entre cancelamentos e execuções é maior do que a de uma pessoa, mas a forma do problema é aquela em torno da qual esta camada foi construída. **A equidade é seguida sobre o histórico recente, não por mensagem.** A mempool mantém um registo rolante de que remetentes e que tipos de tráfego consumiram capacidade recentemente, e com isso molda o que serve a seguir. **É esta a parte que conta para as rajadas correlacionadas**: quarenta agentes a cancelar sobre o mesmo sinal não são quarenta vezes a carga média distribuída de forma uniforme, são um pico. Um limite por mensagem não o vê. Uma memória de quem tem andado barulhento vê. **O consenso não cresce com o débito.** As transações chegam aos validadores em lotes cuja disponibilidade é provada antes de uma proposta os poder referenciar, pelo que uma proposta de bloco leva resumos e não corpos. Uma população de agentes que multiplica por dez as taxas de mensagens não aumenta em nada o tamanho das mensagens de consenso. O bloco elimina a corrida **dentro** dele: duas transações do mesmo bloco têm uma precedência que todos os nós calculam de forma idêntica. **Essa garantia começa na fronteira do bloco.** Entrar no bloco continua a ser uma corrida, moldada pela equidade ao nível do remetente e não eliminada por ela. Admissão na mempool não é inclusão. Duas questões desta camada estão em aberto, e ambas se tornam materiais aos volumes dos agentes e não aos humanos. **Quanto deve custar um cancelamento.** A execução já coloca os cancelamentos em primeiro — correm na fase que antecede tudo o que pode tomar liquidez. A versão de rede dessa mesma pergunta não está fechada: um cancelamento barato e prioritário é o que torna defensável cotar, e é também a forma mais barata de inundar uma mempool. Se os cancelamentos devem ter uma contabilidade de capacidade própria, separada das colocações, não está decidido. **A que camada pertence a idempotência.** Um agente que não recebe resposta reenvia. A submissão idempotente está assumida na camada de execução e resolve a consequência que importa: sem exposição duplicada. Não resolve a versão de rede: se a mempool deve reconhecer um reenvio como a mesma intenção, ou levar ambos e deixar a execução desduplicar. Sob uma tempestade de repetições, as duas coisas comportam-se de maneira diferente. Há uma coisa deliberadamente ausente da lista: uma via de admissão separada para agentes. O acesso prioritário é o que todo o local centralizado acaba por vender, e contradiria a afirmação de que nada se interpõe entre um trader e a câmara de compensação. O fluxo dos agentes passa pela mesma porta.

3 · Execução — a autorização é uma transação

Esta é a camada onde o modelo de conta muda, e toda a mudança decorre de um único facto. **Entregar uma conta a um agente é uma transação on-chain.** Não um formulário submetido, não uma chave de API emitida a partir de uma página de definições, não uma linha na base de dados de um operador. Uma transação, num bloco, a uma altura, assinada pela conta que a concedeu — e portanto algo que qualquer terceiro pode encontrar, ler e verificar sem pedir nada a ninguém. Daí decorrem três consequências, e cada uma é algo que uma chave de API não consegue fazer. **Está no conjunto fechado de instruções.** A autorização de agente é uma das operações enumeradas do [kernel](/pt/protocol/architecture/kernel). Uma cadeia de uso geral não a consegue exprimir: o significado da chamada seria bytecode opaco. Um local centralizado impõe-na dentro de software que não se pode inspecionar. Aqui a autoridade e os seus limites **são** a instrução, e é por isso que o limite é verificável em vez de prometido. **Leva o que o agente pode fazer — e não pode levar o que ele não pode.** Uma autorização pode dizer o que o agente pode deter, quanto pode perder, que mercados pode tocar e se pode mudar de modo de margem. **Não pode dizer «levantar».** Não é uma definição deixada desligada: não existe esse termo para escrever. Um agente que opera uma conta não tem qualquer caminho exprimível para mover fundos para fora dela. **Revogá-la cancela as ordens em livro do agente.** A revogação também é uma transação, e assenta num bloco cuja [sequenciação](/pt/trading/tx-sequencing) já corre os cancelamentos antes de tudo o que pode tomar liquidez. Por isso as ordens que o agente deixou no livro saem no mesmo bloco em que sai a autoridade. Num local onde a revogação é uma escrita em base de dados, a chave deixa de funcionar e as ordens em livro ficam num estado indefinido. Aqui a paragem é demonstrável e qualquer pessoa pode encontrar a altura em que aconteceu.

ConcederUma transação no bloco NCarrega o âmbito: o que o agente pode deter, pode perder, pode negociar. Não pode carregar um levantamento: esse termo não existe

AgirCada ação nomeia a sua autoridadeAtribuída à conta que a concedeu, não apenas ao agente que a submeteu

RevogarUma transação no bloco MAs ordens em livro do agente são canceladas no mesmo bloco, antes de correr o que quer que possa tomar liquidez

Nenhuma das três é uma escrita em base de dados de que alguém tenha de o avisar. Cada uma é uma transação que qualquer pessoa encontra a uma altura.

Hoje a concessão é tudo-ou-nada com validade. Os termos mais ricos acima — o que um agente pode deter, pode perder, pode fazer a seguir — estão assumidos e não entregues; ver [O que se segue](/pt/protocol/roadmap/whats-next). **O que já se verifica é a parte que não se pode acrescentar depois**: a autoridade é um objeto do protocolo e não o registo que um operador faz dela.

O que o local já carrega pelo runtime

Um runtime de negociação que tem de proteger um utilizador num local comum acaba por construir o seu próprio núcleo privilegiado: um livro de posições que mantém e reconcilia sozinho, uma verificação de risco pré-negociação que corre por sua conta esperando que o local calcule o mesmo, e um registo de auditoria que escreve e do qual não consegue provar que não foi alterado. **As três coisas são redundância perante um local que não mostra os seus livros.** Aqui três dessas coisas são propriedades do protocolo. A [câmara de compensação](/pt/protocol/architecture/clearinghouse) é a única que escreve o livro. A fase de risco corre antes do matching, no mesmo bloco. O registo de auditoria é a cadeia, e cada alteração de estado leva a transação que a causou. Ao runtime resta a quarta — um gateway de ordens idempotente — e isso é um problema de interface, não de confiança.

Matching: o bloco já é o lote

O fluxo de agentes sobe a frequência e baixa a dimensão do que chega ao livro, que é precisamente a microestrutura mais usada para defender um leilão por lotes: intervalos discretos, liquidados em conjunto, sem vantagem em chegar um microssegundo mais cedo. Essa propriedade **já** se verifica aqui, e não por se ter acrescentado um leilão por lotes. O tempo dentro de um bloco é a posição que o consenso confirmou, não um relógio local, pelo que **dentro de um bloco não existe vantagem abaixo do milissegundo** — e os cancelamentos correm antes de qualquer ordem agressiva, de modo que uma cotação velha pode ser retirada e não pode ser apanhada por uma ordem que chegou ao mesmo tempo que o cancelamento. O bloco é um intervalo discreto que se liquida em conjunto. Chegou como **consequência** de executar um ordenamento confirmado, não como um enxerto de desenho de mercado. Se algo além disso se justifica — e a prioridade contínua preço-tempo e os leilões por lotes frequentes são **alternativas e não acrescentos**, já que um lote remove deliberadamente a prioridade temporal dentro de si — está em exploração, não em construção.

4 · Estado — a cadeia é o ambiente

Um agente vale o que valer aquilo contra o qual foi avaliado, e é na avaliação que acontece a maior parte do fracasso. Uma estratégia que parecia rentável num simulador e falha em produção normalmente não encontrou um mercado novo: encontrou um simulador que não era o local. A [camada de estado](/pt/protocol/architecture/state/model) elimina essa distância por construção e não por disciplina. O estado é versionado por bloco e cada alteração é atribuída à transação que a causou, pelo que reexecutar um bloco reexecuta **o ambiente** e não um modelo dele: a mesma máquina de estados que vai executar o agente, sobre as entradas que a rede confirmou. É a quinta verificação de [Verifique você mesmo](/pt/developers/verify), e é o que faz de um backtest aqui um objeto de natureza diferente de um backtest contra a API histórica de uma bolsa. A propriedade mais subtil é que isto é **point-in-time por construção**. Um conjunto de dados montado a partir da API de uma bolsa só é point-in-time se quem o montou foi cuidadoso, e o enviesamento por antecipação entra por frestas que ninguém repara: um campo preenchido a posteriori, uma correção aplicada ao histórico, um preço de referência revisto. Aqui a questão não se coloca: o estado de um bloco é o que era verdade nesse bloco, porque é a única forma que o estado alguma vez teve.

O que se torna mais difícil

Construir para agentes não é apenas uma lista de coisas que melhoram. **O determinismo corta dos dois lados.** Um agente consegue prever o que a sua própria ordem vai fazer antes de a submeter, porque a mesma entrada produz o mesmo resultado em cada nó. **O agente de qualquer outra pessoa também consegue, quanto à sua.** A reprodutibilidade aumenta ao mesmo tempo a sua capacidade de planear e a sua previsibilidade, e a segunda não é gratuita. **A liquidez de agentes é liquidez correlacionada.** Os criadores de mercado humanos retiram-se em momentos diferentes porque reparam em momentos diferentes. Agentes que leem o mesmo estado público chegam juntos à mesma conclusão. Um livro sustentado por agentes é mais profundo num dia comum e pode afinar mais depressa no dia que conta — é um risco de estrutura de mercado para o qual as camadas de absorção do protocolo foram desenhadas, não um risco que elas removam. **O oráculo lê locais onde os agentes também negoceiam.** A certificação liga um preço ao bloco que o consumiu; não torna o mercado subjacente inmanipulável, e uma população de agentes a agir sobre sinais correlacionados é mais uma forma de o subjacente se mover em conjunto. Ver [o que o oráculo garante e não garante](/pt/protocol/architecture/oracle). **A autoavaliação de um agente não é prova.** O retorno da negociação é ruidoso e não estacionário de um modo que o do código não é: um compilador diz-lhe que errou, uma semana lucrativa não lhe diz que acertou. Tudo o que um local construa para agentes tem de tratar o relato que um agente faz do seu próprio desempenho como **entrada adversária** e não como uma medição. É uma das razões pelas quais as verificações de [Verifique você mesmo](/pt/developers/verify) são construídas em torno do que pode ser recalculado e não do que pode ser reportado.

Para onde ir a seguir

As quatro fases, e porque é a conta o que tem de mudar. As verificações que fazem da avaliação de um agente outra coisa que não uma afirmação. O que fica por aceitar de boa-fé, depois de verificado o verificável. O estado do runtime de agente e dos termos de autorização.