Sprint planning con IA: probabilidades reales

Dos cosas que se llaman planificar con IA

La primera versión: le pides a un modelo de lenguaje que proponga un plan de sprint y te devuelve texto. La segunda: le das a un motor un estado (un ticket, un backlog, un contexto) y una lista de preguntas tipadas, y te devuelve una respuesta por pregunta con la opción elegida, una confianza y las probabilidades de cada alternativa. Las dos producen algo que parece una priorización. La diferencia está en si después puedes comprobar qué se decidió y con qué margen. En AI Tasker las dos existen y están separadas por contrato: la IA alojada redacta y el motor decide.

La segunda versión no es una idea nueva: es una tool concreta del servidor MCP (una de las 40 que expone) y un endpoint HTTP, POST /api/decide. Su código es público en el repositorio y sus respuestas son objetos con campos, no párrafos. Eso cambia lo que un agente puede hacer con la salida, y es lo que se explica aquí.

Las tres primitivas tipadas

La tool decide acepta hasta 10 preguntas por llamada. Cada pregunta declara un type, un instructions y, cuando hace falta, un criteria. El servidor valida el tipo de cada pregunta antes de ejecutar nada, y no admite más que tres primitivas:

Primitivas aceptadas por el endpoint, con la forma de la respuesta de cada motor.

Primitiva	Qué declaras	Qué devuelve
choice	criteria como objeto: de 2 a 20 opciones, cada una con su descripción	la opción elegida, la confianza y las probabilidades de cada opción
noul	las instrucciones y nada más: es una condición de sí o no	la probabilidad de que la condición se cumpla
score	criteria como array ordenado: de 2 a 20 niveles	el nivel, la confianza, las probabilidades y la leyenda de la escala

• El contexto sobre el que se decide se llama state y es una cadena de texto no vacía o un objeto plano no vacío. Sirve para pasar los datos que el motor necesita, no para escribir un briefing.
• El criterio de choice es un objeto de clave y descripción: el motor elige una clave, y la descripción es lo que le da sentido. En score, el array de niveles va ordenado y ese orden es la escala.
• Si una pregunta no cumple el contrato (por ejemplo, un choice con una sola opción o un score con 21 niveles), el servidor responde 400 INVALID_DECISION_REQUEST con la lista de errores concretos y no se cobra nada.
• El orden importa: la ruta valida primero, cobra después y a continuación llama a los motores. Una petición rechazada no deja deuda.

Por qué sin prosa cambia el trabajo del agente

La diferencia con un modelo generativo no es de estilo. Un modelo generativo devuelve texto y quien lo consume tiene que parsearlo: extraer la opción elegida de una frase, distinguir una lista de una recomendación y asumir que el modelo no se ha inventado una tercera opción que no estaba en la lista. Con un motor de decisión no hay nada que parsear: la respuesta ya viene desglosada por pregunta y con campos con nombre.

El propio producto llama a esto la regla de nexos: el modelo redacta, tu agente decide. El motor de decisión no genera prosa. Si quieres un párrafo que explique la decisión, lo escribes tú a partir de las probabilidades; si quieres el objetivo de sprint en frases o el desglose de una tarea, eso lo hace el modelo que ya trae el agente.

Por eso la tool decide no tiene un tipo generate y por eso su salida no es un plan. Es una decisión con forma de dato: se puede guardar, comparar y auditar. La prosa sigue donde estaba, en el modelo que escribe.

Dos motores y una regla de enrutado

Hay dos motores detrás de la misma interfaz y el servidor elige entre ellos según el tipo de preguntas:

Motores del motor de decisión y su coste de proveedor.

Motor	Qué es	Latencia	Coste de proveedor
laya	ONNX embebido en el proceso del servidor (laya-ts), con los pesos exportados	~33 ms	0
jev	OpenRouter Decisions API (modelo typesafe/jev-1.13)	~250 ms	~0,00002 $ por llamada, medido por el proveedor en usage.cost

• Con engine auto, una escala score de 5 o más niveles va a Jev y el resto va a Laya. El motivo es la calibración: una escala ancha necesita un ranking fino y Laya se reserva para lo corto.
• Si das un valor explícito (laya o jev), la llamada va directa a ese motor y el enrutado automático no se aplica.
• Si Laya no está disponible, la llamada cae a Jev y queda contabilizada como fallback. Si no hay ningún motor disponible, la respuesta es 503 DECISION_ENGINE_UNAVAILABLE y los 5 tokens reservados se devuelven.
• GET /api/decide/stats devuelve la latencia media, los errores, los fallbacks y el coste acumulado por motor, para que sepas en qué motor estás corriendo antes de ajustar nada.

El motor está apagado por defecto

Esto es parte del contrato y conviene decirlo antes que nada: POST /api/decide responde 503 DECISION_ENGINE_DISABLED mientras DECISION_ENGINE_ENABLED no sea exactamente true. El gate es independiente de la autenticación y del resto de la IA del producto, así que un cliente bien autenticado se encuentra con ese 503 si nadie lo ha encendido.

Para encenderlo hacen falta dos cosas: DECISION_ENGINE_ENABLED=true y un motor configurado. O bien LAYA_MODEL_DIR apuntando a una carpeta con los pesos ONNX exportados (el servidor comprueba que exista encoder.onnx, de modo que una carpeta vacía cuenta como motor no disponible), o bien OPENROUTER_API_KEY para que Jev pueda llamar a su API. Con el gate abierto pero sin motores, la respuesta es 503 DECISION_ENGINE_UNAVAILABLE y el cargo se revierte.

Prender el motor de decisión es una decisión de despliegue, no un comportamiento por defecto de la plataforma. Si tu agente llama a decide y recibe 503, el primer trabajo no es reescribir el prompt: es configurar el gate y un motor.

Una llamada real

El cuerpo tiene tres campos: engine (opcional, auto por defecto), state y questions. El ejemplo siguiente es el que usa la regresión del libro de tokens del propio backend:

Petición a POST /api/decide con una pregunta de tipo choice.

POST /api/decide
Authorization: Bearer atkr_...

{
  "engine": "auto",
  "state": { "ticket": "me cobraron doble, quiero reembolso" },
  "questions": {
    "dept": {
      "type": "choice",
      "instructions": "¿qué equipo?",
      "criteria": { "billing": "pagos", "tech": "bugs" }
    }
  }
}

Y la respuesta llega con esta forma:

Forma de la respuesta: engine y un objeto answers con una entrada por pregunta.

{
  "engine": "jev",
  "answers": {
    "dept": { "type": "choice", "choice": "billing", "confidence": 1 }
  }
}

Lo que garantiza el servidor son dos campos: engine, con el motor que respondió, y answers, con una entrada por pregunta. Los campos de cada respuesta los aporta el motor, así que un cliente debe leer los que necesite de cada tipo (la opción y su confianza en choice, la probabilidad en noul, el nivel y su leyenda en score) y no asumir que todas las preguntas traen los mismos. Cuando responde Jev, la respuesta puede traer además un campo usage con el coste y los tokens de entrada que reporta el proveedor.

Dónde entra esto en la planificación de sprint

La IA alojada y el motor de decisión son dos cosas distintas que se cobran distinto y resuelven cosas distintas. El catálogo público de operaciones publica las tres operaciones de IA alojada, con 1 unidad cada una:

Operaciones de IA alojada del catálogo en vivo (GET /api/plans).

Operación	Bucket	Unidades	Qué hace
AI_SPRINT_PLAN	hosted_ai	1	Planificar sprint con IA alojada
AI_GENERATE_TASKS	hosted_ai	1	Generar tareas desde lenguaje natural
AI_BREAKDOWN	hosted_ai	1	Desglosar tarea en subtareas

Y el motor de decisión es una tool aparte, con su propio coste de 5 tokens por llamada. El reparto es lo que importa para el diseño del agente:

• La IA alojada escribe. Planificar el sprint, generar tareas y desglosar una tarea son trabajos de redacción: el resultado es texto que una persona va a leer y un agente va a ejecutar.
• El motor decide. Elegir equipo, comprobar una condición, ordenar una escala: son preguntas cerradas, con respuesta verificable y con probabilidad.
• El plan determinista del producto es un tercer carril. El plan que produce GET /api/sprints/:id/plan no usa LLM ni scoring: ordena por prioridad y fecha, excluye lo que no es elegible siempre con el motivo visible y deja el commit en un clic humano explícito. Ese resultado nunca se persiste solo.

Los límites van aparte de las unidades: el plan gratuito incluye 100 operaciones de IA alojada y 100 de agente al mes por workspace, y los techos diarios son 10 operaciones de IA alojada y 200 peticiones autenticadas con API key entre MCP y HTTP directo.

Por qué una probabilidad es citable

Un plan en prosa no se puede auditar: si el modelo propuso la tarea X antes que la Y, nadie puede reconstruir por qué con las mismas entradas. Una probabilidad sí: la respuesta dice qué se preguntó, qué opciones existían, cuál salió elegida, con qué confianza y con qué probabilidad tenía cada alternativa. Eso se puede guardar, comparar entre ejecuciones, contrastar con lo que la persona decidió después y aprender de la diferencia. Y se puede citar, porque la respuesta es un objeto con campos y no un párrafo que hay que interpretar.

• La decisión y su motivo viven en el mismo sitio: la pregunta enviada es el contrato y la respuesta es su resolución. No hay que reconstruir la intención.
• Es reproducible en el mismo sentido que las reglas del plan de sprint: mismas entradas, mismo orden, mismas exclusiones con el motivo a la vista.
• La confianza permite fijar un umbral en el cliente: si la confianza baja de lo que acepta tu flujo, esa pregunta se escala a una persona en lugar de ejecutarse a ciegas.
• El rastro es comparable con lo que ocurre en el tablero: la misma operación de agente que crea o mueve la tarea deja su actor y su fecha en el historial, y la decisión queda al lado.

Cuándo sí quieres un modelo generativo

Ninguna de las dos piezas sustituye a la otra. El motor de decisión no redacta, no matiza y no conoce el contexto del equipo: si le pides que escriba las notas de la versión, no puede. Y un LLM generativo no te da una probabilidad con la que comparar. Hay casos en los que el modelo generativo es la herramienta correcta:

• Las notas de la versión y el resumen para una persona: ahí el valor está en la redacción y el lector es humano, no un programa que vaya a parsear la respuesta.
• El objetivo del sprint en frases, el mensaje de rechazo de una tarea o el texto de un webhook para un cliente: son prosa dirigida a personas.
• La exploración abierta, cuando todavía no sabes qué preguntar. Un motor responde a las preguntas que le has hecho: si el problema no está formulado, no hay escala que ordenar.

La regla práctica es la del nexo: si el resultado lo va a leer una persona, lo escribe un modelo; si lo va a ejecutar un programa y lo va a revisar alguien más tarde, que sea una decisión tipada con su probabilidad.

Checklist para decidir dónde va cada cosa

• ¿El resultado lo lee una persona o lo consume un programa? (texto o decisión tipada)
• ¿Se puede escribir la pregunta como choice, noul o score con sus criterios? (si no, es un caso de prosa)
• ¿Vas a poder repetir la llamada con el mismo estado y comparar las respuestas? (auditabilidad)
• ¿El gate está encendido en tu despliegue y hay un motor configurado? (si no, 503)
• ¿El coste por llamada cabe en el presupuesto del agente? (5 tokens por llamada)
• ¿La decisión va a llegar al tablero o se queda en un párrafo? (integración real)

Lo que queda por decidir

El hueco de este nicho no es la IA que planifica sprints: hay varias herramientas que lo hacen y cobran por usuario y por mes. La comparativa de esta serie las revisa con sus páginas oficiales. El hueco es más pequeño y más concreto: un plan cuya justificación se puede volver a comprobar. El motor de decisión de AI Tasker cuesta 5 tokens por llamada, devuelve respuestas tipadas y no redacta; el plan de sprint que lo acompaña es determinista y enseña el motivo de cada exclusión. Si la pregunta que te haces es qué debería hacer este agente primero, un LLM te responde rápido. Si la pregunta es por qué lo hizo y puedo auditarlo, necesitas la respuesta con campos.

Cómo decidir con el motor tipado dentro de tu flujo de sprint

Cuatro pasos para pasar de una pregunta en prosa a una respuesta tipada con probabilidad: definir el estado, escribir las preguntas, llamar a decide y comprobar el contrato de la respuesta.

1. Define el estado que se decide

   Elige el campo state: una cadena con el contexto mínimo o un objeto plano. En el ejemplo de la regresión del backend es el ticket que hay que clasificar. El servidor exige que no esté vacío, y en ese campo va el dato, no la instrucción.

2. Escribe las preguntas con las tres primitivas

   choice para elegir entre 2 y 20 opciones descritas, noul para una condición de sí o no y score para una escala ordenada de 2 a 20 niveles. Máximo 10 preguntas por llamada, y cada una con su instructions.

3. Llama a decide y comprueba el contrato

   POST /api/decide o la tool decide del servidor MCP. La respuesta trae engine y answers. Lee los campos que correspondan a cada tipo de pregunta y no asumas los que no vienen; con el motor jev puede llegar además usage con el coste de la llamada.

4. Guarda la decisión y pásala a la acción

   Escribe la pregunta y la respuesta en tu registro y lleva la decisión al tablero con las tools de agente. Si la respuesta es 400, no se ha cobrado nada: corrige el cuerpo y vuelve a intentarlo con el mismo estado.

Preguntas frecuentes

¿Qué diferencia hay entre el motor de decisión y un LLM que escribe un plan?

El motor devuelve respuestas tipadas por pregunta (la opción elegida, la confianza y las probabilidades) y no genera texto; un LLM devuelve prosa que hay que parsear para saber qué decidió. En AI Tasker el reparto es explícito: el modelo redacta y el agente decide. La tool decide expone las primitivas choice, noul y score, y su salida no es un plan.

¿Cuánto cuesta una decisión?

5 tokens por llamada, con cargo en dos fases: se reservan al validar la petición y se confirman cuando la respuesta llega. Un 400 INVALID_DECISION_REQUEST no se cobra y un 503 sin motores disponibles devuelve los tokens reservados. Con el pack de 500 créditos por 5 € salen 100 decisiones, y el motor laya no añade coste de proveedor.

¿Por qué el endpoint /api/decide responde 503?

Porque el motor de decisión está apagado por defecto. DECISION_ENGINE_ENABLED tiene que ser exactamente true y hace falta un motor configurado: LAYA_MODEL_DIR con los pesos ONNX exportados o OPENROUTER_API_KEY para Jev. Con el gate cerrado la respuesta es 503 DECISION_ENGINE_DISABLED; con el gate abierto pero sin motores, 503 DECISION_ENGINE_UNAVAILABLE y el cargo se revierte.

Fuentes

• AI Tasker — documentación de la API (OpenAPI)
  https://api.ai-tasker.theboomer.dev/docs
• AI Tasker — catálogo de planes y operaciones en vivo
  https://api.ai-tasker.theboomer.dev/api/plans
• AI Tasker — manifiesto del servidor MCP
  https://ai-tasker.theboomer.dev/server.json
• AI Tasker — contrato legible por máquina
  https://ai-tasker.theboomer.dev/llms.txt
• OpenRouter — Decisions API (motor jev)
  https://openrouter.ai/api/alpha/decisions
• OpenRouter — modelo typesafe/jev-1.13
  https://openrouter.ai/typesafe/jev-1.13
• Laya (Apache 2.0) — proyecto del motor embebido
  https://github.com/NandhaKishorM/laya

Cifras verificadas contra la API en vivo y las páginas oficiales de cada producto el 21 de octubre de 2026. Los precios de terceros pueden cambiar: contrasta con la página oficial antes de publicar.

Guías relacionadas

• Todas las guías — Cómo elegir gestor de tareas, MCP y ciclo de vida para agentes de IA.
• Gestor de tareas para agentes de IA: guía 2026 — Cómo elegir un gestor de tareas para agentes de IA: MCP, ciclo de vida, créditos y supervisión humana. Comparativa y checklist.
• Ciclo de vida de un agente de IA — Cómo registrar un agente autónomo, vincularlo a un humano y qué pasa si deja de trabajar: aviso a 48 h, archivo a 7 días y purga a los 14.
• Créditos y presupuesto por agente: cómo se cobra — Cómo AI Tasker mide y cobra el uso de agentes: unidad facturable de 2 €, operaciones, packs y recarga automática. Sin sorpresas.
• Precios — Precios reales: plan gratuito y unidad facturable de 2,00 €/mes.
• Integración MCP — https://mcp.ai-tasker.theboomer.dev/mcp
• /llms.txt — Contrato legible por máquina.