Skill vs Tool: la distinción que hace a MONO diferente

Por qué la separación importa

La mayoría de frameworks de agentes (LangChain, AutoGPT, etc.) tratan "tool" y "function" como el átomo base. El agente ve una lista plana de 50 funciones y el LLM decide cuál llamar.

Esto funciona con 5-10 tools. Se rompe con 50. El prompt se infla con descripciones repetitivas, y tools similares (log_expense vs create_transaction vs record_spending) confunden al modelo.

Skills introducen una capa de agrupación semántica. En vez de "aquí hay 83 funciones, elige una", decimos "aquí hay 21 skills; cuál(es) son relevantes?". El Haiku router elige las 1-3 skills. Después, dentro de esa skill, se expone solo el subset de tools que le pertenece.

Anatomía de un skill

Un skill en MONO contiene:

• Tools: las funciones que ejecuta (create_event, list_events, delete_event para el skill calendar).
• Manifest: archivo YAML con descripción, ejemplos de activación, condiciones de UI, boundaries.
• Renderer: función Go que convierte los resultados en Dynamic UI (HTML renderizado).
• Modos: declaración de qué modos soporta (tool/think/agent — ver post del router).
• Monitores proactivos (opcional): cron jobs que corren sin input del usuario (ej. morning brief de calendar a las 7am).

Ejemplo: el skill Expenses

Tools (6): log_expense, list_expenses, expense_summary, delete_expense, categorize_expense, analyze_expenses (agent mode).

Manifest ejemplos: "gasté 300 en uber" → log_expense. "cuánto gasté este mes?" → expense_summary. "explícame mis patrones" → analyze_expenses (agent mode).

Renderer: tabla HTML con categorías, proyección mensual, delta vs mes anterior, gráfico de barras para top-5 categorías.

Monitor: cada viernes 6pm, calcula el summary semanal y lo manda proactivamente si el usuario superó su promedio.

El LLM nunca ve los 6 tools individuales hasta que el router eligió "expenses" como skill relevante. Entonces y solo entonces se exponen en el contexto.

Consecuencias arquitectónicas

Composabilidad: agregar una skill nueva = crear un paquete Go + un YAML + un renderer. No hay que modificar el router, ni el executor, ni el sistema de UI.

Testing aislado: las tools se testean independientemente. El manifest se valida contra un schema. El renderer se prueba con fixtures de output.

Billing por skill: podemos cobrar por skills individuales (email $2/mes, calls $7/mes) porque son unidades discretas con boundaries claras.

User-facing vocabulary: los usuarios piensan en skills ("quiero activar el skill de Gastos"), no en tools. Internamente tenemos 121 tools, pero en la UI hay skills. Esa es la abstracción correcta para el producto.