Pi.dev y la idea clave: tu propio harness para agentes de IA

Hay una frase en Pi.dev que resume muy bien hacia dónde se está moviendo la ingeniería con agentes:

“There are many agent harnesses, but this one is yours.”

La traducción práctica sería simple: hay muchos entornos para correr agentes de IA, pero el que realmente importa es el que puedes adaptar a tu propia forma de trabajar.

Ese matiz es más importante de lo que parece.

Durante los últimos años, gran parte de la conversación sobre IA se concentró en modelos: cuál responde mejor, cuál programa más rápido, cuál cuesta menos, cuál tiene más contexto. Todo eso importa. Pero cuando empiezas a usar agentes en trabajo real, aparece otra pregunta mucho más concreta:

¿Dónde vive el agente y cómo se conecta con tu workflow?

Ahí entra el concepto de harness.

Qué es un harness de agentes

Un harness es la capa que envuelve al modelo y lo convierte en una herramienta operativa.

No es solo una interfaz bonita. No es solo un chat. No es solo un CLI.

Es el entorno que define:

• qué herramientas puede usar el agente
• qué contexto recibe
• cómo ejecuta comandos
• cómo maneja sesiones
• cómo se conecta con archivos, repositorios y APIs
• qué permisos tiene
• cómo se extiende
• cómo se integra con el trabajo diario

El modelo es el motor.

El harness es el chasis, el tablero, los controles, la memoria operativa y las conexiones con el mundo real.

Por eso dos personas pueden usar el mismo modelo y obtener resultados completamente distintos. La diferencia no siempre está en el LLM. Muchas veces está en el harness.

Pi.dev apunta a una idea correcta

Pi se presenta como un minimal terminal coding harness.

La gracia no está en prometer otra interfaz cerrada para “hacer coding con IA”. La gracia está en el enfoque: mantener un core pequeño y permitir que el usuario lo extienda con piezas propias.

Desde lo que muestra su documentación, Pi se apoya en varias ideas interesantes:

• extensiones en TypeScript
• skills cargables bajo demanda
• prompt templates reutilizables
• themes y paquetes compartibles
• modos interactivo, print/JSON, RPC y SDK
• sesiones estructuradas
• configuración de proveedores y modelos
• control del contexto mediante instrucciones, compaction y extensiones

Ese set de primitivas dice algo importante: el producto no intenta decidir todo por ti.

Te entrega una base para construir encima.

Y eso es exactamente lo que necesitan muchos operadores técnicos, founders, builders y equipos que ya tienen una forma particular de trabajar.

El cambio: de usar agentes a diseñar sistemas de agentes

Usar un agente genérico es fácil.

Diseñar un sistema de agentes útil es otra cosa.

Cuando trabajas de verdad con IA, rápidamente aparecen necesidades que un producto cerrado no siempre resuelve bien:

• quieres que el agente entienda convenciones de tu proyecto
• quieres cargar instrucciones solo cuando hacen falta
• quieres reducir ruido del contexto
• quieres conectar herramientas internas
• quieres automatizar flujos repetibles
• quieres que el historial sea navegable
• quieres controlar permisos y comportamiento
• quieres que el output tenga tu estilo

Eso ya no es “prompt engineering”.

Eso es context engineering y arquitectura de operación.

Pi.dev es interesante porque conversa con esa capa. No solo con el modelo.

Por qué “propio” importa

La palabra clave es propio.

Un harness propio no significa necesariamente escribir todo desde cero. Significa que el sistema se adapta a ti, no al revés.

En la práctica, eso puede verse así:

• un agente que entiende tu repositorio y tus estándares
• comandos propios para tareas frecuentes
• skills para workflows específicos
• plantillas para posts, documentación, bugs o análisis
• integración con tus herramientas reales
• una forma de guardar, resumir y reutilizar contexto
• una salida alineada con tu tono y tus objetivos

Para una empresa, esto puede ser la diferencia entre “tenemos acceso a ChatGPT” y “tenemos una capa operativa de IA integrada a cómo trabajamos”.

Para una persona, puede ser la diferencia entre consultar IA ocasionalmente y tener un sistema que multiplica su throughput diario.

El riesgo de quedarse solo con interfaces cerradas

Las interfaces cerradas tienen valor. Son simples, cómodas y reducen fricción inicial.

Pero también tienen un techo.

Cuando todo vive dentro de una UI rígida, cuesta adaptar el agente a flujos más complejos. Cuesta integrarlo con herramientas internas. Cuesta controlar el contexto. Cuesta construir memoria útil. Cuesta convertirlo en una ventaja operacional específica.

El futuro no va a ser un único asistente universal haciendo todo igual para todos.

Va a ser una mezcla de modelos fuertes con harnesses personalizados, herramientas internas, memoria contextual y workflows específicos.

La ventaja no estará solo en “tener IA”.

La ventaja estará en cómo la operas.

Mi lectura

Pi.dev representa una señal sana dentro del ecosistema: volver a las primitivas.

Menos magia cerrada.

Más control.

Más extensibilidad.

Más capacidad de adaptar el agente al entorno real donde trabajas.

Eso conecta con una tesis que cada vez me parece más clara: los profesionales y equipos más productivos no van a usar IA solo como chat. Van a construir su propio entorno operativo alrededor de agentes.

Algunos usarán Pi. Otros usarán Hermes, OpenCode, Codex, Claude Code, herramientas internas o mezclas propias.

La herramienta específica puede cambiar.

La dirección es la misma:

el harness se vuelve parte de la ventaja competitiva.

Porque al final, un modelo responde.

Pero un buen harness convierte esa inteligencia en trabajo ejecutable.

Y ahí empieza lo interesante.