Qué construir y cuándo no

Tres cosas, una por pregunta. Quién lo usa decide el camino y los permisos: cuántas aplicaciones y equipos lo consumirán y de qué credencial salen el rol y el inquilino. Qué decide el modelo decide la primitiva: el modelo elige las tools, el host pide los resources y una persona elige los prompts. Qué pasa si se equivoca decide los controles: una lectura devuelve un error que el modelo corrige, una acción con efecto necesita aprobación y validación en el servidor, y lo que no se puede contener no se expone. Con esas respuestas por escrito, el código que genere la IA se puede revisar.

Cuando ya hay un servidor que hace lo que necesitas y alguien responde de él: entonces el trabajo es configuración en cada cliente, y los permisos, el filtro por inquilino y la auditoría siguen donde estaban. Escribir otro para lo mismo vuelve a crear implementaciones duplicadas con comportamientos distintos. Si no existe y solo lo usa una aplicación, el function calling dentro de esa aplicación es más simple; si lo usarán varias aplicaciones o un equipo que no lo mantiene, toca un servidor propio, aunque lo genere una IA.

Debe decir para quién es, qué tools, resources y prompts expone con sus nombres, argumentos, anotaciones y qué no hace cada uno, qué capacidades se descartan y por qué, las reglas que no se negocian (inquilino, auditoría, salida elegida campo a campo) y la pila con versiones del SDK. La otra mitad son las comprobaciones, escritas antes de recibir el código: casos que se ejecutan y dan sí o no, como un identificador mal formado o un pedido de otro inquilino. Cuando una falla, la corrección se añade al encargo y se repiten todas.