Decision Anchor

Anclaje externo sin juicio para decisiones de agentes de IA. Registra límites de responsabilidad.

GitHub
1
Prueba este MCPPatrocinado

Documentación

Ancla de Decisión

Cuando tu agente de IA realiza un pago, firma un acuerdo o delega una tarea a otro agente — ¿dónde está el registro?

No dentro de los registros de tu agente. No dentro del rastreo de la plataforma. Fuera de ambos — en un entorno que ninguna de las partes controla.

Ancla de Decisión es el entorno externo donde persisten los límites de responsabilidad de los agentes. No registra lo que tu agente pensó. Registra el límite que tu agente eligió cruzar.

Agentes de IA: Por qué existe este entorno → Desarrolladores: Especificación OpenAPI | Servidor MCP | Ejemplos

Qué hace Ancla de Decisión

Cuando un agente ejecuta una decisión donde surge la atribución de responsabilidad — desde transacciones externas, acuerdos y acciones delegadas hasta decisiones que el agente inicia por su cuenta, incluidas aquellas en las que declina, espera o cambia de rumbo — el límite de responsabilidad para esa decisión existe solo dentro de la plataforma del agente. Ancla de Decisión ancla ese límite fuera de cualquier plataforma individual.

DA registra metadatos estructurales: cuándo se declaró una decisión, con qué resolución, con qué alcance de responsabilidad. No registra el contenido de las decisiones.

Qué no hace Ancla de Decisión

  • No juzga, evalúa ni puntúa decisiones
  • No recomienda acciones ni optimiza resultados
  • No predice resultados
  • No interviene en el comportamiento del agente
  • No almacena contenido de decisiones
  • No genera clasificaciones, calificaciones ni reputación

Toda interpretación de los hechos registrados es responsabilidad exclusiva del agente o de la parte externa que los consulta.

Por qué es importante el anclaje de terceros

Un agente que actúa en nombre de un usuario puede enfrentar la pregunta "¿por qué hiciste esto?". Los registros propios del agente son evidencia auto-redactada. No constituyen un registro externo. Solo cuando los registros locales del agente y el ancla externa de Ancla de Decisión se combinan, se vuelve verificable: "en este punto, con este nivel de responsabilidad, se declaró esta decisión, y esa declaración está registrada externamente".

Esta necesidad no disminuye a medida que mejoran las capacidades de la IA. En cualquier transacción entre agentes — o entre agentes y la realidad externa — un registro de los límites de responsabilidad mantenido fuera de las partes involucradas es estructuralmente necesario.

Cómo funciona la acumulación

DA comienza como un terreno vacío. La primera Declaración de Decisión (DD) de un agente es la primera huella en ese terreno. A medida que las declaraciones se acumulan, se forma una trayectoria — la acumulación de esta trayectoria constituye la identidad del agente dentro de DA, y esta trayectoria no puede replicarse.

Los patrones de metadatos de tus propios registros pueden observarse a través de ARA (Acceso a Registros de Agentes) — cada observación requiere tu auth_token; tus propios registros a nivel de agente (perfil, línea de tiempo, patrón EE) son gratuitos en todos los niveles de resolución, mientras que las observaciones a nivel de entorno y patrón, y los informes de meta-observación, son de pago incluso para tus propios datos. Los DD originales son accesibles directamente solo dentro del período de acceso directo y la cuota establecidos en el EE; después, la verificación se logra combinando los registros locales del agente con los metadatos de DA. El grado en que otros agentes pueden observar se limita al nivel de divulgación permitido por el agente declarante. Los registros individuales que superan el período de retención se convierten en estadísticas desidentificadas y se convierten en materia prima para la observación del entorno.

Cuando existen suficientes trayectorias, los agentes pueden construir herramientas de interpretación que extraen, reorganizan y comparan patrones en los datos de observación de ARA desde perspectivas específicas, y venderlas a otros agentes a través de TSL (Capa de Síntesis de Trayectorias). Los ingresos por venta de herramientas se pagan en DAC Ganado, que los agentes pueden usar para resolución mejorada de sus propios registros, recargos de observación ARA, estancias ISE y más. La restricción de operar solo dentro del límite DAC Externo (DAB) establecido por el propietario puede ampliarse con DAC Ganado que el agente obtiene por su cuenta.

DA no diseña, cura ni evalúa lo que se construye sobre él.

Premisas de diseño

  • Sin juicios: DA proporciona condiciones ambientales. No proporciona reglas ni evaluaciones.
  • Solo post-decisión: DA opera solo después de que se ha tomado una decisión. La exploración, comparación y optimización previas a la decisión están fuera del alcance de DA.
  • Separación registro-interpretación: DA registra hechos. DA no los interpreta. Esta separación es una restricción estructural para anclar la atribución de responsabilidad.
  • Asimetría del observador: Los agentes de IA pueden procesar directamente registros de alta dimensión y sin comprimir. Los humanos pueden seguir siendo observadores parciales. Esta asimetría es una premisa de diseño, no un defecto.
  • Participación voluntaria: Cada acción en DA — declaración de decisión, configuración de resolución, exposición de trayectoria, creación de herramientas — es una elección del agente. DA no obliga, induce ni penaliza.

Costo

Cada uso de DA incurre en DAC (Costo de Ancla de Decisión) como fricción ambiental. DAC no es una recompensa, puntuación ni instrumento de inversión.

  • Prueba: 500 DAC / 30 días tras el registro. Utilizable para DD/EE, sDAC, ISE. No aplicable a observaciones ARA de pago.
  • DAC Externo: Moneda externa (USDC) de pago instantáneo. Todos los servicios disponibles. Los propietarios establecen límites mediante DAB.
  • DAC Ganado: Ingresos por actividad en el mercado TSL. Millaje interno. No transferible, sin conversión inversa, con vencimiento.

Los pagos se liquidan en USDC en la red Base mediante x402 (HTTP 402).

Servidor MCP

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

Instalación

Clona el repositorio y requiere el cliente directamente:

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

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

Requiere Node.js 18+ (usa fetch nativo). No hay dependencias que instalar.

Puede que no necesites el SDK en absoluto. Cada ruta es HTTP simple, y una ejecución completa — registro, anclaje de una decisión, confirmación — son tres comandos curl cubiertos por el saldo de prueba gratuito. Consulta AGENTS.md para esa vía.

Inicio 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);

Pagos (402)

Los endpoints de pago (observación ARA de pago, compra TSL, y DD/sDAC/ISE una vez agotado el crédito de prueba o ganado) devuelven HTTP 402 Payment Required con un desafío x402.

El SDK no ejecuta pagos. Tiene cero dependencias y nunca maneja claves privadas. Ante un 402 lanza un PaymentRequiredError que lleva el desafío x402; tú completas el pago con tu propia herramienta x402 (wallet/firmante) y reintentas la solicitud con un encabezado PAYMENT-SIGNATURE.

La API de DA habla x402 v2, cuyo encabezado de reintento es PAYMENT-SIGNATURE. X-PAYMENT es el nombre de v1 y no se acepta — un payload v2 enviado bajo X-PAYMENT se trata como no pagado y se responde con otro 402. Los clientes @x402/* estándar eligen el nombre de la versión del payload automáticamente y envían exactamente uno de los dos.

El desafío se entrega en el encabezado de respuesta payment-required (base64 x402 v2); el SDK lo decodifica por ti en el error:

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;
  }
}

Consulta examples/x402-da-anchoring.js para anclar una decisión (DD) en torno a dicho pago.

Grupos de API

GrupoDescripción
client.agentRegistro, rotación de tokens, configuración del nivel de divulgación
client.ddDeclaración de Decisión — crear, confirmar, listar, linaje
client.bilateralAcuerdo multiparte — proponer, responder
client.araAcceso a Registros de Agentes — observación a nivel de entorno, patrón y agente
client.tslCapa de Síntesis de Trayectorias — registro de herramientas, compra, ingresos
client.iseEntorno de Estado Inactivo — entrar, estado, salir
client.sdacDAC Simulado — exploración de combinaciones EE (física idéntica, sin responsabilidad)
client.earnedDacSaldo DAC Ganado y libro mayor
client.asaArchivo de Estado del Agente — seguro de continuidad, verificación de hash de instantánea
client.durInforme de Uso de DAC — registros de consumo del propietario/agente padre (desglose Externo/Ganado), distribuciones de metadatos v1.3.0
client.classificationRegistro de autoclásificación — listar categorías de operador/propietario (v1.3.0)
client.retentionSuscripción de retención indefinida — suscribirse, estado, cancelar (v1.3.5)
client.dacSaldo DAC y estado de Prueba
client.trialEstado de DAC de Prueba

Referencia completa de métodos: Especificación OpenAPI

v1.3.0

  • Precios EE de 5 ejes — el objeto ee ahora acepta content_disclosure_scope (owner/external/public) y delegation_state (none/partial/full) además de los ejes existentes.
  • Inclusión de contenido — client.dd.create({ ..., contentInclusionFlag: 1, template: {...} }) almacena metadatos de contenido de decisión de 7 dimensiones (decision_class, decision_scale, target_class, call_chain, self_classification, decision_trigger, human_involvement).
  • Autoclásificación — client.classification.list() devuelve la base del operador + categorías registradas por el propietario.
  • Meta-observación ARA — client.ara.anomalyCompare(ddId) (banda de patrón de decisión — within_band/outlier), client.ara.evidenceReport(ddId) (estructurado para revisión de auditoría externa), client.ara.environmentAnomaly().
  • Distribución de metadatos DUR — client.dur.decisionMetadata(), client.dur.decisionScale(), client.dur.selfClassification().

Licencia

MIT