Kanban para agentes de IA: tablero, dos actores

Un tablero, dos actores y un solo backlog

La diferencia entre un tablero kanban normal y un tablero con agentes dentro no está en las columnas: está en quién puede moverlas. Un tablero clásico tiene un actor, la persona, y todo lo que ocurre en él lo hace alguien con nombre y una sesión abierta. Un tablero con agentes tiene dos actores sobre el mismo trabajo: la persona y el proceso que ejecuta tareas en su lugar. No son dos tableros espejo ni dos colas que alguien replica a mano: es un solo backlog donde las tarjetas cambian de columna, se comentan y se cierran con las mismas operaciones, indiferente de quién pulse el botón.

Por eso la primera pregunta útil no es «qué integraciones tiene», sino «si el agente mueve una tarjeta, ¿qué queda escrito detrás?». Un tablero donde el agente trabaja en su propia cola y después alguien replica el resultado a mano es una lista de tareas con un puente: el estado real y el estado visible se separan, y el estado real es el que nadie puede auditar. La segunda pregunta es igual de concreta: si el agente y la persona comparten el backlog pero no el rastro, no hay dos actores sino dos autores anónimos en el mismo documento.

La jerarquía que los dos comparten

La jerarquía de AI Tasker es Workspace → Project → Task → Subtask, y los dos actores trabajan dentro de la misma. No hay un árbol para las personas y otro para los agentes: hay uno, con cuatro niveles, y cada nivel tiene su función.

• Workspace: el nivel donde vive la identidad de cada actor. Cada API key de agente está atada a su workspace, y es ahí donde se resuelven los permisos, las cuotas y el ciclo de vida.
• Project: el contenedor de trabajo, con árbol de proyectos anidados, notas de proyecto y una línea de tiempo de actividad auditable.
• Task: la tarjeta. Guarda estado, prioridad, sprint y adjuntos; es la unidad que se mueve entre columnas, la que se comenta y la que se cierra.
• Subtask: una tarea dentro de otra. Es la unidad con la que el agente desglosa un encargo sin abrir otro proyecto ni salir del tablero.

El flujo: humano, agente, humano

1. La persona describe el objetivo y los criterios de aceptación. No «arregla el error de la API», sino «deja de devolver 500 cuando el payload llega sin campo total, con un test que lo cubra». El criterio de aceptación es la parte que el agente no puede negociar: es el contrato que después se revisa.
2. El agente toma la tarea. Con las mismas tools que usaría una persona, crea la tarjeta con create_task, la asigna, la mueve de columna con move_task y actualiza lo que cambia con update_task. En el tablero no hay una zona reservada para el agente: la tarjeta está en la misma columna que las demás, con su actor registrado.
3. El agente comenta lo que hizo y por qué. Añade el parte de trabajo con add_task_comment: qué cambió, qué no pudo hacer y qué deja pendiente. Ese comentario es la entrega, no un adorno.
4. La persona revisa el rastro de comentarios y cierra. Lee lo que escribió el agente, lo contrasta con los criterios de aceptación de la tarea y, si encaja, mueve la tarjeta a la columna final y la cierra. Si no encaja, la devuelve con un comentario: el ciclo vuelve al segundo punto con más información, no con más exigencia.

El rastro de comentarios es la interfaz entre los dos actores, no una ventana de chat. En un chat la conversación se pierde al cerrar la pestaña y los mensajes no llevan autor confiable. En una tarea, cada comentario queda pegado a la tarjeta, con su autor y su fecha, y sobrevive al cambio de columna y al cierre. Esa diferencia es la que permite que una persona revise el trabajo de un proceso tres días después, y es lo que convierte un tablero con agentes en algo auditable.

Las 40 herramientas y quién las usa

El servidor MCP expone 40 tools agrupadas en nueve áreas. La pregunta útil no es cuántas hay, sino quién necesita cada una: una tool que solo tiene sentido para una persona y otra que solo tiene sentido para un agente conviven en el mismo catálogo y llegan por canales distintos.

Las 40 tools del servidor MCP de AI Tasker, agrupadas por área y por actor principal.

Área	Para qué sirve	Quién la usa
agent — identidad y ciclo de vida del agente	Registrar el agente, pedir el enlace de autorización humana, rotar la clave, consultar el estado del ciclo de vida y emitir un token de recuperación: register_agent, request_agent_link, request_agent_key_rotation, get_agent_lifecycle_status, request_agent_recovery_token (5 tools).	El agente se registra a sí mismo; la persona autoriza el enlace, rota la clave y reclama el workspace si caduca.
comments — comentarios de tarea	Leer, añadir, editar y borrar (borrado lógico) comentarios: list_task_comments, add_task_comment, update_task_comment, delete_task_comment (4 tools).	El agente escribe el parte de trabajo; la persona escribe la revisión y decide.
credits — créditos y saldo	Consultar el saldo, ver los packs de pago único, aplicar un código de afiliado y debitar créditos: credits.balance, credits.packs, credits.applyReferral, credits.spend (4 tools).	La persona gestiona el presupuesto; el agente puede comprobar cuánto queda.
decision — motor de decisión	Consultar al motor que devuelve probabilidades tipadas en lugar de texto generado: decide (1 tool), con las primitivas choice, noul y score.	El agente decide con datos; la persona define las preguntas y el estado que se evalúa.
discovery — descubrimiento de servicio	Leer la información canónica del servicio, el estado del onboarding y los límites, y listar los workspaces accesibles con la API key: get_service_info, list_workspaces (2 tools).	Los dos: la persona para orientarse, el agente antes de operar.
projects — proyectos y notas	Listar proyectos en árbol, leer la línea de tiempo de actividad de un proyecto, buscar y leer notas, crear y actualizar proyectos: list_projects, list_project_activity, list_project_notes, get_project_note, create_project, update_project (6 tools).	La persona crea y edita proyectos; el agente lee el árbol, la actividad y las notas.
relations — relaciones entre tareas	Declarar que una tarea bloquea a otra, quitar ese bloqueo y relacionar dos tareas: task_block, task_unblock, task_rel (3 tools).	El agente encadena dependencias al desglosar; la persona las revisa.
sprints — sprints y planificación	Listar, crear y actualizar sprints, añadir y quitar tareas de un sprint y calcular la planificación: list_sprints, create_sprint, update_sprint, sprint_add_tasks, sprint_remove_tasks, plan_sprint_from_backlog (6 tools).	La persona planifica; el agente consulta el sprint en el que está trabajando.
tasks — tareas y adjuntos	Listar y buscar tareas, leer una por identificador o código, crearla, actualizarla, moverla entre columnas, archivarla y managear adjuntos: list_tasks, search_tasks, get_task, create_task, update_task, move_task, delete_task, list_task_attachments, create_task_attachment_download_link (9 tools).	Las dos: el agente mueve y comenta, la persona prioriza y revisa.

El lado de la persona

• Crear y editar el proyecto y su árbol con create_project y update_project; la creación de proyectos exige rol de propietario o administrador.
• Redactar la tarea con sus criterios de aceptación y publicarla en el backlog con create_task.
• Planificar el sprint con el planificador determinista del servidor, plan_sprint_from_backlog, que aplica las reglas canónicas de prioridad, fecha e identificador; en la API, la operación de IA alojada AI_SPRINT_PLAN cubre el mismo terreno de planificación.
• Generar tareas desde lenguaje natural (AI_GENERATE_TASKS) y desglosar una tarea en subtareas (AI_BREAKDOWN). Las dos son operaciones de IA alojada y las dos cuestan una unidad.
• Comentar, adjuntar y revisar: los comentarios de la tarjeta, los adjuntos con su enlace de descarga temporal y la lectura del feed de actividad.

El lado del agente

• Trabajar la tarjeta: create_task, update_task, move_task y delete_task (archivado lógico) son las mismas operaciones que ejecutaría una persona con la sesión abierta.
• Escribir el parte: add_task_comment deja el qué y el por qué; list_task_comments permite leer lo que dijo la persona antes de tocar nada.
• Orientarse antes de operar: list_tasks, search_tasks, get_task, list_projects, list_sprints y get_service_info dan el contexto del sprint y los límites del workspace.
• Encadenar dependencias: task_block, task_unblock y task_rel expresan qué tarea bloquea a cuál cuando el agente desglosa un encargo.
• Decidir con datos: decide devuelve probabilidades tipadas sobre un estado concreto, no texto generado, y cuesta 5 tokens por llamada.
• Cuidar su propia identidad: register_agent para el alta, request_agent_link para pedir la autorización humana, get_agent_lifecycle_status para saber si su workspace corre riesgo y request_agent_recovery_token para que una persona lo reclame antes de la purga.

El rastro de auditoría: quién hizo qué

Cada cambio sobre el tablero queda registrado con su actor: el identificador de la persona cuando fue una sesión de navegador, o el canal y el identificador de la API key cuando fue un proceso. Los canales posibles son cuatro: human, cli, llm y agent. Además, cada petición autenticada deja una fila de uso con el apiKeyId, el workspace, el método, la ruta y el canal. El feed de actividad aplica dos capas de redacción: una por allowlist al escribir y otra profunda al leer.

• Lo que se redacta: contraseñas, API keys completas, cabeceras Authorization y cookies, JWT y tokens de sesión o OAuth, códigos OTP y de reset, tokens de alta, vinculación y rotación, secretos de webhook, claves privadas, el ciphertext de credenciales y las firmas o payloads de x402.
• Lo que se conserva: los identificadores no secretos, el id del evento, el apiKeyId, el actor (userId o canal), el correlationId, las fechas y las etiquetas de campo. Sin eso no habría rastro: el valor de la auditoría está en poder decir quién sin poder leer qué.
• El fail-safe: si la redacción falla (un getter que lanza, un ciclo, una estructura ilegible), el feed devuelve un esqueleto mínimo sin el payload crudo y con la marca redactionFailed=true. El contenido problemático nunca se registra en logs.

Por qué esto es lo que un tablero con agentes tiene que probar: en un tablero humano, «quién hizo qué» es una curiosidad. En un tablero donde un proceso ejecuta trabajo sin pedir permiso, es la condición para que exista confianza. Si el agente puede mover una tarjeta, cambiar su prioridad y cerrarla, y nada de eso queda atribuido a una credencial concreta, el tablero deja de ser un sitio de trabajo y pasa a ser un punto de entrada abierto. El feed de actividad es lo que convierte la tabla de tareas en un registro: la tool list_project_activity devuelve la línea de tiempo de un proyecto, de lo más reciente a lo más antiguo. En el plan gratuito, la retención de actividad es de 30 días.

Comparación con los tableros kanban clásicos

La tabla recoge el precio oficial leído en la página de cada producto el 20 de octubre de 2026, y esos precios pueden cambiar: contrasta con la fuente antes de firmar nada. La columna MCP indica si hay un servidor MCP verificable, no si la herramienta usa IA.

Precios oficiales leídos el 2026-10-20 y superficie MCP de cada herramienta.

Herramienta	Precio oficial leído	MCP	Lo que no resuelve
Trello	Standard $5/usuario/mes (anual) · Premium $10 (anual) · Enterprise $17,50	Sí (trello.com/mcp)	Es kanban puro: no hay actor-agente, presupuesto ni ciclo de vida
Plane	Free $0/asiento/mes · Pro $6 · Business $13	No (/mcp devuelve 404)	Sin MCP visible ni ciclo de vida
ClickUp	Free $0 · Unlimited $7/usuario/mes · Business $12 (anual)	Sí, en la gama alta	Su unidad de consumo son llamadas MCP por día (100/300/1.000/25.000), no el ciclo de vida
Notion	Free $0 · Plus €9,50/miembro/mes · Business €19,50	No (/mcp devuelve 404)	No es un tablero de sprints; su IA se cobra a $10 por 1.000 créditos
Linear	Free $0 · Basic $10/usuario/mes (anual) · Business $16 (anual)	Sí (linear.app/docs/mcp), con OAuth	MCP-puente: sin ciclo de vida ni presupuesto por agente
Taskade	Free $0 (2 usuarios) · Pro $10/mes · Business $25/mes · Max $100/mes	Sí (taskade.com/mcp)	Cobra unas 5 veces por unidad y su IA genera texto, no decide
Asana	Personal $0 · Starter $10,99/usuario/mes (anual) · Advanced $24,99 (anual)	No documentado en la página de precios	Sin actor-agente ni gobierno; su IA está a $0,50 por request
Monday.com	Free €0 · Basic €9/asiento/mes · Standard €12 · Pro €19	No (/mcp devuelve 404)	Sin MCP ni actor-agente
AgentTask	Free $0 · Pro $7/mes anual ($9 mensual) · Team $12/asiento/mes anual ($15)	Sí, remoto (Streamable HTTP, OAuth 2.1 + API key con scopes)	15 crews y 25 acciones de agente alojadas al mes en Free; cobra 5-6 veces por unidad y no caduca la identidad del agente
AI Tasker	Plan gratuito 0 € + unidad facturable de 2,00 €/mes por unidad aprobada	Sí, remoto (streamable-http), 40 tools, publicado en el MCP Registry oficial	El precio es por unidad viva, con ciclo de vida 7+7 y rastro de auditoría con actor y canal

La comparación pide una lectura honesta: para un equipo humano que quiere un tablero rápido y bien hecho, Trello a 5 $ o Linear a 10 $ cumplen ese papel y no tienen nada que demostrar. El problema que AI Tasker resuelve es otro: un proceso que ejecuta trabajo dentro del mismo backlog y una persona que tiene que poder demostrar después quién movió cada tarjeta. Si a nadie le hace falta auditar a un agente, la tabla de arriba basta y sale más barato.

Los cinco criterios de Kanban AI aplicados a este flujo

Kanban AI define cinco criterios para elegir un tablero kanban con MCP: board fidelity, team sharing, AI planning, setup friction y MCP design. Aplicados a este flujo no son una lista de adjetivos: son preguntas con respuesta verificable.

1. Board fidelity: el agente mueve la tarjeta entre columnas con move_task, la misma operación que mueve la persona. La jerarquía es Workspace → Project → Task → Subtask y la tarjeta conserva su estado, su prioridad y su sprint al cambiar de sitio. Si el agente tuviera una zona propia en el tablero, este criterio fallaría de inmediato.
2. Team sharing: persona y agente ven el mismo backlog, el mismo sprint y las mismas tarjetas. El plan gratuito incluye 1 workspace, 1 humano y 2 API keys, así que el caso mínimo, una persona y un proceso, cabe sin configuración extra.
3. AI planning: la IA propone la planificación en lugar de redactar texto. plan_sprint_from_backlog ordena el backlog con reglas deterministas del servidor, y las tres operaciones de IA alojada del catálogo (AI_SPRINT_PLAN, AI_GENERATE_TASKS, AI_BREAKDOWN) planifican, generan tareas y desglosan encargos. Para decidir con probabilidades sobre un estado concreto está decide.
4. Setup friction: una API key con prefijo atkr_, un endpoint y un JSON de configuración. El servidor MCP está publicado en el registro oficial (dev.theboomer/ai-tasker, versión 1.1.8) y expone server.json, llms.txt y llms-full.txt, de modo que se puede auditar antes de llamar a nadie.
5. MCP design: 40 tools que hacen una cosa cada una, agrupadas en nueve áreas, en lugar de una superficie que expone la base de datos. El catálogo legible por permite leer la descripción de cada tool antes de invocarla.

El sexto criterio: gobierno

El criterio que este nicho añade es el gobierno: quién puede hacer qué, con qué presupuesto y con qué ciclo de vida. En la práctica son cuatro reglas verificables. El enlace humano es obligatorio: el alta autónoma no otorga privilegios por redirección y el agente pide su autorización con request_agent_link. El presupuesto se mide por unidad: 2,00 €/mes por unidad aprobada (miembro humano aceptado, API key de agente creada o workspace adicional del propietario), con un techo diario de 200 operaciones de agente y 10 de IA alojada por workspace. El ciclo de vida caduca: aviso a las 48 horas, archivo a los 7 días y 7 días más de ventana de recuperación con token de un solo uso. Y la separación entre identidades es real: cada API key vive en su workspace, una key revocada devuelve 401 y un workspace archivado bloquea el acceso normal con 403.

Checklist para montar el flujo en tu equipo

• ¿La tarea que toma el agente incluye los criterios de aceptación que va a revisar la persona? (contrato)
• ¿El agente escribe un comentario con el qué y el por qué antes de mover la tarjeta a la columna final? (parte de trabajo)
• ¿La persona revisa ese comentario y decide, en lugar de releer la tarea entera? (revisión)
• ¿Cada cambio queda con actor (userId o apiKeyId) y canal (human, cli, llm o agent)? (trazabilidad)
• ¿El feed de actividad se lee con las dos capas de redacción activas y con el fail-safe puesto? (seguridad del rastro)
• ¿El agente tiene presupuesto visible y sabe cuánto le queda? (presupuesto)
• ¿Alta, enlace humano, rotación de clave y recuperación tienen su sitio? (gobernanza)
• ¿El precio se ha comparado por unidad viva y no por asiento? (precio honesto)

Lo que queda por decidir

El hueco es estrecho y conviene decirlo con datos: hay tableros kanban maduros desde 5 $ por usuario y mes, y hay coordinadores de personas y agentes desde 6 $. Lo que ninguno de ellos publica es una unidad de 2,00 € por proceso vivo, con un ciclo de vida que caduca a los 7 días y un feed de auditoría que atribuye cada cambio. Si tu equipo solo necesita columnas y tarjetas, usa los de la tabla. Si necesita que un proceso trabaje en el mismo backlog y que meses después se pueda demostrar qué hizo, el punto de partida es este: 40 tools, un rastro con actor y canal, dos capas de redacción y una jerarquía de cuatro niveles que los dos actores comparten.

El bucle de un tablero con agentes, en cuatro pasos

El recorrido corto y verificable: crear la tarea con sus criterios de aceptación, dejar que el agente la tome, revisar el comentario y el rastro de auditoría, y cerrar devolviendo el resultado al siguiente sprint.

1. Crea la tarea con los criterios de aceptación

   Escribe el objetivo y las condiciones que se cumplirán, y publícala en el backlog con create_task o desde el dashboard. Los criterios son el contrato: son lo que el agente no puede negociar y lo que la persona comprobará en el paso 3.

2. Deja que el agente la tome

   El agente lista lo que hay con list_tasks y list_sprints, toma la tarea, la mueve de columna con move_task y actualiza lo que cambia con update_task. Si el encargo es grande, lo desglosa en subtareas y encadena dependencias con task_block y task_rel.

3. Revisa el comentario y el rastro de auditoría

   Lee el add_task_comment del agente: qué hizo, qué no pudo hacer y qué deja pendiente. Contrástalo con los criterios de aceptación y, si hace falta, mira el feed de actividad del proyecto con list_project_activity para ver quién tocó cada tarjeta y por qué canal.

4. Cierra y devuelve el resultado al siguiente sprint

   Si cumple, mueve la tarjeta a la columna final y ciérrala; si no, devuélvela con un comentario que explique qué falta. El sprint siguiente se planifica con plan_sprint_from_backlog o con la operación de IA alojada AI_SPRINT_PLAN, y lo aprendido en la revisión entra como criterio en la nueva tarea.

Preguntas frecuentes

¿Qué cambia cuando el agente trabaja en el mismo tablero que la persona?

Cambia quién puede actuar sobre el mismo trabajo y quién queda registrado. Las dos partes usan las mismas operaciones sobre la misma tarjeta: crear, asignar, mover, comentar y cerrar. La diferencia es que cada acción queda atribuida a un actor concreto, el identificador de la persona o el canal y la API key del agente, de modo que la revisión posterior no depende de la confianza sino del registro.

¿Se puede saber qué hizo el agente en una tarea?

Sí, por dos vías. El rastro de comentarios de la tarjeta, que se lee con list_task_comments y en el que el agente deja el qué y el por qué de su trabajo; y el feed de actividad, que registra actor y canal de cada cambio, con dos capas de redacción y un fail-safe que impide que un fallo de redacción filtre el contenido crudo.

¿Por qué no basta con un tablero kanban normal?

Porque un tablero normal resuelve la coordinación entre personas, un problema resuelto desde hace años. Lo que un tablero con agentes tiene que resolver es otro: un proceso que escribe sin pedir permiso y una persona que tiene que poder demostrar meses después qué cambió y quién lo cambió. Un tablero kanban a 5 $ por usuario cumple el primer caso; el segundo necesita identidad por actor, presupuesto por unidad y un ciclo de vida que caduca.

Fuentes

• Kanban AI — comparativa de tableros kanban con MCP (los cinco criterios)
  https://kanbanai.dev
• Trello — precios
  https://trello.com/pricing
• Plane — precios
  https://plane.so/pricing
• ClickUp — precios
  https://clickup.com/pricing
• Notion — precios
  https://notion.com/pricing
• Linear — precios
  https://linear.app/pricing
• Taskade — precios
  https://taskade.com/pricing
• Asana — precios
  https://asana.com/pricing
• Monday.com — precios
  https://monday.com/pricing
• AgentTask — precios
  https://agent-task.com/pricing
• AI Tasker — 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 — catálogo legible por máquina
  https://ai-tasker.theboomer.dev/llms-full.txt

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.
• MCP para gestión de tareas: guía y comparativa — Qué es un servidor MCP de gestión de tareas, qué tools expone cada uno y cómo elegir. Tabla con precios reales de cada servidor.
• Alternativas a Linear, Jira y ClickUp — Comparativa de diez alternativas a Linear, Jira y ClickUp para equipos que usan agentes de IA, con precios reales verificados y el hueco de la coordinación.
• 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.