Estado y alcance
TilcAI es una infraestructura para que el agente de una persona u organización consulte, cotice, reserve y compre al agente de una empresa con autoridad limitada, condiciones verificables y pagos sobre Stellar. Se construye por etapas. El flujo de compra completo no está habilitado. Los nombres pueden cambiar.
- Base disponible Un riel de pago x402 con OpenZeppelin Relayer en Stellar Testnet, un evaluador determinista de políticas y contratos compartidos versionados.
- En integración Conector MCP, cotizaciones y órdenes, aprobación por compra, conciliación de pagos y confirmación de entrega.
- Siguientes pasos Smart accounts con permisos limitados, presupuesto compartido entre agentes y tareas programadas.
El primer flujo apunta a un negocio, un servicio, un asistente, un usuario y un activo en stellar:testnet. Esta documentación distingue la base disponible, los componentes en integración y los siguientes pasos.
Que un componente esté disponible no equivale a que el flujo de compra esté habilitado. Nada de esto ha sido auditado y nada opera con fondos reales.
Arquitectura
Una solicitud recorre el camino siguiente. El modelo de lenguaje ayuda con la tarea; la infraestructura decide qué acciones pueden ejecutarse y bajo qué condiciones.
Tres planos permanecen separados, de modo que una solicitud puede avanzar en el primero sin tener permisos en el tercero:
- Comunicación. Asistentes, herramientas MCP y mensajes entre agentes.
- Comercio y control. Identidad del negocio, cotizaciones, órdenes, mandatos y política.
- Financiero. Cuenta, autorización, firma, pago y conciliación.
| Módulo | Responsabilidad | Control esencial |
|---|---|---|
| Servidor MCP | Exponer herramientas a los asistentes | Permisos y contexto del principal |
| Gateway | Coordinar el ciclo de compra | Idempotencia y una máquina de estados |
| Adaptador comercial | Conectar las capacidades del negocio | El negocio es la fuente de verdad |
| Identidad y verificador de oferta | Comprobar quién ofrece y que las condiciones estén íntegras | Claves de una fuente de confianza independiente |
| Política y presupuesto | Evaluar proveedor, servicio, monto y límites | Rechazo por defecto |
| Autorización y firmante | Vincular la acción exacta a un consentimiento o mandato | Secretos fuera del alcance del modelo |
| Adaptador Stellar, facilitador y Relayer | Construir, verificar y presentar el pago x402 | Activo, red e invocación exactos |
| Conciliador y recibos | Establecer el resultado real y conservar evidencia | No repetir un pago incierto |
Los módulos son responsabilidades lógicas, no un servicio por caja. Las órdenes, los mandatos y los estados se guardan en almacenamiento durable: el historial de un chat no es un registro de compras.
Integración empresarial
El negocio conserva la autoridad sobre sus servicios, precios, disponibilidad y condiciones. Un adaptador comercial conecta al flujo común las capacidades que realmente puede respaldar, y su agente consulta los sistemas propios del negocio. No inventa stock, descuentos ni confirmaciones.
- Capacidades explícitas. Cada negocio expone solo las operaciones que admite, por ejemplo consultar disponibilidad, retener un recurso o confirmar una orden. Los permisos las distinguen.
- Contexto desde la autenticación. Negocio, usuario y rol provienen de la sesión autenticada, nunca de un argumento libre propuesto por el modelo.
- Identidad de alcance limitado. Un negocio registra su operador, origen, claves y destino de cobro. Controlar una clave o un dominio no demuestra identidad legal ni calidad comercial.
- Cotizaciones firmadas. Una cotización vincula negocio, servicio, cantidad, precio total, red, activo, destinatario, vencimiento y un hash de las condiciones.
Un comprador acepta una cotización solo cuando:
- la clave de firma la reconoce una fuente independiente (onboarding, un registro aceptado o la configuración confiable del principal), nunca se toma de la propia cotización;
- servicio, red, activo, monto y destinatario coinciden exactamente con los requisitos de pago, y la cotización no ha vencido;
- la política, el presupuesto y la aprobación siguen permitiendo la operación.
Una firma protege las condiciones después de firmadas. No protege frente a una clave comprometida, un origen de phishing o una política mal configurada, y nunca concede autoridad de gasto.
La entrega la aporta el negocio. La orden la confirma y cumple el sistema propio del negocio, y esa evidencia se mantiene separada del recibo de pago. Publicar el perfil de un negocio requiere su aprobación; agregar un perfil o explorar un caso de uso no habilita ventas. Un negocio se presenta como habilitado solo cuando su flujo operativo ha sido verificado.
MCP y asistentes
MCP (Model Context Protocol) es la interfaz de herramientas para asistentes compatibles. TilcAI está diseñado para publicar un servidor MCP con operaciones específicas, autenticado según la especificación de autorización de MCP. Todavía no hay un servidor MCP expuesto. Los nombres siguientes son diseño de interfaz, no un paquete publicado.
| Herramienta | Función | Permiso |
|---|---|---|
list_businesses | Descubrir proveedores incorporados | Consulta |
get_service | Consultar servicios y condiciones | Consulta |
get_availability | Consultar disponibilidad | Consulta |
request_quote | Obtener una cotización identificable | Preparación |
prepare_purchase | Verificar y preparar una orden | Usuario autenticado y política |
request_purchase | Solicitar la ejecución de una orden preparada | Confirmación exacta o mandato |
get_order_status | Consultar el resultado de una orden propia | Propiedad de la orden |
request_cancellation | Pedir una cancelación según las condiciones | Permiso comercial correspondiente |
get_budget_status | Consultar límites y retenciones | Acceso al presupuesto propio |
El modelo trabaja con IDs de cotización y de orden. No existe una herramienta irrestricta para enviar dinero a una dirección cualquiera. Precio, destinatario, cantidad, red y activo viajan como datos versionados; la conversación explica esos datos pero no los redefine.
- Conectar no es gastar. Conexión, acceso a datos y autoridad de compra son cosas distintas. Seleccionar un asistente o permitir una herramienta nunca concede permiso de gasto.
- Una skill es guía, no permiso. Explica cómo consultar, aclarar, preparar y comunicar estados. El servidor aplica las reglas aunque un agente ignore la skill.
- El soporte es por capacidad. El catálogo de clientes distingue lectura, cotización, preparación y ejecución. Soportar MCP no implica pagos autónomos. Cada cliente se prueba con su propia versión y autenticación.
- Estado hoy. Todos los clientes del catálogo están en preparación. Se publica una guía para un cliente solo después de probarlo, y ninguna guía pide una frase semilla, una clave privada ni un token.
Permisos y pagos
Un pago es elegible solo cuando se cumplen a la vez:
- una identidad reconocida y una oferta auténtica y vigente;
- una intención vinculada a una orden y un mandato aplicable;
- presupuesto disponible y retenido;
- aprobación exacta o una delegación verificable.
Una firma válida no basta para autorizar un pago. La reputación puede informar una decisión, pero nunca se salta un límite.
Decisiones y estados son cosas distintas
| Estado | Significa | No significa |
|---|---|---|
Permitido (ALLOW) | La política se cumple para esta intención | Permiso para firmar, un pago o una entrega |
| Aprobado | La persona autorizó las condiciones exactas, o aplica un mandato válido | Que se haya movido algún fondo |
| Enviado | Se presentó un intento de pago al riel | Que se haya liquidado; el resultado aún puede ser incierto |
| Liquidado | El riel confirmó el pago | Que el servicio se haya entregado |
| Entregado | El negocio aportó evidencia de cumplimiento | Evidencia del pago en sí |
El motor de políticas devuelve ALLOW, DENY o REQUIRE_APPROVAL. El prototipo actual devuelve ALLOW o DENY; la aprobación humana forma parte del flujo de autorización. Una orden mantiene estados de comercio, pago y presupuesto por separado, así que una orden pagada aún puede estar pendiente de entrega.
Dos formas de autorizar
- Aprobación por compra (primera ruta). La persona conecta una cuenta compatible y revisa servicio, monto, activo, red, destinatario y condiciones. La wallet firma una autorización compatible con el riel, que en x402 sobre Stellar es una entrada de autorización Soroban. Una firma de inicio de sesión o conectar la wallet no basta. Si cambian la oferta o la invocación, se exige una nueva aprobación.
- Delegación limitada (ruta objetivo). Una smart account Soroban de la persona acepta un firmante restringido dentro de un mandato: red y activo exactos, contratos permitidos, destinatarios, montos por operación y por periodo, proveedores, vigencia y revocación. Se habilita solo después de probar juntas la cuenta, el firmante y el riel. Que una smart account funcione no demuestra por sí solo que un payload de pago sea compatible con ella.
El riel de pago hoy
El riel es un facilitador x402 que se ejecuta como plugin dentro de un OpenZeppelin Relayer, en Stellar Testnet. Expone verify, settle y supported. Comprueba la red, el activo permitido, el destinatario, el monto y la autorización firmada del pagador, simula la transacción, y el Relayer la envía y paga la comisión de red.
- Probado. Se confirmó un pago en Testnet dentro de la cadena y se comprobó de forma independiente. Se rechazaron payloads alterados antes de mover fondos. Repetir un payload ya liquidado no pagó dos veces. La respuesta de liquidación trae solo evidencia de pago, nunca datos de entrega.
- Todavía no. Conexión con cotizaciones, aprobaciones, presupuesto y órdenes; una smart account como pagadora; mainnet; y USDC, porque la prueba en Testnet usó el activo nativo de la red.
El detalle técnico, los payloads y el contrato de errores están en la documentación del riel de pago del repositorio abierto tilcai-core.
Cuando algo falla
- Pago incierto. Un timeout después de enviar no es un fallo. Se mantiene la retención de presupuesto y se concilia el mismo intento antes de firmar de nuevo. Repetir una consulta puede ser seguro; repetir una ejecución financiera exige conocer el estado del intento anterior.
- Pago sin entrega. La orden no se marca como entregada. El problema se resuelve según las condiciones comerciales, y repetir la compra no es una solución automática.
- Revocación. Revocar un mandato bloquea nuevas firmas. No revierte un pago que ya se liquidó.
- Condiciones cambiadas. Un precio, proveedor o servicio distinto detiene la operación hasta una nueva aprobación. El agente no puede subir su propio límite ni aprobar su propia excepción.
Extensiones previstas
Son extensiones previstas, no activas. Se añaden detrás de las mismas operaciones y estados.
- Extensión prevista A2A. Un estándar de comunicación entre agentes, con capacidades descritas mediante Agent Cards. Conectaría la solicitud del comprador con las capacidades del agente de la empresa. No sustituye inventario, mandato ni firma financiera. El primer flujo puede funcionar con MCP y una API comercial.
- Extensión prevista ERC-8004. Un estándar en borrador para registros de identidad, reputación y validación en Ethereum/EVM. No es un contrato nativo de Stellar ni garantiza confianza. TilcAI prevé una identidad operativa nativa en Stellar y, por separado, un adaptador para resolver un registro EVM. Consultar una identidad EVM nunca mueve fondos entre redes ni construye un bridge.
- Siguientes pasos Smart accounts, presupuesto compartido y tareas programadas. Consulta el estado de construcción en el resumen.
Modelo de seguridad y límites conocidos
- El modelo propone; las reglas deciden. La salida del modelo nunca se acepta para precio, destinatario ni aprobación. Una condición que no se puede verificar bloquea la operación o pide revisión humana.
- El firmante es una frontera separada. Las claves quedan fuera del alcance del modelo y de los datos del negocio. Este sitio web no almacena claves privadas, tokens financieros ni mandatos de gasto.
- Dependencia del facilitador. La liquidación depende de un facilitador x402 y de un Relayer en Testnet. Si no están disponibles, los pagos se detienen.
- Solo Testnet. El primer flujo corre en Stellar Testnet. Testnet y mainnet tienen configuración y habilitación separadas.
- Sin auditar. Nada de lo descrito aquí ha sido auditado.
Fuera del alcance por ahora: un marketplace de agentes, trading o DeFi, bridges entre cadenas, negociación libre de precios, compras a cualquier negocio sin adaptador, servicios regulados y autonomía ilimitada de los agentes.
Glosario
- Principal
- La persona u organización que posee los fondos y otorga la autoridad.
- Mandato
- Autoridad delegada a un agente, con alcance, límites, periodo y revocación.
- Cotización
- Condiciones comerciales exactas de un negocio: servicio, precio, activo, red, destinatario y vencimiento.
- Orden
- La operación comercial que vincula al principal, el negocio y la cotización, con estados propios.
- MCP
- Model Context Protocol: la interfaz de herramientas para asistentes compatibles.
- x402
- Un protocolo de pago HTTP: un servidor responde
402 Payment Requiredcon las condiciones de pago y el cliente paga para obtener el recurso. - Facilitador
- El componente que verifica y presenta un pago x402. Aquí, un plugin que corre en un OpenZeppelin Relayer.
- Soroban
- La plataforma de contratos inteligentes de Stellar.
- Conciliación
- Establecer el resultado real de un intento de pago, incluso cuando una llamada falló a mitad de camino.
- Código de motivo
- Una explicación legible por máquina de una decisión.