IA local por dentro: qué hay realmente detrás de un agente de inteligencia artificial

Cuando escribimos «busca esto, abre aquello y dime qué has encontrado», parece que todo ocurre dentro de un único cuadro de chat. Es una ilusión muy cómoda: escribimos una orden, esperamos unos segundos y recibimos una respuesta.

¿Qué ocurre realmente detrás del cuadro de chat?

Esa pregunta es la columna vertebral de este artículo. Para responderla voy a utilizar la historia de PowerChat, OpenClaw y Agente Jiménez como un caso real con el que explicar las piezas que forman un agente y la función que cumple cada una.

Al terminar deberías poder mirar cualquier agente moderno —local o en la nube— y distinguir aproximadamente quién entiende la orden, quién aporta información, quién ejecuta acciones, quién comprueba el resultado y por qué una sola petición puede esconder muchos pasos.

¿Qué ocurre realmente cuando le pides algo a un agente?

Un modelo de lenguaje recibe texto y genera texto. Puede interpretar una petición, resumir información o redactar una respuesta convincente. Pero eso, por sí solo, no le permite consultar el tiempo, abrir un programa, leer un archivo ni comprobar que una acción se completó.

Para hacer esas cosas necesita un sistema alrededor. Ese sistema puede preparar contexto, escoger herramientas, ejecutar código, devolver resultados al modelo y verificar lo sucedido. Cuando todas esas piezas colaboran, dejamos de hablar solamente de un chatbot y empezamos a hablar de un agente.

PowerChat: descubrir que un modelo no es un agente

Mi primer intento serio fue PowerChat. Ya hablé brevemente de él en Cómo usé una IA para crear una IA que creó un software espía.

Quería experimentar con modelos locales relativamente ligeros que pudieran funcionar en un ordenador cotidiano. PowerChat conversaba, pero al añadir herramientas, historial, acciones y procesos de varios pasos aparecían fallos por todas partes.

Aquello me enseñó la primera lección importante: un modelo puede hablar como si supiera hacer algo sin disponer de ningún mecanismo para hacerlo. También puede elegir una herramienta equivocada, perder una instrucción dentro de un contexto demasiado grande o describir una acción que nunca ocurrió.

PowerChat no fracasó por no saber conversar. El problema era que conversar y actuar son tareas distintas.

El alumno que sabe copiar

La analogía que mejor me funciona es la de dos alumnos haciendo un examen. Uno es extraordinariamente inteligente, ha estudiado todo el temario y recuerda casi todas las respuestas. El otro sabe bastante menos, pero tiene apuntes, acceso a una biblioteca, una calculadora y alguien le ha enseñado cuándo utilizar cada cosa.

No estoy intentando convencerme de que el segundo alumno se ha vuelto mágicamente tan inteligente como el primero.

Estoy intentando enseñarle a copiar bien en el examen.

Un modelo pequeño puede no conocer una información reciente, pero una herramienta puede buscarla. Puede no ser fiable haciendo una operación exacta, pero el código puede resolverla. Puede necesitar instrucciones especializadas, y una skill puede proporcionarle un procedimiento.

En esta comparación, el modelo es el alumno, el contexto son los apuntes, las herramientas son la calculadora y la biblioteca, las skills son los manuales para resolver determinados ejercicios y el orquestador decide qué coloca encima de la mesa en cada momento.

OpenClaw: descubrir que el problema era la arquitectura

Más tarde apareció el proyecto que hoy conocemos como OpenClaw. Durante su evolución pasó por Clawdbot y Moltbot hasta adoptar definitivamente el nombre OpenClaw el 30 de enero de 2026. Su documentación oficial conserva esa historia.

Al experimentar con él, el descubrimiento importante no fue una herramienta concreta. Fue la jerarquía y la separación de responsabilidades. OpenClaw organiza sesiones, herramientas, skills, modelos y rutas alrededor de una capa central. Su arquitectura muestra que el modelo es una pieza del sistema, no el sistema completo.

PowerChat me había mostrado el problema. OpenClaw me ayudó a poner nombre y orden a las piezas. Con esa lección regresé al desarrollo propio.

Agente Jiménez: cómo se organizan las piezas de un agente

Agente Jiménez es, en cierto modo, PowerChat reconstruido después de aprender todo lo que PowerChat hacía mal y de estudiar cómo otros proyectos organizaban mejor un agente.

El modelo neuronal no vive dentro de Agente Jiménez. Vive en LM Studio, que puede ejecutar modelos de pesos abiertos y ofrecerlos mediante un servidor local. Agente Jiménez se coloca alrededor y organiza el trabajo.

Actualmente utilizo tres perfiles para dividir responsabilidades: Adolfo para conversación e investigación, Adolfo-Assistant para acciones y automatización, y Adolfo-Dev para desarrollo de software. No son tres modelos: son tres configuraciones que limitan instrucciones, rutas y capacidades.

Elegí modelos locales porque quería experimentar en hardware corriente y conservar control sobre la arquitectura. Eso no significa que la IA local sea siempre mejor ni automáticamente privada. Una búsqueda web o una herramienta externa sigue generando tráfico. La comparación completa entre ambos enfoques está en IA local vs IA en la nube.

Seguimos una petición de principio a fin

Imaginemos que escribo: «Busca qué tiempo hará mañana y dime si merece la pena salir».

El chat solamente recoge la frase. El orquestador detecta que la respuesta depende de datos recientes, identifica la fecha y la ubicación disponibles en el contexto, autoriza la herramienta meteorológica y prepara la consulta. La herramienta obtiene datos reales. El modelo los interpreta y redacta una recomendación. Finalmente, el sistema comprueba que existe un resultado válido antes de responder.

Ese recorrido responde a las preguntas que normalmente quedan ocultas:

• ¿Quién decide qué hacer? El orquestador.
• ¿Quién escribe la respuesta? El modelo.
• ¿Cómo sabe cosas recientes? Mediante fuentes y herramientas.
• ¿Cómo recuerda la conversación? Con contexto seleccionado, no con memoria infinita.
• ¿Cómo aprende procedimientos? Con instrucciones y skills.
• ¿Cómo actúa fuera del chat? Mediante tool calling y código.
• ¿Cómo sabemos que lo hizo? Verificando el resultado.
• ¿Por qué no puede hacerlo todo? Por permisos, límites y capacidades disponibles.

El modelo y el contexto

El modelo interpreta la intención, relaciona conceptos, elige entre alternativas y genera lenguaje. Es la parte flexible del sistema y también la menos determinista.

Conviene utilizarlo cuando hay ambigüedad, lenguaje natural o decisiones difíciles de convertir en reglas. No conviene pedirle que sustituya una comprobación exacta que puede hacer el código.

Si necesito validar que un JSON cumple una estructura, utilizo código. Si una herramienta devuelve una temperatura, utilizo ese dato. Si necesito explicar qué significa esa previsión para una persona, ahí sí tiene sentido el modelo.

Los modelos tienen una longitud máxima de contexto: una cantidad limitada de tokens que pueden mantener disponibles mientras responden. LM Studio advierte de que excederla puede producir comportamientos erráticos.

Guardar una conversación no equivale a enviarla completa en cada turno. Un agente tiene que seleccionar qué mensajes recientes, instrucciones, datos del usuario y resultados anteriores son relevantes para la petición actual.

No solo importa cuánta memoria tienes. También importa qué decides colocar dentro del contexto.

Tools y skills

Una herramienta permite al sistema consultar o modificar algo que está fuera del modelo: buscar en la web, leer un archivo, consultar una API, abrir un programa o ejecutar una operación exacta.

En el tool use de LM Studio, el modelo no ejecuta directamente una función. Genera una solicitud estructurada; el programa valida esa solicitud, ejecuta la función y devuelve el resultado.

La herramienta es la mano. El modelo puede pedir «consulta el tiempo», pero el código decide cómo se llama a la API, qué parámetros son válidos y qué respuesta se devuelve.

Antes de pensar en archivos o formatos, una skill puede entenderse como un manual de procedimientos que el agente consulta para abordar una tarea.

Puede explicar cómo investigar un tema, cómo revisar una traducción, qué pasos seguir al diagnosticar un sistema o cuándo debe utilizarse una herramienta. Después aparece la implementación técnica: proyectos como OpenClaw utilizan archivos SKILL.md para organizar esas instrucciones y decidir cuándo están disponibles.

Instalar una skill no vuelve experto al modelo ni le concede automáticamente permiso para ejecutar código. En Agente Jiménez, una capacidad ejecutable requiere una integración explícita con el orquestador. Además, las skills de terceros deben tratarse como contenido no confiable.

El orquestador

El orquestador es la pieza que decide qué pone encima de la mesa. Identifica el perfil activo, prepara las instrucciones, selecciona el contexto, ofrece solamente las herramientas permitidas, coordina las llamadas y entrega los resultados al modelo.

Esta separación es especialmente importante con modelos pequeños. Veinte herramientas también significan veinte oportunidades de elegir la equivocada. Miles de instrucciones ocupan contexto aunque no tengan relación con la tarea. Dividir responsabilidades reduce el problema que el modelo debe resolver.

Un buen agente no es aquel que utiliza más IA. Es aquel que sabe dónde merece la pena utilizarla.

Verificación, ciclo del agente y permisos

Un modelo puede generar perfectamente la frase «he abierto el programa». Eso es texto. Una herramienta puede intentar abrirlo. Eso es una acción. El sistema puede comprobar si el programa quedó realmente abierto. Eso es verificación.

Cuando pasamos de un chatbot a un agente, confundir esas tres cosas es peligroso. Una respuesta convincente no demuestra que la acción se ejecutara.

Además, una orden puede requerir un ciclo completo. El agente observa el estado, decide el siguiente paso, actúa, comprueba el resultado y vuelve a observar. Puede repetirlo hasta completar la tarea, encontrar un error o alcanzar un límite de seguridad.

Por eso una sola petición visible puede generar varias llamadas al modelo y varias acciones internas. El usuario ve un turno; el sistema puede haber recorrido el ciclo muchas veces.

Cada herramienta amplía lo que el agente puede hacer y también lo que puede salir mal. Leer un archivo no implica el mismo riesgo que borrarlo. Consultar una API no equivale a controlar el escritorio. La arquitectura debe definir permisos, validar parámetros, limitar repeticiones y registrar resultados.

Un modelo local puede alucinar, una herramienta puede fallar y una skill puede contener instrucciones peligrosas. Ejecutar el modelo en nuestro PC no elimina esos riesgos. Solamente nos da más control sobre dónde colocar las fronteras.

Al final, ¿qué es realmente un agente de IA?

Un agente no es solamente un modelo que habla. Es un sistema que combina un modelo, contexto seleccionado, herramientas, procedimientos, permisos, código determinista, un orquestador y mecanismos de verificación.

PowerChat me enseñó que un modelo no es un agente. OpenClaw me enseñó que el problema era la arquitectura. Agente Jiménez es el laboratorio donde intento reconstruir esa arquitectura con modelos locales y hardware corriente.

La analogía del examen sigue funcionando hasta el final: el modelo es el alumno; el contexto, los apuntes; las herramientas, la calculadora y la biblioteca; las skills, los manuales; y el orquestador, quien decide qué necesita el alumno en cada momento. La verificación comprueba que no se limitó a inventar una respuesta convincente.

La próxima vez que escribas una orden en el chat de un agente y te responda que ha buscado, abierto o comprobado algo, ya sabrás que entre esas dos frases probablemente han ocurrido muchos más pasos. Y sabrás aproximadamente quién ha hecho cada uno.