Configurar Credenciales y Runtimes

Objetivo

Preparar OPS para que las tareas IA y los despliegues se ejecuten con el proveedor correcto, sin secretos expuestos y sin fallbacks inesperados.

Esta guia existe porque muchas incidencias operativas parecen "errores de agente", pero en realidad son problemas de credenciales, runtime no disponible, modelo mal elegido o dispatch activado antes de tiempo.

Conceptos

Credencial:

• secreto gestionado por OPS;
• permite autenticar contra un proveedor, runtime, servidor o destino;
• no debe copiarse en comentarios, tareas ni documentacion.

Runtime:

• herramienta que ejecuta una tarea;
• puede ser un CLI local, un servicio o un proveedor;
• debe estar disponible en el host donde corre el worker.

Modelo:

• identificador que entiende el runtime o proveedor;
• no debe asumirse solo por nombre comercial;
• si el runtime no lo soporta, la tarea debe bloquearse o revisarse.

Dispatch:

• sistema que toma tareas en cola y las entrega a workers/agentes;
• solo debe estar activo si runtime, credenciales y tareas estan preparados.

Paso 1: identificar que necesitas ejecutar

Antes de crear credenciales, responde:

• Es una tarea de agente IA?
• Es una tarea de despliegue?
• Es una tarea de servidor?
• Es una integracion externa?
• Requiere MiniMax Token Plan, OpenCode Go u otro proveedor?
• Debe ejecutarse automatico o con intervencion humana?

Por que importa:

• No todas las credenciales sirven para todo.
• Una credencial de despliegue no debe usarse como credencial de agente.
• Un runtime puede existir pero no estar autenticado para ese modelo.

Paso 2: crear o revisar credencial

Ve a Automatizacion -> Credenciales.

Campos importantes:

• nombre claro;
• tipo o proveedor;
• scope;
• uso previsto;
• estado activo/inactivo;
• notas no sensibles;
• fecha de revision si aplica.

Buenas practicas:

• Nombra la credencial segun proveedor y uso.
• No incluyas el valor del secreto en el nombre.
• Si cambias una credencial, deja comentario operativo sin exponer secretos.
• Si una credencial es temporal, anotarlo ayuda a no depender de ella.

Paso 3: elegir scope correcto

Scope recomendado:

• Workspace: para credenciales compartidas por el espacio de trabajo.
• Personal: para acceso individual o pruebas.
• Deployment/server: para objetivos tecnicos concretos.

Por que importa:

• El scope limita donde se puede usar la credencial.
• En un piloto o SaaS, credenciales mal compartidas son riesgo de seguridad.
• La UI debe mostrar suficiente contexto sin revelar secretos.

Paso 4: asociar runtime y modelo

Cuando una tarea IA use una credencial, revisa tambien:

• perfil/subagente;
• execution mode;
• modelo;
• runtime preferido;
• skills requeridos;
• deployment target si aplica.

Regla importante:

No cambies de proveedor como fallback silencioso. Si una tarea estaba pactada con MiniMax u OpenCode, se mantiene salvo decision explicita. Si no se puede ejecutar, se bloquea con motivo claro.

Paso 5: ejecutar Runtime check

Antes de activar dispatch o lanzar tareas IA, ejecuta Runtime check.

Debe confirmar:

• runtime disponible;
• credencial activa;
• worker fresco si aplica;
• modelo/proveedor coherente;
• sin blockers inesperados.

Si falla:

1. Revisa si el runtime existe en el host.
2. Revisa si la credencial esta activa.
3. Revisa si el modelo seleccionado pertenece al proveedor esperado.
4. Revisa si el worker esta reportando estado reciente.
5. Bloquea la tarea si no hay seguridad de ejecucion.

Paso 6: preparar dispatch

Antes de poner tareas en queued, confirma:

• dispatch esta on solo si quieres que se procese cola;
• la tarea tiene perfil/subagente;
• la tarea tiene instrucciones completas;
• la tarea tiene criterio de terminado;
• si requiere decision humana, empieza en waiting o pasa a review;
• si requiere propuesta previa, no debe desarrollar ni publicar automaticamente.

Por que importa:

• Dispatch ejecuta lo que le das, no lo que querias decir.
• Una tarea ambigua puede consumir tiempo y generar output inutil.
• Las tareas sensibles deben tener human gate o bloqueo por decision.

Ejemplo: tarea editorial recurrente

Objetivo correcto:

• La primera ejecucion propone temas.
• La tarea queda bloqueada o en review.
• El usuario elige tema.
• La siguiente fase desarrolla el tema elegido.
• No publica automaticamente.

Configuracion recomendada:

• proyecto asignado;
• perfil editorial o research;
• modelo/proveedor definido;
• instrucciones con fecha de ejecucion;
• criterio: "proponer temas y esperar decision";
• estado final esperado: waiting o review.

Checklist antes de ejecutar IA

• Workspace correcto.
• Proyecto correcto.
• Credencial activa.
• Runtime check OK.
• Modelo compatible.
• Perfil/subagente correcto.
• Skills necesarios.
• Instrucciones claras.
• Criterio de terminado.
• Regla de bloqueo si falta decision.

Errores comunes

• Usar Hermes, OpenCode, MiniMax u otro runtime sin comprobar lo pactado.
• Activar dispatch para "ver si funciona".
• Crear tareas IA sin perfil.
• Mezclar credenciales de servidor con credenciales de agente.
• Copiar secretos en notas.
• Cambiar modelo sin dejar trazabilidad.
• Reintentar una tarea bloqueada sin corregir la causa.

Resultado esperado

Al terminar esta guia deberias saber:

• que credencial usa cada tipo de trabajo;
• que runtime esta disponible;
• que tareas pueden entrar en cola;
• que tareas deben esperar decision humana;
• como detectar si el problema esta en credencial, runtime, modelo o instrucciones.