Cómo diseñar un agente con presupuesto de herramientas y contexto

Inventaría intenciones antes de herramientas. Recoge veinte tareas reales y agrúpalas por finalidad. Para cada una define entrada, salida y consecuencia. No comiences copiando todas las APIs. La intención establece qué necesita el agente y qué acciones deben quedar fuera o pedir aclaración. Este paso fija el alcance de un agente de producto que debe elegir herramientas y contexto para cada intención. Define responsable, entorno y criterio de aceptación. La decisión autorizar producción solo cuando selección, límites y readback sean reproducibles debe demostrarse mediante intención, subconjunto, esquema, contexto, llamada, aprobación, costo, resultado, error y lectura posterior; evita verbos amplios que no indiquen qué se probará, permitirá, bloqueará o remitirá a una persona con autoridad.

Elimina dependencias de la interfaz. Reemplaza herramientas que dependen de una pestaña o panel por lecturas con esquema. Documenta relaciones e identificadores. Si una función solo puede operar sobre estado visual, decláralo y evita presentarla como acceso directo a datos o capacidad general del agente. Incluye casos comunes, extremos y fallidos. Prueba herramientas duplicadas, estados de interfaz, documentación antigua y tareas que mezclan finalidades de manera controlada y registra exclusiones. Un resultado positivo no cubre aquello que nunca formó parte de la muestra. La seguridad del método depende tanto de sus límites como de la precisión observada.

Crea conjuntos por tarea. Asigna a cada intención un conjunto mínimo y una política de selección. Añade ruta de insuficiencia. Prueba que una tarea no pueda invocar herramientas de otra finalidad sin nueva autorización. Versiona reglas junto con el producto y su documentación. Usa permisos mínimos y separa preparación, aprobación y ejecución. El objetivo es un agente con superficie pequeña, contexto suficiente y acciones observables. Una sola identidad o credencial no debe acumular acciones con consecuencias distintas solo por comodidad. Diseña confirmación, readback y reversión antes de exponer el piloto a usuarios reales.

Presupuesta el contexto explícitamente. Divide contexto estable, sesión, usuario y tarea. Decide qué se cachea, resume o vuelve a consultar. Registra omisiones. El límite debe proteger datos y mantener señal. Un contador de tokens solo informa tamaño; la prueba confirma si permaneció la evidencia necesaria. Conecta cada métrica con una decisión. Para un agente de producto que debe elegir herramientas y contexto para cada intención, conserva intención, subconjunto, esquema, contexto, llamada, aprobación, costo, resultado, error y lectura posterior. Añade una señal de daño, un umbral máximo y una persona que pueda detener el ensayo. Mejorar tiempo o volumen no compensa automáticamente exposición, inequidad, errores o pérdida de trazabilidad.

Prueba elección y efecto. Crea casos correctos, ambiguos y adversariales. Mide herramienta elegida, llamadas inútiles, costo y resultado. Para escrituras, muestra plan, solicita aprobación específica y relee el destino. Un código de éxito sin readback no prueba que el estado final sea correcto. Ensaya timeout, respuesta ambigua, cambio de datos y revocación. Antes de repetir, relee el destino y evita duplicados. Comprueba herramientas duplicadas, estados de interfaz, documentación antigua y tareas que mezclan finalidades. Otra persona debe poder reconstruir la secuencia usando registros sin depender de la memoria de quien ejecutó la prueba.

Publica por oleadas con regresión. Empieza con lectura y una tarea reversible. Expande una herramienta a la vez. Ejecuta regresión cuando cambie modelo, esquema o política. Documenta go, revise o stop y conserva métricas que permitan retirar funciones cuya complejidad supera el valor. Cierra con go, revise o stop y documenta la razón. un agente con superficie pequeña, contexto suficiente y acciones observables existe solo si el estado real coincide con el solicitado y el equipo conoce pendientes, propietario y fecha de revisión. La guía se convierte así en un control que puede repetirse cuando cambian las condiciones.