Pi Agent propone una alternativa a los agentes de programación que han ido acumulando funciones, herramientas y automatizaciones. Su planteamiento parte de una idea sencilla: mantener pequeño el núcleo del agente, hacer visible el contexto que recibe el modelo y permitir que cada desarrollador añada únicamente las capacidades que necesita mediante extensiones, habilidades y plantillas.
El proyecto, desarrollado por Mario Zechner y publicado como código abierto, ha ganado una comunidad relevante en GitHub. Su diseño gira alrededor de cuatro herramientas básicas, un sistema de instrucciones reducido y una arquitectura extensible que permite añadir desde subagentes y modos de planificación hasta integraciones con MCP (Model Context Protocol) o controles personalizados de permisos.
Las claves de Pi Agent en 30 segundos
- Pi reduce el núcleo del agente a unas pocas herramientas y mantiene el prompt del sistema por debajo de 1.000 tokens.
- Las sesiones se almacenan como archivos JSONL con estructura de árbol, lo que permite recuperar puntos anteriores y crear nuevas ramas.
- El modelo puede cambiarse durante una misma sesión sin perder el contexto de trabajo.
- Extensiones, Skills y plantillas permiten añadir funciones que otros agentes incorporan directamente en su núcleo.
- El proyecto no incluye un sandbox propio: el aislamiento debe proporcionarlo el sistema operativo, un contenedor o una máquina virtual.
El planteamiento responde a una preocupación que está ganando peso entre quienes utilizan agentes de programación a diario: qué está haciendo realmente el agente y qué información recibe el modelo antes de cada petición.
Herramientas como Claude Code, Codex u OpenCode han ido incorporando subagentes, ejecución en segundo plano, MCP, modos de planificación y otras funciones. Estas capacidades pueden simplificar determinadas tareas, pero también añaden componentes que el usuario no siempre ve directamente.
Pi toma el camino contrario. En lugar de incorporar todas esas funciones al núcleo, las deja fuera y proporciona mecanismos para añadirlas cuando sean necesarias.
Un agente que intenta mantener visible el contexto
Una de las decisiones centrales de Pi está relacionada con el prompt y las herramientas disponibles para el modelo.
El proyecto limita el prompt del sistema a menos de 1.000 tokens y expone su contenido. La idea es reducir la cantidad de instrucciones que aparecen automáticamente en el contexto y permitir que el desarrollador tenga una visión más clara de lo que está recibiendo el modelo.
El autor también cuestiona el coste de cargar definiciones de herramientas de MCP de forma permanente. Según el análisis publicado por Zechner, algunas integraciones pueden introducir decenas de herramientas y consumir miles de tokens antes incluso de comenzar una tarea.
La alternativa que plantea Pi consiste en utilizar herramientas de línea de comandos y cargar instrucciones adicionales solo cuando hacen falta. Las Skills siguen esta filosofía: son archivos SKILL.md que describen procedimientos y pueden incorporarse al contexto cuando la tarea los necesita.
El objetivo no es eliminar las extensiones, sino trasladar la decisión al usuario.
Subagentes visibles en lugar de procesos ocultos
El mismo principio se aplica a los subagentes.
En lugar de ejecutar agentes secundarios y presentar únicamente un resumen de su trabajo, Pi puede utilizar sesiones independientes que se muestran mediante tmux. De esta manera, el usuario puede observar las interacciones de los distintos agentes.
Es una diferencia de diseño más que una cuestión de capacidad. Pi no pretende que el agente tenga menos posibilidades, sino que esas posibilidades no tengan que formar parte obligatoriamente del núcleo.
La inspiración procede, según el material de partida, de Terminus, un harness utilizado en pruebas de agentes de terminal. Su propuesta era especialmente sencilla: proporcionar al modelo una herramienta para interactuar con una sesión de tmux, obligándolo a trabajar con entradas de teclado y las secuencias ANSI que devuelve el terminal.
Para Pi, ese tipo de experiencia sirve como demostración de que los modelos actuales pueden trabajar con un entorno de programación sin necesitar necesariamente una capa enorme de abstracción.
Cambiar de modelo sin abandonar la sesión
Una de las funciones más interesantes para desarrolladores es la posibilidad de cambiar de proveedor durante una misma sesión.
El contexto de Pi se serializa en un formato independiente del proveedor. Por eso, según la documentación descrita en el material, una sesión iniciada con Anthropic puede continuar posteriormente con un modelo de OpenAI o Google sin tener que comenzar desde cero.
El cambio puede realizarse mediante /model o Ctrl+L.
Pi también unifica la forma de expresar los niveles de razonamiento. Capacidades que cada proveedor denomina de manera diferente, como el extended thinking de Anthropic o los niveles de razonamiento de OpenAI, se presentan mediante una escala común de cinco niveles, desde minimal hasta xhigh.
El proyecto admite más de 15 proveedores y permite añadir proveedores personalizados mediante ~/.pi/agent/models.json. También puede conectarse a servidores compatibles con las API de OpenAI o Anthropic y a modelos locales mediante sistemas como llama.cpp.
Esta arquitectura reduce la dependencia de un proveedor concreto y permite cambiar de modelo dentro del mismo flujo de trabajo.
Las sesiones funcionan como un árbol
Pi utiliza JSONL (JSON Lines) para almacenar las sesiones. Cada entrada dispone de un identificador y un parentId, creando una estructura de árbol.
La diferencia respecto a una conversación lineal aparece cuando el desarrollador quiere recuperar una decisión anterior. Con /tree puede regresar a un punto concreto de la sesión y continuar desde allí mediante una nueva rama.
El sistema mantiene el historial completo en el archivo, mientras que /compact permite resumir mensajes antiguos para reducir el contexto activo. La compactación automática también puede intervenir cuando el contexto alcanza su límite.
La separación resulta sencilla: el historial conserva lo que ha ocurrido y archivos como AGENTS.md o CLAUDE.md pueden almacenar instrucciones y convenciones que deben mantenerse presentes en un proyecto.
Las funciones avanzadas se añaden como extensiones
Pi está construido para que buena parte de las funciones que otros agentes incluyen de serie puedan incorporarse posteriormente.
Las Extensions están escritas en TypeScript y pueden añadir herramientas, comandos, accesos directos, elementos de interfaz y eventos. También pueden interceptar llamadas a herramientas.
Eso permite crear, por ejemplo, una extensión que bloquee comandos potencialmente destructivos o que solicite confirmación antes de ejecutarlos. También se pueden desarrollar sistemas propios de checkpoints de Git, commits automáticos, subagentes, modos de planificación o integración con servidores MCP.
Por encima están las Skills, escritas en Markdown y compatibles con el estándar Agent Skills, y las Prompt Templates, que permiten guardar instrucciones reutilizables.
Los paquetes pueden distribuirse mediante npm o Git y gestionarse desde el propio agente con comandos como pi install, pi list y pi update.
La consecuencia es que dos instalaciones de Pi pueden tener capacidades muy diferentes aunque utilicen el mismo núcleo.
Pi Web lleva las sesiones al navegador
El proyecto también dispone de una interfaz web denominada Pi Web. Según el material analizado, permite consultar, reanudar, renombrar y eliminar sesiones, además de crear ramas desde conversaciones existentes.
La interfaz puede mostrar archivos del proyecto y diferencias de Git, cambiar entre worktrees y gestionar proveedores, modelos, paquetes y Skills.
Al compartir la configuración y los archivos de sesión con la versión de terminal, el navegador funciona como otra interfaz sobre el mismo entorno de trabajo.
La seguridad depende del entorno de ejecución
Hay una diferencia importante frente a algunas propuestas que integran mecanismos de aislamiento: Pi no incorpora un sandbox propio.
Las operaciones de lectura, escritura, edición y ejecución de comandos utilizan los permisos del usuario que inicia el agente. Las extensiones tienen igualmente esos privilegios.
El proyecto plantea que el aislamiento real debe realizarse mediante mecanismos del sistema operativo, contenedores o máquinas virtuales. Para repositorios que no son de confianza y ejecuciones sin supervisión, el material recomienda utilizar un entorno aislado.
Pi también dispone de un mecanismo de project trust que pide confirmación ante proyectos no verificados antes de permitir determinadas modificaciones de configuración. Sin embargo, esta protección no elimina por completo el riesgo de prompt injection.
Esa decisión encaja con la filosofía general del proyecto: mantener pequeño el agente y trasladar determinadas responsabilidades al entorno donde se ejecuta.
Pi Agent no elimina las funciones que ofrecen otros agentes de programación. Las coloca en otro nivel. El núcleo se mantiene reducido y las capacidades adicionales pasan a ser componentes que el desarrollador puede instalar, escribir o retirar según sus necesidades.
Para quienes trabajan con agentes de código y quieren saber con mayor precisión qué herramientas, instrucciones y contexto participan en cada ejecución, ese diseño ofrece una alternativa concreta al modelo de agente cada vez más automatizado. Su principal apuesta no es añadir otra función a la lista, sino hacer que el usuario tenga más control sobre qué entra en ella.
Preguntas frecuentes
¿Qué es Pi Agent?
Pi es un agente de programación orientado a terminal cuyo diseño mantiene reducido el núcleo y permite ampliar sus capacidades mediante extensiones, Skills y plantillas.
¿Se puede cambiar de modelo durante una sesión?
Sí. Pi utiliza un formato de contexto independiente del proveedor y permite cambiar de modelo mediante /model o Ctrl+L sin abandonar la sesión.
¿Cómo guarda Pi las sesiones?
Las sesiones se almacenan en archivos JSONL con identificadores y relaciones parentId. Esta estructura permite utilizar /tree para volver a puntos anteriores y crear nuevas ramas.
¿Pi tiene un sandbox integrado?
No. Las herramientas se ejecutan con los permisos del usuario. Para aislar código no confiable, el proyecto plantea utilizar mecanismos externos como contenedores o máquinas virtuales.
