PolyAccounts · Scenario
Libros para una empresa operada por agentes de IA
Un libro diseñado para que los agentes escriban con seguridad: sandbox de autoservicio, MCP remoto con OAuth, claves de idempotencia, revisiones de fila, recibos durables, lecturas con decimales exactos y credenciales revocables por el administrador.
Respuesta directa
Si un agente va a llevar los libros, el sistema contable debe estar diseñado para un llamador poco confiable: uno que sufre tiempos de espera, reintenta, corre en paralelo y a veces lee mal un registro. PolyAccounts exige en cada escritura una clave de idempotencia con recibo durable, de modo que un reintento devuelve el resultado original en lugar de asentar dos veces. Cada edición y cada baja lógica deben llevar la revisión vigente de la fila en PostgreSQL, así un agente desactualizado no sobrescribe un cambio más reciente.
Las lecturas devuelven cadenas decimales exactas, no punto flotante. La evidencia del libro se pagina con cursores ligados a la empresa y a los filtros. Una escritura interrumpida se reporta como incierta y nunca se reenvía automáticamente. Los administradores ven la actividad reciente del agente y pueden revocar una credencial de inmediato.
Empieza sin una persona en el circuito
Un agente puede crear su propia empresa sandbox sintética con un POST, o llamando a la herramienta create_sandbox del conector stdio cuando no hay credencial configurada. La respuesta incluye una empresa, un catálogo inicial, dos meses de actividad inventada, una credencial de siete días y un inicio de sesión web para que una persona vea los mismos libros.
Para una empresa real, un administrador aprueba la conexión una vez. Los clientes listados en directorios usan el punto de conexión MCP remoto con OAuth 2.1 (PKCE, registro dinámico de clientes, tokens de actualización). Los clientes locales usan el conector stdio con un archivo de token. Ambos caminos emiten la misma credencial limitada a la empresa y pasan por la misma validación contable.
npx -y polyaccounts-mcp # luego, en el cliente: llama a create_sandbox y después a accounting_context
Qué puede y qué no puede hacer un agente
Puede: leer contexto, balanzas y evidencia del libro; descubrir tablas y sus campos editables; crear, actualizar y dar de baja registros; ejecutar 82 flujos de facturación, pagos, fondos de clientes, conciliación, periodos, presupuestos, pronósticos, aprobaciones y operaciones; consultar recibos de operación.
No puede: mover dinero en un banco, enviar correo, invitar usuarios, emitir otras credenciales, ejecutar SQL directo, cruzar a otra empresa, revertir un pago de Stripe sin reembolso verificado del proveedor, ni modificar un periodo cerrado fuera del flujo de periodos. Las credenciales de agente no otorgan administración de la plataforma.
| Control | Comportamiento |
|---|---|
| Idempotencia | Clave obligatoria por escritura; la repetición devuelve el resultado original |
| Concurrencia | Las ediciones exigen la revisión vigente; el conflicto devuelve 409 |
| Incertidumbre | Envío interrumpido reportado; concilia antes de continuar |
| Precisión | Las lecturas base devuelven decimales exactos como cadenas |
| Revocación | Inmediata desde Configuración; también al remover al administrador, cambiar su rol o restablecer su contraseña |
| Lecturas | Sin medición; límites de uso razonable publicados |
Alcance
Los recibos durables dan envío como máximo una vez, no una transacción distribuida. Los importes de los flujos usan la precisión de la aplicación (en general centavos) mientras las lecturas base conservan decimales exactos. El acceso anticipado es para evaluación supervisada con datos sintéticos. Esta versión no certifica libros de clientes reales ni contabilidad fiscal.