Modalidades de uso

El ecosistema se entiende mejor si separamos dos cosas: qué es cada componente y qué rol tiene. Primero veremos los conceptos y después las herramientas que permiten a un modelo acceder a información o actuar.

Conceptos

Modelo (LLM). Es el motor que procesa entradas y genera respuestas. Por sí solo no abre una carpeta, consulta PubMed ni ejecuta un comando.

Chatbot. Es una interfaz para conversar con uno o varios modelos. Recibe una petición y devuelve una respuesta. Puede incorporar archivos o búsqueda.

Asistente. Es un chatbot configurado para cumplir una función más estable. Puede tener instrucciones, documentos, memoria o herramientas y mantener una forma de trabajar consistente entre conversaciones.

Agente. Recibe un objetivo, decide el siguiente paso, utiliza herramientas, observa el resultado y continúa hasta terminar o pedir ayuda.

Harness. Es el programa que convierte al modelo en una herramienta de trabajo. Mantiene el bucle del agente, prepara el contexto, ejecuta herramientas, controla permisos y enseña el progreso. Codex y Claude Code son ejemplos de harnesses de agente.

Orquestador o wrapper. Es la capa que lanza y supervisa harnesses. Gestiona hilos, modelos, subagentes, notificaciones y la interfaz desde la que los controlamos.

Ajustes habituales de un harness

El harness suele permitir elegir el modelo, el nivel de razonamiento y los permisos. Ojo, son ajustes del entorno de trabajo, no capacidades que aparezcan por cambiar el prompt.

Niveles de razonamiento

Lo que suelo recomendar y aplicar yo mismo es utilizar el nivel más bajo que dé un resultado suficientemente bueno. Más razonamiento implica más gasto de tokens y en muchas ocasiones vale más la pena pararse a definir mejor el prompt que dar uno vago y esperar que un nivel mayor de razonamiento te salve.

Modo plan

El modo plan cambia la forma de trabajar del harness. Antes de modificar nada, el agente revisa el contexto, identifica las decisiones pendientes y propone una secuencia de trabajo para que podamos corregirla o aprobarla. Normalmente suele activarse con /plan.

Resulta especialmente útil si una decisión inicial condiciona todo lo que viene después:

Por ejemplo, antes de reorganizar los metadatos de cientos de muestras, podemos pedir que identifique archivos, columnas protegidas, reglas para duplicados y comprobaciones finales sin modificar todavía los datos. Una vez revisado el plan, pasamos a la ejecución.

Ejemplo

Imagina que quieres cribar abstracts sobre un tema en concreto. Si tienes claro lo siguiente:

1. Objetivo: qué decisión o producto se necesita.
2. Entradas: qué documentos o datos puede utilizar.
3. Procedimiento: pasos y criterios que debe seguir.
4. Salida: campos, formato y orden.
5. Restricciones: qué no puede inferir o modificar.
6. Evidencia: cómo debe señalar el respaldo de cada afirmación.
7. Control: qué revisar y cuándo detenerse.

Entonces podrías redactar un prompt como el siguiente.

Objetivo: cribar abstracts para una revisión sobre [tema].
Entradas: pregunta PECO y abstracts numerados.
Procedimiento: aplica cada criterio por separado.
Salida: ID | incluir/excluir/dudoso | criterio | fragmento de apoyo.
Restricciones: no uses el título para completar datos ausentes.
Control: marca como dudoso cualquier caso sin evidencia explícita.

Si, por el contrario, no lo tienes claro, entonces el modo plan es una buena opción.

Ventana de uso

En determinados planes de suscripción, Codex y Claude Code agrupan parte del consumo en ventanas móviles de cinco horas. No equivale a un número fijo de mensajes: influyen el modelo, el nivel de razonamiento, la longitud de la conversación, los archivos y las herramientas utilizadas. Si trabajas mediante API, en cambio, el consumo suele facturarse por uso y no funciona como una bolsa de suscripción.

Las condiciones cambian entre planes y pueden existir además límites semanales o uso compartido con otras superficies. Antes de una tarea larga, revisa el contador de la propia aplicación, o una herramienta como CodexBar, y consulta las páginas vigentes de uso de Codex y límites de Claude Code.

Cambiar de modelo y la caché

Para responder a cada nuevo mensaje, el sistema vuelve a procesar el contexto. Algunos proveedores pueden reutilizar el cálculo mediante una caché, lo que reduce latencia y coste. Esa reutilización depende del modelo y de la configuración: si cambias de modelo a mitad de una conversación, el nuevo modelo tendrá que procesar de nuevo el contexto y se pierde parte o toda la ventaja de la caché anterior.

Por eso no conviene cambiar de modelo cuando el hilo ya es largo. Si el cambio está justificado, termina primero la tarea actual, resume el estado imprescindible y abre un hilo nuevo.

Formas de potenciar los modelos

En el anterior capítulo habíamos comentado que un modelo por sí solo únicamente puede generar una salida a partir del contexto que recibe. Para consultar información actual, trabajar con archivos o actuar sobre una aplicación necesita herramientas.

Tool use

Una herramienta es una acción concreta que el modelo puede solicitar. Para cada una recibe un nombre, una descripción y los datos que necesita. El ciclo habitual es:

1. Pedimos una tarea.
2. El modelo decide si necesita una herramienta.
3. Genera una llamada con los argumentos necesarios.
4. El harness comprueba los permisos y la ejecuta.
5. El resultado vuelve al modelo, que lo interpreta o solicita otra herramienta.

Por ejemplo, para comprobar los DOI de una bibliografía, el modelo puede pedir una búsqueda para cada referencia. La herramienta devuelve candidatos y el modelo los compara con el título, los autores y el año. La búsqueda aporta datos, pero no garantiza que la coincidencia elegida sea correcta.

MCP, conectores y plugins

MCP (Model Context Protocol) es un protocolo común para ofrecer herramientas y contexto a distintos agentes. Un servidor MCP describe qué herramientas tiene y qué argumentos acepta. Codex, Claude Code u otro cliente compatible puede descubrirlas y utilizarlas sin necesitar una integración distinta para cada agente.

Un conector es una integración ya preparada con una aplicación o servicio concreto. Puede estar construido sobre MCP, pero para la persona usuaria lo importante es que ofrece acceso a una fuente identificada, con unos permisos determinados.

Un plugin es un paquete instalable. Puede reunir conectores, servidores MCP, skills o interfaces adicionales para distribuir varias capacidades juntas.

Si quieres profundizar

Delegación, subagentes y permisos

Delegación

Dar acceso a herramientas no explica por sí solo qué puede hacer un agente. Un encargo debería definir:

1. objetivo y criterio de finalización;
2. recursos permitidos;
3. acciones prohibidas;
4. formato del resultado;
5. comprobaciones obligatorias;
6. puntos que requieren aprobación humana.

Por ejemplo: «Revisa los PDF de esta carpeta, extrae los metadatos a una tabla nueva y no renombres ni borres archivos. Marca los duplicados como propuesta; no los elimines».

Subagentes

Un subagente es un agente al que el agente principal delega una parte concreta del trabajo. Tiene su propio hilo y contexto, y devuelve un resultado al agente principal. No tiene por qué utilizar un modelo más pequeño: podemos elegir el modelo y el nivel de razonamiento según la tarea.

Son útiles cuando el trabajo puede dividirse de verdad:

• buscar literatura en áreas distintas;
• revisar por separado método, estadística y reproducibilidad;
• comprobar enlaces, tablas o referencias mientras el agente principal redacta;
• explorar varias hipótesis independientes.

No aportan gran cosa cuando cada paso depende del anterior. Tampoco conviene poner varios agentes a editar el mismo archivo o la misma tabla a la vez: el tiempo que se gana en paralelo puede perderse resolviendo conflictos.

Divide esta revisión entre tres subagentes independientes:
1. metodología y riesgo de sesgo;
2. consistencia de resultados y cifras;
3. referencias, DOI y enlaces.

No modifiquéis el manuscrito. Devolved hallazgos con evidencia localizable.
Espera a los tres y prepara una única lista, eliminando duplicados y
señalando las discrepancias entre revisores.

Cada subagente utiliza contexto y herramientas, por lo que el consumo total suele aumentar. La ventaja está en mantener limpio el hilo principal y avanzar en paralelo. Los permisos deben decidirse antes de delegar, ya que los subagentes trabajan con los controles definidos en la tarea de origen.

Permisos según la acción

Antes de conectar un servicio o delegar una tarea, comprueba qué datos podrá leer, qué acciones podrá ejecutar, con qué identidad actuará y cómo se revoca el acceso. Es preferible autorizar una carpeta concreta antes que todo el proyecto y empezar en modo lectura antes de permitir modificaciones.

Control remoto

El control remoto permite iniciar, seguir, corregir y aprobar una tarea que se está ejecutando en otro ordenador. Por ejemplo, podemos dejar un análisis largo en el equipo del laboratorio y comprobar desde el móvil si ha terminado o si necesita una decisión.

El trabajo sigue ocurriendo en el ordenador conectado. Los archivos, credenciales, plugins, navegador, herramientas y permisos son los de ese equipo; el móvil funciona como mando y superficie de revisión. Si el equipo se apaga, pierde la conexión o entra en reposo, el trabajo remoto puede detenerse.

En un entorno institucional, activa autenticación multifactor, utiliza equipos administrados y revisa qué dispositivos están emparejados.