Linear con agentes: conectar tu backlog con la IA sin perder el control
Linear se conecta a agentes de IA con su servidor MCP oficial o delegándoles issues, con permisos de lectura o escritura. Cómo usarlo con seguridad.
¿Cómo funciona la conexión?
Linear expone un servidor MCP alojado por la propia empresa. Según su documentación, el endpoint principal es mcp.linear.app/mcp con transporte HTTP en streaming; el endpoint /sse está en desuso. La autenticación es OAuth 2.1: la primera vez, el navegador pide tu aprobación. También puedes usar un token o una API key en el encabezado de autorización, útil en configuraciones programáticas.
Lo que el servidor puede hacer, según la documentación, es encontrar, crear y actualizar objetos como issues, proyectos y comentarios. La página también menciona documentos y avisa de que habrá más funciones. Linear lista como clientes compatibles a Claude, Claude Code, Codex, Cursor, VS Code, Windsurf y Zed, entre otros.
Además, Linear Agent, su agente propio, puede conectarse a otros servidores MCP desde la personalización del agente o desde automatizaciones de triage (novedad de abril de 2026). Los administradores controlan el acceso con listas de permitidos y permisos de MCP a nivel de workspace.
¿Y si quiero delegar el issue en lugar de conectar mi propio agente?
Linear tiene dos caminos distintos y conviene no mezclarlos:
- MCP (tú llevas el agente a Linear): abres Claude Code, Codex, Cursor u otro cliente y este lee y escribe en Linear con tu cuenta.
- Plataforma de agentes (Linear lleva el trabajo al agente): un administrador instala un agente desde el Integrations Directory y elige a qué equipos tiene acceso. Después puedes asignarle (delegarle) un issue o mencionarlo con @ en un comentario. En la página de integraciones de Linear, Codex aparece como agente al que se delegan issues y Cursor como agente que convierte issues en pull requests; Claude figura como cliente de IA que se conecta por MCP.
Los agentes instalados no cuentan como asientos facturables, aunque su proveedor puede cobrar aparte. No pueden iniciar sesión en la app, acceder a funciones de administración ni gestionar usuarios. Linear permite además escribir una guía a nivel de workspace y de equipo con tus convenciones; si ambas existen, la del equipo tiene prioridad. Para seguir qué hizo cada agente, puedes filtrar por “Delegate” en vistas personalizadas.
¿Qué plan de Linear necesito?
Según la página de precios de Linear en noviembre de 2026, el acceso por MCP, Linear Agent y la plataforma de agentes están incluidos en todos los planes, también el gratuito. El agente de programación en la nube y los Loops requieren créditos de IA. Los planes de pago cuestan 10 USD (Basic) y 16 USD (Business) por usuario al mes con facturación anual; Enterprise es a medida. Los precios cambian: confírmalos en la página antes de decidir.
¿Qué puede hacer un agente con Linear y por qué le importa a un diseñador?
Un agente puede leer un issue, proponer un plan o actualizar su estado. Le importa a un diseñador porque el backlog es el lugar donde una idea de diseño se convierte en trabajo. Si el agente lee el issue completo, con sus comentarios y criterios, puede proponer un plan que el diseñador revisa antes de tocar código. Eso acorta el paso de “qué hay que hacer” a “cómo se verá” y hace visible la decisión.
Esto encaja con la idea de orquestación de agentes: el backlog es la fuente de instrucciones, y el agente es quien ejecuta. Cuanto mejor escrito esté el issue, mejor será el trabajo que sale de él.
Algunos usos que describen las guías de integración:
- Empezar desde un ticket: leer el issue y sus comentarios y proponer un plan antes de codificar.
- Actualizar al hacer merge: mover el ticket a revisión y dejar un resumen del cambio.
- Hacer triage: listar los issues sin empezar del ciclo actual o los bloqueados por otro.
- Crear o editar: abrir issues o comentarios a partir de un hallazgo de research.
Para diseño, el uso más valioso suele ser el segundo: un resumen claro de qué cambió y qué criterio de aceptación cumple, dejado en el ticket.
¿Qué riesgos tiene y cuándo no conviene?
Las escrituras usan tus permisos. El agente puede cambiar lo que tú puedes cambiar, y no ve equipos a los que no tienes acceso. Sigue siendo acceso de escritura.
Otros puntos a vigilar:
- Pedidos sin alcance: “muéstrame el backlog” puede llenar el contexto del agente y gastar tokens sin necesidad.
- Datos viejos: el MCP devuelve instantáneas; si alguien cambió el issue mientras trabajas, el agente no lo sabe. Vuelve a leer antes de escribir.
- Contexto incompleto: lo que no está escrito en el ticket o en sus comentarios no llega al agente. Las decisiones tomadas en Slack o en una reunión son invisibles para él.
- Credenciales: guarda los tokens fuera del repositorio y revoca los que ya no uses.
Cuándo NO conviene:
- Cuando el backlog contiene información confidencial que no debe salir a un agente externo.
- Cuando el equipo no tiene criterios de aceptación: el agente inventará los suyos.
- Cuando se quiere que el agente decida prioridades. Eso es trabajo del equipo.
- Cuando los issues son demasiado cortos para dar contexto: el agente trabajará con suposiciones.
¿Cómo se aplica en un proyecto?
Una configuración prudente:
- Conecta el MCP con permisos de solo lectura para la primera semana.
- Define en el ticket el criterio de aceptación y el alcance del cambio.
- Pide al agente un plan, no código, y revísalo.
- Solo cuando el plan es correcto, habilita escritura para el cambio de estado y el comentario final.
- Revisa el historial de cambios de Linear después de cada sesión.
Si el flujo incluye agentes de código, conviene leer también Claude Code o Cursor para entender dónde se ejecuta el trabajo.
Cómo escribir un issue que un agente pueda ejecutar. Un agente trabaja tan bien como el issue que recibe. Un formato sencillo para diseño:
- Problema: qué ocurre hoy, con una cita o una captura.
- Resultado esperado: qué debe ser verdad cuando termine, en términos observables.
- Alcance: qué pantallas o componentes entran y cuáles no.
- Criterios de aceptación: tres a cinco condiciones que alguien pueda comprobar.
- Referencias: enlace al prototipo, al componente del sistema de diseño y a la decisión previa.
Si el issue no tiene criterios comprobables, el agente los inventará. Y si no dice qué queda fuera, el cambio crecerá sin control. Antes de asignar un issue a un agente, pregúntate si otra persona del equipo podría ejecutarlo con esa información sin llamarte.
Ejemplo
Ejemplo ilustrativo: un diseñador tiene un issue “Mejorar el estado vacío de notificaciones” con criterios claros y un enlace al prototipo. Conecta el MCP en solo lectura y pide a su agente que lo lea y proponga un plan con los componentes existentes. Revisa el plan, que propone reutilizar el componente de estado vacío del sistema de diseño. Después habilita escritura, el agente deja un comentario con el plan aprobado y mueve el ticket a “En progreso”.
Lo que aprendió: el plan corto antes de codificar detectó que el agente quería crear un componente nuevo cuando ya existía uno.
Errores comunes
- Dar acceso de escritura desde el primer día.
- Pedir al agente “todo el backlog” en una sola consulta.
- Escribir issues sin criterios de aceptación y esperar buenos resultados.
- Olvidar que el agente no ve lo que se decidió en Slack o en una reunión.
- Dejar tokens activos en máquinas que ya no se usan.