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 Fitness"), no en tools. Internamente tenemos ~83 tools, pero en la UI hay 21 skills. Esa es la abstracción correcta para el producto.