Contenido detallado
🧑🍳 Skill = 1 verbo; agente = el chef
La diferencia esencial: una skill es un verbo — una tarea. En algún momento, varias skills relacionadas merecen convertirse en una entidad propia, equipada con criterio: el agente. No es una skill única; es un especialista que coordina varias skills, en el orden correcto, decidiendo cuál usar.
🌱 ¿Nuevo aquí?
Un agente es un rol: piensa en un «empleado» de tu OS, especialista en una parte del dominio. Orquestar significa elegir y activar skills en la secuencia correcta, como un chef que decide qué herramienta tomar y prueba el plato antes de servirlo. La skill es el cuchillo; el agente es quien decide cortar.
Cómo leer: el cuadro grande (morado) es el agente; los tres más pequeños (cian) son skills, cada uno un verbo. Lo que el agente agrega no es otro verbo: es la criterio de cuál llamar, cuándo y con qué revisión.
Por qué aprender
Porque confundir una skill con un agente es el error que infla el costo y la fragilidad. Si la tarea se expresa con un solo verbo, es una skill: crear un «agente» para eso es exagerado. El agente solo se justifica cuando hay varias skills que coordinar con criterio. Mantener clara esa frontera evita el antipatrón que da inicio a la Trilha 1: saltar a los agentes demasiado pronto.
Conceptos clave
🚪 El portón de revisión antes de que algo salga
Lo que hace confiable a un agente no es solo lo que hace: es el barrera de revisión (review gate) antes de que algo salga al mundo. Todo agente que produce algo que va hacia afuera (un correo electrónico, un informe, un lanzamiento) pasa por un punto de verificación: tú u otro agente revisan antes del envío.
Cómo leer: el borrador del agente no sale directamente. Pasa por la revisión (el rombo morado). «Sí» sigue hacia el mundo; «no» (rojo) vuelve al agente para que lo rehaga. Ese ciclo es lo que evita que tonterías lleguen al cliente.
💡 Quién revisa
El revisor puede ser tú (humano en el ciclo, dando el OK final) o otro agente — el revisor escéptico del tema 6. En dominios serios (dinero, asuntos legales), el filtro es obligatorio; es lo que sostiene la confianza en el agente.
Por qué aprender
Porque un agente sin barrera es un riesgo suelto. Con el review gate, ganas autonomía sin perder el control: el agente trabaja, pero nada irreversible sucede sin pasar por la revisión. Es el equivalente, en la capa de agentes, al hack de solo lectura de la capa de herramientas: seguridad desde el diseño.
Conceptos clave
🔼 Promueve solo una rutina que ya haces a mano
El criterio para decidir cuándo crear un agente es directo: convierte en agente solo una rutina que tú ya ejecuta manualmente hoy, con skills que ya existen para que lo orqueste. Es el mismo "empieza de forma manual" de la capa de skills, un nivel más arriba: el agente no es donde empiezas, sino a donde llegas.
✓ Listo para convertirse en agente
- ✓Ya haces esta rutina a mano, repetidamente.
- ✓Ya existen skills para que el agente las orqueste.
- ✓Hay una puerta de revisión clara antes del envío.
✗ Agente de teatro
- ✗Agente para algo que nunca hiciste a mano.
- ✗No hay ninguna habilidad debajo, solo una promesa.
- ✗Parece potente, pero no ofrece nada confiable.
⚠️ El error n.º 1 del curso, otra vez
La mayoría de las personas empieza por la capa de agentes, la última que debería tocar. Un agente es un "empleado" que solo tiene sentido contratar después de que hayas construido el contexto, las skills y las reglas. Sin esa base, el agente no tiene en qué apoyarse.
Por qué aprender
Porque es el freno al entusiasmo. Los agentes son la parte "divertida", y por eso la tentación de empezar por ellos es enorme. Promover solo rutinas reales, con skills listas debajo, garantiza que cada agente sea un trabajador de verdad, no un adorno que impresiona y falla.
Conceptos clave
🔀 Agente vs. workflow vs. subagentes desechables
No todo trabajo merece un "empleado" permanente. Antes de crear un agente, pregúntate: ¿realmente necesitas un agente o solo un proceso que se ejecute de vez en cuando? Una auditoría puntual de cientos de archivos quizá sea un workflow dinámico, no un agente fijo. Y cuando necesita más fuerza bruta, subes subagentes descartables.
Un rol permanente que tú «contratas». Tiene sentido para rutinas recurrentes que requieren criterio; por ejemplo, el agente de respuesta.
Un proceso puntual, creado para una tarea específica; por ejemplo, auditar cientos de archivos una sola vez. No necesita un «empleado».
Cuando necesitas mucho más firepower, lanza varios agentes throwaway para encargarse de la carga y luego descártalos.
🔎 La escala de la elección
Piensa en términos de escala: una tarea única y grande → workflow. Una rutina recurrente que requiere criterio → agente fijo. Un pico de carga que exige paralelismo → subagentes descartables. Elegir la forma adecuada evita crear un "empleado" permanente para un trabajo que ocurre una sola vez.
Por qué aprender
Porque «agente» no es la única respuesta, ni siempre la mejor. Tratar todo como un agente fijo llena el OS de roles que rara vez se ejecutan. Distinguir entre agente, workflow y sub-agentes te permite aplicar la forma adecuada a cada tarea y ahorrar contexto y mantenimiento.
Conceptos clave
🗂️ Ejemplos: agente de respuesta y de deep research
En Freedom OS, los agentes surgieron de rutinas que el autor ya hacía a mano. Muestran la capa activa: cada agente es un "empleado" con un trabajo claro, y van apareciendo otros nuevos a medida que el OS madura.
Por qué aprender — cómo aparecieron los agentes
Agente de respuesta
Tiene acceso a Gmail (vía CLI). Cuando el autor dice "revisa mi correo", consulta los mensajes de las agencias, reúne los 10 documentos correctos y redacta las respuestas — el autor solo revisa y envía (review gate).
Agente de investigación profunda
Monitorea constantemente los cambios en las leyes de pasaporte y residencia. Cuando un país cambia la legislación (p. ej., la nueva ley tributaria de Turquía), indica que conviene revisar esa ciudadanía.
Un OS vivo
Cada parte es muy intencional, con etapas de revisión. Los agentes no surgieron de una vez: se incorporaron uno a uno, a medida que se consolidaban las rutinas.
💡 El hilo conductor
Fíjate: el agente de respuesta usa una CLI (Gmail) y varias skills (buscar un documento, redactar un borrador). Solo fue posible porque las capas inferiores —contexto, skills, herramientas— ya existían. Es toda la Ruta 3 convergiendo en un agente.
Por qué aprender
Porque los ejemplos reales sacan al agente de lo abstracto. Muestran que un agente es un trabajador con un alcance claro —no una "IA mágica"— y que se apoya en las skills y herramientas que ya construiste. Es tu modelo para diseñar el primer agente de tu OS.
Conceptos clave
🛡️ Review gates: el revisor escéptico
La puerta del tema 2 recibe un nombre cuando el revisor es otro agente: el revisor escéptico (abogado del diablo). Es un agente diseñado para "regañarte antes que el contador" —o el cliente—: revisa el trabajo con una mirada adversarial antes de que salga.
✓ Con un revisor escéptico
- ✓Tu OS te hace una crítica dura antes de que el error se filtre.
- ✓Menos idas y vueltas con el contador/cliente.
- ✓El agente busca la fuente del problema antes que tú.
✗ Sin gate adversarial
- ✗El error solo aparece cuando se queja el contador.
- ✗Trabajo repetido y desgaste para quien lo recibe.
- ✗El agente «vendedor de sí mismo» no se cuestiona.
🔎 Caso real
En Tax OS, antes de enviar un ledger al contador, un revisor escéptico comprueba si hay algo extraño. En consultoría, el revisor puede asumir la voz del cliente — un agente con nombre y contacto, como referencia principal de todas las reuniones sintetizadas — y a veces quieres varios revisores adversariales, no uno solo.
Por qué aprender
Porque el revisor escéptico es lo que transforma la autonomía en confianza. Reduce la probabilidad de que un error llegue a quien importa, disminuye las interacciones tediosas (que arruinan lo que te gusta hacer) y te permite delegar de verdad. Es el punto de revisión en su forma más poderosa.
Conceptos clave
🧠 Modelos más inteligentes → menos instrucciones, quizá ningún agente
Un punto que cambia la forma en que gestionas la capa: los agentes cambian con el tiempo. A medida que los modelos se vuelven más inteligentes, el mismo agente necesita menos instrucciones para obtener el mismo resultado — o puede dejar de ser necesario, porque Claude Code o Codex ya lo hacen de forma nativa.
💡 Revisa, no acumules
Pregunta de vez en cuando: "¿este agente todavía necesita todas estas instrucciones? ¿Todavía necesita existir, ¿o el modelo ya lo resuelve por sí solo?". Tratar a los agentes como permanentes para siempre es el camino a la hinchazón; revisarlos mantiene el OS ágil.
🔎 Qué decae según el dominio
Recuerda la Trilha 1: cada capa se deteriora a un ritmo distinto. Los agentes cambian porque los modelos evolucionan; la identidad tiende a ser más estática; el contexto puede necesitar una actualización mensual. Saber qué decae (y cuándo) es parte de mantener vivo el OS.
Por qué aprender
Porque te protege de la acumulación. Si nunca vuelves a revisar los agentes, terminas con una flota de "empleados" que quizá el nuevo modelo ya no necesita. Auditar periódicamente —¿menos instrucciones? ¿sigue siendo necesario?— es lo que mantiene la capa de agentes en proporción con lo que realmente necesitas.
Conceptos clave
📄 Copy-run: el esqueleto de un AGENT.md
Hora de bosquejar tu primer agente. Un agente vive en un archivo AGENT.md (en la carpeta agents/ del OS) con partes claras: el rol, las skills que orquesta, la orden, o review gate y los límites. Copia el esqueleto de abajo y complétalo para una rutina que ya haces a mano.
Copia y completa — agents/<nome>/AGENT.md
Objetivo: esbozar un agente que orqueste las skills que ya tienes, con una puerta de revisión antes de cualquier envío.
Crea el archivo y cambia lo que está entre < >:
--- name: <nome-do-agente> role: <o funcionário que ele é, ex.: "agente de resposta de e-mail"> --- ## Quando empregar <a rotina que eu JÁ faço à mão hoje e quero delegar> ## Skills que orquestra (já existem) - /<skill-1> — <o que faz> - /<skill-2> — <o que faz> ## Ordem de operação 1. <primeiro passo> 2. <segundo passo> 3. produzir um RASCUNHO (nunca enviar direto). ## Review gate (obrigatório) - nada sai sem revisão: <eu confiro / um revisor cético confere>; - se reprovar, voltar ao passo <N> e refazer. ## Limites (never) - <ex.: nunca enviar e-mail sem meu OK>; - <ex.: só LER do CRM, nunca escrever>. ## Done-check - <como sei que o agente fez um bom trabalho>.
Cómo verificar: lee el archivo y confirma las cinco partes: rol, skills, orden, review gate y límites. Si falta el review gate o si alguna «skill» no existe realmente en tu carpeta skills/, el agente todavía no está listo: vuelve y construye la base antes.
💡 Consejo
El bloque «producir un BORRADOR (nunca enviar directamente)» + la puerta de revisión son el corazón de la seguridad. Sin ellos, tienes un agente que actúa sin freno. Empieza siempre con la puerta activada y relájala solo cuando confíes en él, nunca al revés.
Por qué aprender
Porque cierra la Ruta 3 con un artefacto tuyo. Al completar esta plantilla, reúnes las tres capas de acción —skills (3.1), herramientas (3.2) y agentes (3.3)— en un solo documento con criterio y revisión. Desde aquí sigues a la Ruta 4, donde el /os-coach construye todo esto contigo, capa por capa.
Conceptos clave
✅ Resumen del módulo
Siguiente ruta:
Ruta 4 — Paso a paso: construye tu OS con /os-coach 🛠️