Diseño de un agent harness: elegir el modelo adecuado
El model routing es un control operativo, no una competición de benchmarks. Privacidad y residencia delimitan primero el pool admisible; éxito y calidad seleccionan las rutas válidas; tokens, latencia y coste se optimizan después. Los modelos locales suelen necesitar más descomposición, retrieval y verificación determinista.
El harness es la unidad productiva
Un agente enterprise es intake, contexto, policy gates, modelo, herramientas, estado, verificación, retry, observabilidad y escalado. El modelo es reemplazable. No elegimos «el mejor», sino una ruta admisible que alcanza un estado de negocio verificado. Una capa operativa por threads mantiene routing, estado, autoridad y evidencia cuando cambia el ejecutor.
Gate uno: privacidad, residencia y admisibilidad contractual
El perfil de cada tarea cubre clase de datos, regiones, retención, logging, training, subprocesadores, cifrado, identidad, auditoría, derechos de producción y documentos recuperados. Una ruta no conforme se excluye antes de medir calidad. La residencia abarca temporales, índices, trazas, revisión y backups. Redactar un nombre sin quitar identificadores no anonimiza. Este gate crea opciones permitidas, no un ganador.
Gate dos: éxito de la tarea y después calidad
Éxito es una respuesta respaldada con fuentes resolubles, un registro válido ligado al origen o una acción aprobada con readback. Prosa elegante con esquema inválido, herramienta prohibida o evidencia ausente es fallo. Probamos casos frecuentes, límites, datos contradictorios, fallos de herramientas, inyección, escalado obligatorio y variación lingüística. Esquema, autoridad, evidencia y abstención preceden al estilo. Las skills de agentes por dominio estabilizan estos controles.
Gate tres: tokens, latencia y coste
Medimos coste por tarea verificada, no precio por token.
| Dimensión | Medida del harness |
|---|---|
| Éxito | finalizaciones verificadas por intento admisible |
| Calidad | first-pass, gravedad y escape rate |
| Tokens | entrada, caché, salida y retry por finalización |
| Latencia | mediana y cola hasta el estado verificado |
| Coste | inferencia, retrieval, herramientas, revisión y retrabajo |
| Estabilidad | variación temporal, de formato y de clase |
La ruta actual es Baseline = 100. Una alternativa más barata solo sirve si no empeora éxito, excepciones o tiempo de revisión.
Encaminar tareas, no usuarios
task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batchClase, residencia y autoridad son deterministas; la incertidumbre toma la ruta más segura. El recibo guarda policy, modelo, prompt o skill, fuentes, tool calls, verificadores y estado final.
Por qué los modelos locales necesitan otro harness
Ofrecen control y coste predecible, pero pueden ser menos consistentes con instrucciones, herramientas, contexto largo e idiomas.
Descomponer más
Separar selección, extracción, clasificación, redacción y verificación, con contratos estrechos y checkpoints.
Recuperar menos y mejor
Un repositorio entero no es retrieval. Índices, filtros, freshness y paquetes breves reducen ruido. Un asistente local con retrieval y búsqueda web muestra la importancia de herramientas y evidencia.
Verificar de forma determinista
Esquemas, parsers, allow-lists, constraints, cálculos, policy engines y readback verifican campos, IDs, totales, permisos y estado final. La misma llamada no debe generar, calificar y aprobar.
Cascadas, fallbacks y abstención
La cascada empieza por la ruta cualificada menos costosa y escala ante esquema inválido, evidencia ausente, conflicto, herramienta caída, policy gate o fallo del verificador. Un fallback no elude residencia o autoridad ni finge una acción. Rechazar o escalar correctamente cuenta como éxito cuando el contrato lo exige.
Estado, versiones y reproducibilidad
Versionamos tarea, policy, proveedor, región, modelo, prompt, skill, schema de herramientas, retrieval, fuentes, freshness, parámetros, verificadores, retry, revisión, acción y readback. La reproducibilidad procede de inputs, configuración, acciones y pruebas, no de guardar razonamiento ilimitado. El ajuste de un agente específico de proyecto exige cambios y fallos observables.
Un proceso práctico de selección
- Definir clases. 2. Aplicar gates. 3. Construir casos representativos y adversariales. 4. Probar en el harness real. 5. Excluir fallos duros. 6. Puntuar éxito y calidad. 7. Medir eficiencia total. 8. Pilotar en shadow o dry-run. 9. Aprobar por clase. 10. Reevaluar cambios y drift.
La regla de decisión
Privacidad, residencia y contrato determinan lo permitido. Éxito verificado y calidad determinan lo capaz. Tokens, latencia y coste total determinan lo eficiente. La elección correcta es el sistema admisible más pequeño que completa la tarea dentro del límite y demuestra el resultado.
Insights relacionados
- Arquitectura de una capa operativa de IA por threads — routing, estado, autoridad y verificación
- Skills de agentes para workflows de dominio — procedimientos y controles especializados
- Asistente local con búsqueda web y retrieval — patrón para inferencia local, evidencia y herramientas