Estuve probando Holded durante unas semanas y no me gustó nada. No porque esté mal hecho, que no lo está. Es que está construido para otra época: una UI bonita donde tú entras, haces clic, subes la factura a mano y revisas el cuadro de mandos.
El problema es que yo ya casi no entro a las webs. Le pregunto a un agente. Y el agente no puede usar una UI bonita.
Esa frase suena a eslogan, así que voy a bajarla a decisiones técnicas concretas. Si aceptas que el agente es el nuevo usuario, hay cuatro cosas de tu producto que cambian, y ninguna es "añadir un chatbot en la esquina".
1. Tu OpenAPI deja de ser documentación y pasa a ser la interfaz
Cuando el usuario es humano, la API es un extra para integradores. Cuando el usuario es un agente, la API es el producto y la UI es el extra.
Eso tiene una consecuencia incómoda: la spec tiene que ser pública y completa, sin login previo. Un agente no puede descubrir lo que sabes hacer si le pides que se registre antes de leer el índice.
curl -s https://api.aikount.com/openapi.json | jq '.paths | keys | length'
# 345
345 endpoints, OpenAPI 3.1, accesible sin autenticar. Si tu spec vive detrás de un portal de desarrolladores con registro, para un agente no existe.
2. Los endpoints tienen que hablar el idioma del dominio, no el de tu base de datos
Este es el error que más he visto, y lo cometí yo primero.
Un CRUD honesto expone PATCH /documents/{id} y deja que el cliente descubra qué combinación de campos significa "concilia esto". Un humano con la documentación delante lo resuelve. Un agente se inventa la combinación, y en contabilidad inventarse una combinación significa un asiento mal hecho.
La alternativa es exponer la intención, no la mutación:
POST /api/v1/reconciliations/auto
POST /api/v1/purchases/autogen-from-movements
GET /api/v1/contacts/{contact_id}/tax-suggestion
Estos tres no son azúcar sintáctico sobre un CRUD. Cada uno encapsula una decisión de negocio que antes vivía en la cabeza del contable, y al exponerla como endpoint propio consigues dos cosas: el agente no tiene que reconstruirla, y tú puedes cambiarla sin romper a nadie.
Regla práctica: si para hacer algo el agente necesita encadenar cuatro llamadas en un orden concreto, ese orden es un endpoint que te falta.
3. Hay acciones que el agente puede hacer, y otras que no debe poder
La parte que nadie cuenta de "dale herramientas a tu agente" es que algunas herramientas no deberían existir.
En contabilidad la línea es bastante nítida: proponer es reversible, presentar no lo es. Un agente puede leer un extracto, casar un cobro con su factura y proponer el apunte. Lo que no puede es cerrar un periodo o mandar algo a la AEAT sin que un humano lo mire.
Eso se modela con estado, no con buenas intenciones en el prompt:
POST /api/v1/journal/{entry_id}/lock
Un asiento bloqueado ya no lo toca el agente. Y el registro Veri*Factu, que va encadenado por hash y no admite "perdón, me equivoqué", vive en su propio recurso con su propio reintento:
GET /api/v1/verifactu/records
POST /api/v1/verifactu/records/{record_id}/retry
Fíjate en retry como endpoint explícito. Cuando el cliente es un agente que reintenta solo, el reintento tiene que ser una operación que tú controlas y registras, no un bucle que el modelo improvisa. Si tu API no define qué significa reintentar, el agente lo definirá por ti, normalmente duplicando.
4. El onboarding del agente es un producto en sí mismo
Tenemos un botón que se llama "Conectar tu agente de IA". Lo que hace es generar una API key con scopes y darte el comando ya montado para pegárselo a Claude, ChatGPT o Gemini. Cero configuración manual, cero copiar la URL base de un PDF.
La autenticación es Bearer, y admite tanto el JWT de sesión como una key larga con prefijo agl_:
Authorization: Bearer agl_...
El prefijo no es decorativo. Cuando una credencial se te escapa en un log o en un repo, un prefijo reconocible es lo que permite detectarla y revocarla automáticamente. Si tus keys son un UUID pelado, no hay nada que buscar.
Lo que aprendí
Construimos Aikount para resolver nuestro propio problema: saber el estado real de mi SL con un mensaje de WhatsApp, en vez de abrir un panel y navegar seis pantallas. Es contabilidad española de verdad, con PGC, Modelo 303, Veri*Factu y conexión PSD2 a los bancos.
Pero lo que me llevo como aprendizaje técnico va más allá del nicho:
- Publica la spec sin login o para un agente no existes.
- Expón intenciones, no mutaciones. Si hace falta encadenar llamadas en un orden fijo, falta un endpoint.
- Separa por diseño lo reversible de lo irreversible, y hazlo con estado, no con prompts.
- Trata el alta del agente como onboarding de usuario, porque eso es exactamente lo que es.
Si quieres trastear, la spec está abierta en api.aikount.com/openapi.json y el plan gratuito llega hasta 24.000 € facturados al año, sin tarjeta y sin módulos de pago por separado.
Me interesa mucho el contraargumento, así que si crees que exponer intenciones en vez de CRUD es acoplar demasiado la API al dominio, dímelo en comentarios. Es la crítica que más me ronda.
Top comments (0)