De 50 herramientas a 3 canales de escritura
Abril 2026
Cuando construí Osistan por primera vez — un asistente de operaciones de IA para mi equipo — le di 50 herramientas. Podía consultar bases de datos, enviar mensajes de Slack, crear tareas, actualizar wikis, recuperar correos, generar informes y mucho más. Cada capacidad que se me ocurrió, la expuse como una herramienta.
El LLM gastaba la mayor parte de su inteligencia eligiendo qué herramienta llamar.
El problema
Con 50 herramientas en el system prompt, el modelo hacía dos trabajos a la vez: entender qué necesitaba el usuario y navegar un laberinto complejo de selección de herramientas. El resultado era predecible — elegía la herramienta equivocada, llamaba herramientas innecesariamente, o encadenaba múltiples cuando una era suficiente.
El costo no era solo de precisión. Cada herramienta tenía su propio esquema de parámetros, lógica de validación y manejo de errores. El código base creció. Depurar se volvió más difícil. Agregar una nueva capacidad significaba agregar otra herramienta, otro esquema, otro conjunto de casos extremos.
La intuición
Me di cuenta de que el LLM no necesitaba 50 formas de actuar sobre el mundo. Necesitaba pensar con claridad y luego expresar su intención a través de una interfaz mínima.
La analogía que me hizo clic: un operador humano no necesita 50 botones. Necesita un teclado. El teclado es de propósito general — lo que importa es qué escribes.
Tres canales de escritura
Reduje toda la superficie de herramientas a tres canales:
db_write(entity, operation, data) — Todas las mutaciones de base de datos. Tareas, páginas wiki, entradas de base de conocimiento, recordatorios. Los campos entity y operation determinan qué ocurre. El LLM no necesita conocer el esquema de la base de datos — expresa intención, y una capa determinista la enruta.
slack_send(target, message, blocks) — Toda la comunicación. DMs, mensajes de canal, respuestas en hilos, reacciones. Un canal, flexible para todo.
file_create(filename, content) — Informes, exportaciones, documentos generados.
Todo lo demás — cron jobs, parsing de correos, cálculos de plazos, recuperación de datos — corre en una capa determinista que no involucra al LLM en absoluto.
Qué cambió
El LLM dejó de ser un motor de selección de herramientas y empezó a ser un motor de pensamiento. La calidad de las respuestas mejoró de inmediato. El modelo podía enfocar su ventana de contexto completa en entender la solicitud del usuario y formular una respuesta bien pensada, en lugar de navegar un laberinto de herramientas.
Depurar se volvió directo. Cada acción del LLM pasa por uno de tres canales, así que cada efecto secundario es trazable. La capa determinista maneja toda la recuperación de datos y el cálculo, así que no hay alucinaciones sobre datos que no existen.
El costo también bajó — menos tokens gastados en esquemas de herramientas en el system prompt, menos reintentos por selección incorrecta de herramientas.
La conclusión
Más herramientas no significa más capacidad. Significa más confusión para el modelo y más complejidad para ti. La abstracción correcta es la que deja al LLM enfocarse en lo que hace bien — entender intención y generar output estructurado — mientras mantiene todo lo demás determinista.
Osistan ahora corre 24/7 en una Raspberry Pi 5, sirviendo a un equipo de 8 por ~$40/mes. La arquitectura de 3 canales es la razón por la que es suficientemente confiable para producción.