Agentes de programación

Siempre puedes ejecutar un CLI de agente a mano en una terminal, y para algo puntual suele ser lo más adecuado. Cuando Deska arranca ese mismo CLI como sesión estructurada habla el protocolo propio de la herramienta en lugar de leer su salida en pantalla, y eso aporta cuatro cosas:

• Eventos en streaming en vez de texto interpretado. Los mensajes, las llamadas a herramientas, las actualizaciones del plan, las subtareas delegadas y los avisos del proveedor llegan como elementos separados, así que la transcripción puede mostrar cada uno como corresponde y no como un muro de salida de terminal.
• Aprobaciones y preguntas como tarjetas de interfaz. Una solicitud de permiso pausa el turno y muestra una tarjeta que respondes con una tecla o un clic, en el panel o en tu teléfono, en vez de un aviso enterrado en el historial que solo la terminal enfocada puede contestar.
• Conversaciones que sobreviven a un reinicio. Deska guarda un cursor de reanudación para cada sesión, así que volver a abrir la aplicación y enviar el siguiente mensaje reabre la misma conversación del proveedor con su contexto intacto. Un turno que estaba en curso cuando se cerró la aplicación se reporta como fallido y no se repite en silencio, porque volver a ejecutar efectos que tú nunca reenviaste sería peor que decirlo.
• Contabilidad real de tokens. Los tokens de entrada, salida y caché se suman por hilo, con un anillo de contexto visible solo cuando el proveedor reportó de verdad el tamaño de su ventana.

Las sesiones estructuradas son lo que supervisa el tablero Inbox. Consulta Hilos de agente para el tablero, y Agentes y Dex para el chat consciente del lienzo.

El modo de ejecución es el ajuste más importante de un agente: decide cuánto puede hacer sin preguntarte. Deska traduce tu elección a la política de permisos y de sandbox propia de cada proveedor al iniciar la sesión, de modo que la mayoría de los avisos nunca ocurren y los que quedan llegan como tarjetas de aprobación.

• Approval required ejecuta el agente en un sandbox de solo lectura. Puede leer y razonar, y cada comando o edición vuelve a ti primero. Úsalo en un repositorio que no conoces, o cuando quieras ver pensar a un agente antes de que toque nada.
• Auto-accept edits es el modo por defecto. El agente puede escribir dentro del espacio de trabajo en el que arrancó sin pedir permiso cada vez, y todo lo que salga de ese límite sigue necesitando tu aprobación.
• Auto (AI reviews risky actions) mantiene el mismo límite del espacio de trabajo, pero envía las aprobaciones de acciones arriesgadas a un modelo revisor en lugar de a ti. No todos los proveedores tienen revisor; donde no existe, la sesión se comporta como auto-accept edits en vez de fingir que revisa.
• Full access elimina el sandbox por completo. Nada queda confinado al espacio de trabajo y nada se detiene a pedir aprobación.

Eliges el modo al crear un hilo y puedes cambiarlo a mitad de conversación desde el pie del compositor. Los modos que el proveedor y el modelo actuales demostrablemente no pueden cumplir aparecen desactivados en lugar de ignorarse en silencio.

Una misma máquina suele tener más de una forma de ejecutar el mismo agente: una cuenta de trabajo y una personal, una instalación estable y una nocturna. Una instancia de proveedor es una configuración con nombre que defines una vez y luego eliges por hilo. Se gestionan en Settings → Coding agents → Instances, una página propia bajo AI capabilities.

Las instancias importan por una razón más, y es la principal: también son el motor detrás de Dex. El asistente no corre sobre un modelo gestionado por Deska; corre sobre una de estas mismas instancias, y la que eliges en Settings → Dex, en la sección Who answers, es el agente que responde cada pregunta que escribes o dices.

Si la que elegiste no está instalada en esta computadora, o nadie inició sesión en ella, Dex prueba la siguiente instancia que tengas en vez de fallar en la primera. Cuando ninguna puede responder, la respuesta dice qué agente hacía falta y si lo que necesita es instalarlo o iniciar sesión, con un botón que te lleva directo a la página donde se arregla.

Cada instancia puede llevar lo suyo:

• Binario, cuando el CLI no es el primero de tu PATH.
• Directorio de inicio, que es como dos instancias del mismo proveedor mantienen sesiones iniciadas en cuentas distintas. Deska lo traduce a la variable de directorio de configuración propia del proveedor.
• Modelo por defecto, modo de ejecución por defecto y, donde el proveedor lo admite, un esfuerzo de razonamiento por defecto.
• Argumentos de línea de comandos adicionales para banderas del proveedor que Deska no modela, añadidos literalmente al iniciar la sesión.
• Un color de acento, únicamente para que sus hilos se reconozcan de un vistazo en el tablero.

Los valores se resuelven de lo más específico a lo más general: lo que fija el hilo, luego el valor por defecto del proyecto, luego el de la instancia y por último el del propio proveedor. Deska también sondea de forma barata el almacén de credenciales de cada instancia y marca las que parecen sin sesión iniciada, así que un hilo que va a fallar por autenticación lo dice antes de que envíes un mensaje.

El modo plan cambia lo que produce un turno, no lo que se le permite hacer. Pulsa ShiftTab en el compositor para armar el siguiente turno como planificación y aparecerá una insignia PLAN MODE. Ese turno investiga el código en solo lectura y vuelve con un plan propuesto en lugar de editar archivos, sea cual sea el modo de ejecución de la sesión.

Cada proveedor lo hace a su manera, con su modo de permisos de planificación nativo, una política de solo lectura por turno o un agente de planificación integrado, así que obtienes el mismo comportamiento en los tres. El resultado aterriza como una tarjeta Proposed plan en el hilo, donde Implement devuelve el plan para ejecutarlo, Refine prellena un seguimiento pidiendo cambios, e Implement in new worktree thread arranca un hilo hermano en su propia copia, para que planificación y ejecución nunca compartan árbol de trabajo.

Deska no trae una lista fija de modelos para estos agentes. Le pide a cada CLI instalado su propio catálogo por el mismo protocolo que ya habla, y luego cierra ese sondeo. Obtienes los modelos que tu instalación y tu cuenta tienen de verdad, incluidos los que salieron después de tu copia de Deska. El descubrimiento corre bajo demanda desde los ajustes, tiene un tiempo límite y sus resultados se cachean, así que nada queda esperándolo durante el trabajo normal.

Las sesiones también recogen lo que el CLI anuncia sobre sí mismo. Los comandos slash que el proveedor expone quedan disponibles en el compositor (Codex también lista sus propias skills tras $), y los proveedores con agentes o personas con nombre también los exponen. Cambiar el modelo de un hilo es seguro en cualquier momento: si no hay nada en ejecución se aplica la próxima vez que el hilo arranque, y a mitad de conversación se aplica desde el siguiente turno, sin alterar nunca un turno ya en curso.

Un CLI de agente que se queda corriendo ocupa recursos reales: un proceso y, a veces, un servidor local con su puerto. Una sesión sin turno activo y sin aprobaciones ni preguntas pendientes durante treinta minutos ve detenido su proceso de proveedor. No se pierde nada de la conversación. La sesión conserva su identidad y tu siguiente mensaje reinicia el proveedor de forma transparente desde el cursor de reanudación y continúa donde se quedó. Lo único que notas es que el primer mensaje tras una pausa larga tarda un poco más en arrancar.

Cuando una sesión no puede iniciarse o muere, Deska nombra la causa en lugar de mostrar un volcado: el CLI no se pudo lanzar, hace falta iniciar sesión en ese proveedor, el CLI instalado es demasiado antiguo, el proveedor respondió de forma inesperada, el proceso ya no está, o dejó de responder. Los fallos sin una causa reconocible muestran su mensaje tal cual, sin etiquetarlos con una causa que nadie estableció. Solución de problemas cubre qué hacer con cada uno.