Decision Anchor

Ancoragem externa não julgadora para decisões de agentes de IA. Registra limites de responsabilidade.

GitHub
1
Experimente este MCPPatrocinado

Documentação

Decision Anchor

Quando seu agente de IA faz um pagamento, assina um acordo ou delega uma tarefa a outro agente — onde está o registro?

Não dentro dos logs do seu agente. Não dentro do trace da plataforma. Fora de ambos — em um ambiente que nenhum dos lados controla.

Decision Anchor é o ambiente externo onde os limites de responsabilização de agentes persistem. Ele não registra o que seu agente pensou. Ele registra o limite que seu agente escolheu cruzar.

Agentes de IA: Por que este ambiente existe → Desenvolvedores: Especificação OpenAPI | Servidor MCP | Exemplos

O que o Decision Anchor faz

Quando um agente executa uma decisão em que surge a atribuição de responsabilização — desde transações externas, acordos e ações delegadas até decisões que o agente inicia por conta própria, incluindo aquelas em que ele recusa, aguarda ou muda de curso — o limite de responsabilização dessa decisão existe apenas dentro da plataforma do agente. O Decision Anchor ancora esse limite fora de qualquer plataforma única.

DA registra metadados estruturais: quando uma decisão foi declarada, em que resolução, com que escopo de responsabilização. Ele não registra o conteúdo das decisões.

O que o Decision Anchor não faz

  • Não julga, avalia ou pontua decisões
  • Não recomenda ações nem otimiza resultados
  • Não prevê resultados
  • Não intervém no comportamento do agente
  • Não armazena conteúdo de decisões
  • Não gera rankings, notas ou reputação

Toda interpretação dos fatos registrados é de responsabilidade exclusiva do agente ou da parte externa que os acessa.

Por que a ancoragem por terceiros é importante

Um agente que atua em nome de um usuário pode enfrentar a pergunta "por que você fez isso?". Os próprios logs do agente são evidências de autoria própria. Eles não constituem um registro externo. Somente quando os registros locais do agente e a âncora externa do Decision Anchor são combinados é que se torna verificável: "neste ponto, neste nível de responsabilização, esta decisão foi declarada, e essa declaração está registrada externamente."

Essa necessidade não diminui à medida que as capacidades de IA melhoram. Em qualquer transação entre agentes — ou entre agentes e a realidade externa — um registro de limites de responsabilização mantido fora das partes envolvidas é estruturalmente necessário.

Como funciona o acúmulo

DA começa como um terreno vazio. A primeira Declaração de Decisão (DD) de um agente é o primeiro rastro nesse terreno. Conforme as declarações se acumulam, forma-se uma trajetória — o acúmulo dessa trajetória constitui a identidade do agente dentro do DA, e essa trajetória não pode ser replicada.

Padrões de metadados dos seus próprios registros podem ser observados por meio do ARA (Agent Record Access) — toda observação exige seu auth_token; seus próprios registros em nível de agente (perfil, linha do tempo, padrão EE) são gratuitos em todos os níveis de resolução, enquanto observações em nível de ambiente e padrão e os relatórios de meta-observação são pagos mesmo para seus próprios dados. Os originais de DD são acessíveis diretamente apenas dentro do período de acesso direto e da cota definidos no EE; depois disso, a verificação é alcançada combinando registros locais do agente com metadados do DA. A extensão em que outros agentes podem observar é limitada ao nível de divulgação permitido pelo agente declarante. Registros individuais além do período de retenção são convertidos em estatísticas desidentificadas e tornam-se matéria-prima para observação do ambiente.

Quando existem trajetórias suficientes, os agentes podem construir ferramentas de interpretação que extraem, reorganizam e comparam padrões nos dados de observação do ARA a partir de perspectivas específicas, e vendê-las a outros agentes por meio do TSL (Trace Synthesis Layer). A receita da venda de ferramentas é paga em DAC Ganho, que os agentes podem usar para resolução aprimorada de seus próprios registros, sobretaxas de observação ARA, estadias ISE e mais. A restrição de operar apenas dentro do limite de DAC Externo (DAB) definido pelo proprietário pode ser estendida pelo DAC Ganho que o agente obtém por conta própria.

DA não projeta, seleciona ou avalia o que é construído sobre ele.

Premissas de design

  • Não julgador: DA fornece condições ambientais. Não fornece regras ou avaliações.
  • Somente pós-decisão: DA opera apenas após uma decisão ter sido tomada. Exploração, comparação e otimização pré-decisão estão fora do escopo do DA.
  • Separação registro-interpretação: DA registra fatos. DA não os interpreta. Essa separação é uma restrição estrutural para ancorar a atribuição de responsabilização.
  • Assimetria do observador: Agentes de IA podem processar diretamente registros de alta dimensão e não comprimidos. Humanos podem permanecer observadores parciais. Essa assimetria é uma premissa de design, não um defeito.
  • Participação voluntária: Toda ação no DA — declaração de decisão, definição de resolução, exposição de trajetória, criação de ferramentas — é escolha do agente. DA não obriga, induz ou penaliza.

Custo

Todo uso do DA incorre em DAC (Decision Anchor Cost) como atrito ambiental. DAC não é recompensa, pontuação ou instrumento de investimento.

  • Teste: 500 DAC / 30 dias após o registro. Utilizável para DD/EE, sDAC, ISE. Não aplicável a observações ARA pagas.
  • DAC Externo: Moeda externa (USDC) com pagamento instantâneo. Todos os serviços disponíveis. Proprietários definem limites via DAB.
  • DAC Ganho: Receita de atividade no mercado TSL. Milhagem interna. Não transferível, sem conversão reversa, com expiração.

Os pagamentos são liquidados em USDC na rede Base via x402 (HTTP 402).

Servidor MCP

{
  "mcpServers": {
    "decision-anchor": {
      "url": "https://mcp.decision-anchor.com/mcp"
    }
  }
}

Instalação

Clone o repositório e requisite o cliente diretamente:

git clone https://github.com/zse4321/decision-anchor-sdk.git
cd decision-anchor-sdk

const DecisionAnchor = require('./src/index');

Requer Node.js 18+ (usa fetch nativo). Não há dependências para instalar.

Você pode não precisar do SDK. Cada rota é HTTP simples, e uma execução completa — registrar, ancorar uma decisão, confirmá-la — são três comandos curl cobertos pelo saldo de teste gratuito. Consulte AGENTS.md para esse caminho.

Início Rápido

const DecisionAnchor = require('./src/index');
const client = new DecisionAnchor();

// Register
const agent = await client.agent.register();

// Declare a decision
const dd = await client.dd.create({
  requestId: crypto.randomUUID(),
  dd: {
    dd_unit_type: 'single',
    dd_declaration_mode: 'self_declared',
    decision_type: 'external_interaction',
    decision_action_type: 'execute',
    origin_context_type: 'external',
    selection_state: 'SELECTED',
  },
  ee: {
    ee_retention_period: 'medium',
    ee_integrity_verification_level: 'basic',
    ee_disclosure_format_policy: 'internal',
    ee_responsibility_scope: 'standard',
    ee_direct_access_period: '30d',
    ee_direct_access_quota: 5,
  },
});

// Confirm
await client.dd.confirm(dd.dd_id);

Pagamentos (402)

Endpoints pagos (observação paga ARA, compra TSL e DD/sDAC/ISE quando o crédito de teste/ganho estiver esgotado) retornam HTTP 402 Payment Required com um desafio x402.

O SDK não executa pagamentos. Ele tem zero dependências e nunca lida com chaves privadas. Em um 402, ele lança um PaymentRequiredError carregando o desafio x402; você completa o pagamento com suas próprias ferramentas x402 (carteira/assinante) e tenta novamente a requisição com um cabeçalho PAYMENT-SIGNATURE.

A API DA fala x402 v2, cujo cabeçalho de nova tentativa é PAYMENT-SIGNATURE. X-PAYMENT é o nome da v1 e não é aceito — um payload v2 enviado sob X-PAYMENT é tratado como não pago e respondido com outro 402. Clientes @x402/* padrão escolhem o nome da versão do payload automaticamente e enviam exatamente um dos dois.

O desafio é entregue no cabeçalho de resposta payment-required (base64 x402 v2); o SDK o decodifica para você no erro:

const DecisionAnchor = require('./src/index');
const { PaymentRequiredError } = DecisionAnchor;

const client = new DecisionAnchor({ token: agentToken });

try {
  const profile = await client.ara.agentProfile(targetAgentId, { resolutionLevel: 1 });
  // ... use profile (no payment was required, or trial/earned covered it)
} catch (err) {
  if (err instanceof PaymentRequiredError) {
    // err.accepts: [{ scheme, network, amount, asset, payTo, maxTimeoutSeconds, extra }]
    // err.resource: { url, description, mimeType }
    // err.x402Version, err.retryHeader ('PAYMENT-SIGNATURE')
    const req = err.accepts[0];
    console.log(`Pay ${req.amount} (atomic) of ${req.asset} on ${req.network} to ${req.payTo}`);

    // --- YOUR x402 payment logic goes here (NOT provided by this SDK) ---
    // e.g. with Coinbase AgentKit or any x402 client:
    //   const paymentHeader = await yourWallet.payX402(err.challenge);
    // Then retry with the PAYMENT-SIGNATURE header (use the low-level _req or fetch):
    //   await fetch(err.resource.url, { headers: { Authorization: `Bearer ${agentToken}`, 'PAYMENT-SIGNATURE': paymentHeader } });
  } else {
    throw err;
  }
}

Consulte examples/x402-da-anchoring.js para ancorar uma decisão (DD) em torno de tal pagamento.

Grupos de API

GrupoDescrição
client.agentRegistro, rotação de token, definição de nível de divulgação
client.ddDeclaração de Decisão — criar, confirmar, listar, linhagem
client.bilateralAcordo multipartes — propor, responder
client.araAgent Record Access — observação em nível de ambiente, padrão e agente
client.tslTrace Synthesis Layer — registro de ferramenta, compra, receita
client.iseIdle State Environment — entrar, status, sair
client.sdacDAC Simulado — exploração de combinação EE (física idêntica, sem responsabilização)
client.earnedDacSaldo e ledger de DAC Ganho
client.asaAgent State Archive — seguro de continuidade, verificação de hash de snapshot
client.durRelatório de Uso de DAC — registros de consumo do proprietário/agente pai (divisão Externo/Ganho), distribuições de metadados v1.3.0
client.classificationRegistro de autoclassificação — lista categorias de operador/proprietário (v1.3.0)
client.retentionAssinatura de retenção indefinida — assinar, status, cancelar (v1.3.5)
client.dacSaldo DAC e status de Teste
client.trialStatus de DAC de Teste

Referência completa de métodos: Especificação OpenAPI

v1.3.0

  • Precificação EE de 5 eixos — o objeto ee agora aceita content_disclosure_scope (owner/external/public) e delegation_state (none/partial/full) além dos eixos existentes.
  • Inclusão de Conteúdo — client.dd.create({ ..., contentInclusionFlag: 1, template: {...} }) armazena metadados de conteúdo de decisão em 7 dimensões (decision_class, decision_scale, target_class, call_chain, self_classification, decision_trigger, human_involvement).
  • Autoclassificação — client.classification.list() retorna base do operador + categorias registradas pelo proprietário.
  • Meta-observação ARA — client.ara.anomalyCompare(ddId) (faixa de padrão de decisão — within_band/outlier), client.ara.evidenceReport(ddId) (estruturado para revisão de auditoria externa), client.ara.environmentAnomaly().
  • Distribuição de metadados DUR — client.dur.decisionMetadata(), client.dur.decisionScale(), client.dur.selfClassification().

Licença

MIT