Diseño del mecanismo para el agente: política, aislamiento en sandbox, memoria y verificación
Aprende qué capas de tiempo de ejecución convierten a un LLM que llama a herramientas en un agente fiable: política de ejecución, aislamiento en sandbox del sistema operativo, estado persistente, verificación, control de contexto y costo.
Fuentes: Agent Harness Engineering: The Missing Layer Between an LLM and a Real AI Agent
Los equipos que se proponen crear un agente de IA suelen comenzar comparando modelos: tamaños de la ventana de contexto, puntuaciones en pruebas de referencia, calidad del razonamiento y precio por token. Una vez elegido un modelo, se integran algunos herramientas, y el resultado se denomina agente. Lo que realmente existe en ese momento es un modelo capaz de llamar a funciones, y la brecha entre esto y un agente listo para su uso en producción se cubre con una capa de ejecución comúnmente llamada agent harness. Esta guía explica las capas de dicho framework, de qué te protege cada una y cómo desarrollarlo de forma gradual sin quedar abrumado por las abstracciones del framework.
Un modelo que llama a herramientas aún no es un agente
El conjunto básico típico consiste en una breve lista de capacidades que se exponen al modelo.
search()
read_file()
write_file()
run_command()
Con esas cuatro funciones, el modelo puede buscar, leer, escribir y ejecutar comandos. Eso parece autonomía, pero en esta configuración nada determina qué puede tocar el modelo, qué operaciones requieren la aprobación humana, qué información sobrevive a una caída o reinicio, cómo se verifica la salida o cuánto de los resultados de cada herramienta se vuelve a incluir en el prompt. Todas esas responsabilidades corresponden al sistema de soporte.
El sistema de soporte resulta también ser una variable medible. En el momento de redactar esto, un estudio de 2026 que comparó sistemas de soporte para agentes de programación reportó diferencias de hasta 40 veces en los tokens utilizados por tarea resuelta, mientras que las diferencias en la tasa de éxito entre los mismos sistemas eran mucho menores. La conclusión no es que un entorno de ejecución inteligente haga brillante a un modelo débil, sino que dicho entorno influye significativamente en la eficiencia, seguridad y previsibilidad con las que un modelo capaz realiza su trabajo.
El bucle en el centro y las preguntas que lo rodean
Simplificado a sus elementos esenciales, un agente es un bucle: se le pregunta al modelo qué hacer, se ejecuta la herramienta solicitada, el resultado se agrega al contexto y se repite hasta que el modelo indica que ha terminado.
while True:
response = model(context)
if response.is_final:
break
result = execute_tool(response.tool_call)
context.append(result)
Muchos agentes reales tienen algo muy similar en su núcleo. El modelo toma una decisión, el entorno de ejecución la lleva a cabo, las observaciones vuelven y el modelo elige el siguiente paso. El bucle en sí es trivial; el esfuerzo de ingeniería radica en todo lo que lo rodea. Un sistema utilizable debe responder a una larga lista de preguntas operativas en cada turno.
Can the agent execute this command?
Can it access this directory?
Does it need human approval?
What happens if the command fails?
What information should return to the model?
What should survive the session?
Should another agent review the result?
How much context should we send?
How much will this turn cost?
What happens if the model loops forever?
Juntos, esas respuestas constituyen el “harness”. Un artículo conceptual reciente lo describe como el entorno de ejecución que conecta un modelo de lenguaje con el mundo exterior a través de herramientas, gestión de contexto, controles de seguridad, orquestación y puntos de extensión. Una forma útil de visualizarlo es dividir al agente en dos partes.
AI Agent
│
┌────────┴────────┐
│ │
Model Harness
│ │
reasoning ┌──────┼───────┐
planning │ │ │
generation Tools Memory Safety
│ │ │
Sandbox Context Verification
Por un lado, el modelo proporciona razonamiento, planificación y generación. Por otro lado, el “harness” ofrece herramientas, memoria y mecanismos de seguridad, respaldados por un entorno aislado, manejo de contexto y verificación. El modelo aporta inteligencia; el “harness” regula cómo esa inteligencia interactúa con los sistemas reales.
Por qué un prompt no puede ser su mecanismo de seguridad
Supongamos que el prompt del sistema contiene una regla clara:
Nunca elimine un archivo de producción sin preguntarme primero.
No hay nada ambiguo en esa oración, sin embargo sigue siendo una solicitud. El modelo podría interpretarla erróneamente, perderla de vista en una sesión larga, sopesarla frente a instrucciones contradictorias en otras partes del contexto, convencerse de que el caso actual es una excepción, o obtener el mismo resultado negativo mediante una herramienta diferente que la regla no cubría explícitamente. Pedirle a un agente que evite algo es fundamentalmente diferente de hacer esa acción imposible sin autorización. Un prompt expresa un deseo:
Please don't do X.
Un arnés puede expresar una regla que se evalúa en código:
if dangerous_action and not approved:
deny()
La segunda versión funciona independientemente de si el modelo recuerda la instrucción. Eso resume el primer principio de la ingeniería de harness: siempre que una regla sea determinista, implementarla en código determinista. Claude Code sigue el mismo enfoque en su diseño. Los hooks se ejecutan durante eventos de ciclo de vida y llamadas a herramientas, y pueden, por ejemplo, rechazar una llamada a herramienta antes de que se ejecute, mientras que archivos como CLAUDE.md proporcionan orientaciones que el modelo lee como contexto. Si estás escribiendo un archivo de este tipo, guárdalo únicamente como referencia y lleva la aplicación de reglas a los hooks; nuestro guía para crear un CLAUDE.md efectivo explica qué debe incluirse allí.
Capa 1: un límite de ejecución entre la solicitud y la acción
La primera cuestión que debe resolver el sistema es determinar qué acciones puede realizar el agente. Considere una herramienta que elimina un archivo.
def delete_file(path):
os.remove(path)
El modelo puede invocarla con cualquier argumento que desee.
delete_file("important.md")
Si esa llamada se ejecuta de inmediato, el modelo tiene autoridad ilimitada sobre todo aquello a lo que pueda acceder la función. La solución es enrutar cada llamada a través de un controlador que verifique la política antes de enviarla.
def execute(call):
if call.name == "delete_file":
if not call.args.get("human_approved"):
return "DENIED: human approval required"
return dispatch(call)
Ahora el modelo aún puede solicitar la eliminación, pero solicitarla ya no equivale a llevarla a cabo. El flujo se convierte en una decisión basada en la política con dos resultados posibles.
Model decision
↓
Policy check
↓
Permission?
↙ ↘
No Yes
↓ ↓
Deny Execute
Esto refleja un diseño de seguridad convencional: el modelo propone y el tiempo de ejecución se encarga de ello. Un detalle que merece ser reforzado en el código real es la fuente de la aprobación. En el boceto anterior, la bandera de aprobación se obtiene de los propios argumentos de la llamada, que genera el modelo. Un sistema en producción debería obtener la aprobación de forma independiente, mediante un paso de confirmación humana o un token firmado que el modelo no pueda fabricar, de lo contrario el modelo podría simplemente establecer la bandera por sí mismo.
Por qué las verificaciones a nivel de herramienta fallan
Las políticas de las herramientas son necesarias pero no suficientes. Imagina que el sistema rechaza esta llamada:
delete_file("secrets/api_key")
Eso parece protección, hasta que el agente ejecuta en su lugar la orden de shell equivalente:
rm secrets/api_key
La política delete_file nunca detecta esa operación. O bien el sistema bloquea la lectura de la ruta secreta:
read("secrets/api_key")
Pero una ruta relativa logra pasar desapercibida porque nadie la normalizó:
read("../secrets/api_key")
Los enlaces simbólicos, los programas auxiliares que abren archivos en nombre del agente y los intérpretes que aceptan código arbitrario crean todas puertas traseras similares. Una política expresada en términos de nombres de herramientas y argumentos de cadena no puede enumerar todas las rutas hacia un recurso, por lo que no constituye una barrera de seguridad completa. La guía de OpenAI para ejecutar agentes de programación recomienda combinar el aislamiento en sandbox, políticas de aprobación, ejecución restringida, controles de red y telemetría en lugar de depender únicamente de los prompts. Principio a mantener: el mecanismo de control aplica la política, mientras que el sistema operativo establece la barrera final.
Nivel 2: Aislamiento de lo que el agente puede acceder físicamente
La política determina qué acciones está permitido realizar al agente; un entorno aislado, en cambio, determina qué recursos puede acceder primero. El enfoque deficiente consiste en una lista de denegaciones que intenta enumerar cada ubicación sensible.
Don't access:
- /etc
- ~/.ssh
- secrets/
- production/
- credentials/
- ...
Tales listas nunca se completan. El enfoque más sólido invierte la lógica por defecto: no se concede casi nada, y luego se agrega exactamente lo que necesita la tarea, como un único espacio de trabajo del proyecto.
Agent workspace:
/workspace
├── src/
├── tests/
├── pyproject.toml
└── README.md
El agente recibe /workspace y nada más en el host. Expresado como política, esto corresponde a una lista de permisos.
Allowed:
/workspace
Everything else:
unavailable
Dado que el resto del sistema de archivos simplemente no existe desde el punto de vista del agente, los trucos con rutas, los enlaces simbólicos y los procesos auxiliares pierden gran parte de su eficacia. Los contenedores, las máquinas virtuales dedicadas y las cuentas de usuario restringidas son formas comunes de implementar esto. El SDK de Agents de OpenAI añadió una ejecución en entorno aislado nativo precisamente con este fin, de modo que los agentes pueden instalar dependencias, editar archivos y ejecutar comandos dentro de un entorno controlado.
Los límites de red y recursos deben estar en el entorno aislado
Aislar el sistema de archivos no es suficiente. Un agente que puede ejecutar algo tan sencillo como esto presenta un perfil de amenaza muy diferente:
curl https://example.com
Con acceso a la red saliente, el agente puede:
- descargar y ejecutar software arbitrario
- extraer datos a un host externo
- llamar a APIs de terceros
Por lo tanto, una sandbox que realmente merezca ese nombre abarca varias dimensiones, no solo archivos.
Filesystem
Network
Processes
Environment variables
Secrets
CPU
Memory
Time
Los procesos heredan silenciosamente variables de entorno y secretos, y los límites de CPU, memoria y tiempo evitan que las compilaciones se salgan de control. Es precisamente por esta amplitud que los entornos de ejecución modernos diseñan la sandbox como un entorno de ejecución completo, y no como una simple capa externa.
Nivel 3: estado persistente que sobrevive a la sesión
Se presenta un tipo diferente de fallo en tareas prolongadas. Un agente pasa una hora explorando un repositorio y aprende una regla arquitectónica importante.
The authentication service must never directly access the database.
All database operations go through Repository classes.
Luego la ventana de contexto se llena, se reinicia la sesión y ese conocimiento desaparece. La siguiente sesión no tiene idea de por qué el diseño se ve de esa manera y podría violarlo sin problemas. El historial de conversaciones no es el lugar adecuado para este tipo de información. Un mecanismo útil separa al menos tres categorías de datos con diferentes períodos de validez.
Conversation state
↓
temporary
Project state
↓
persistent
Harness configuration
↓
persistent + globally enforced
Un ejemplo concreto de cada uno:
Conversation:
"Let's investigate the login bug."
Project:
"Authentication uses OAuth."
Harness:
"Never modify generated migrations."
El elemento de la conversación puede desaparecer sin problemas cuando finaliza la tarea. Los datos del proyecto deben persistir entre sesiones, por ejemplo en un archivo de notas con versionado o en un almacenamiento en memoria. La regla correspondiente debe aplicarse en cada ejecución, independientemente de lo que el modelo recuerde actualmente, lo cual generalmente implica que se encuentre en el código de configuración y aplicación, no en texto. A medida que las sesiones se alargan, esta separación cobra aún más importancia. La API Agents de OpenAI, por ejemplo, incluye funciones de gestión de contexto destinadas a agentes que operan durante mucho tiempo, entre ellas la compactación automática cuando una sesión se acerca a su límite de contexto. La compactación es precisamente el momento en que los datos del proyecto no registrados se pierden, por lo que vale la pena persistirlos antes de ese punto de forma intencionada. Para un análisis más profundo de los niveles de memoria, consulte la memoria de agentes de cuatro niveles con
LangGraph y Bedrock.Capa 4: verificación de que el agente no es dueño
Los agentes pueden estar equivocados con total confianza, por lo que el agente que realizó un cambio no debería ser quien decida si este es correcto. Tomemos esta salida:
def calculate_total(items):
return sum(item.price for item in items) + 1
El + 1 extraño podría parecer intencional para el modelo que lo escribió. Un paso de verificación independiente puede evaluar el cambio en función de varios indicadores.
Code
Tests
Type checking
Linting
Security rules
Expected behavior
Lo que hace valioso esto es la separación entre generar y juzgar.
Agent
│
↓
Changes
│
↓
Verification
↙ ↘
PASS FAIL
↓ ↓
Continue Investigate
Un éxito permite que el bucle continúe; un fracaso envía al agente de vuelta para investigar. Hay una mejora fácil de pasar por alto: el revisor debería informar los problemas en lugar de arreglarlos en silencio. Si el verificador corrige el error sin decir nada, se pierde la señal de que el agente original falló, y las métricas de éxito se vuelven ficticias.
Pruebas en modo simulado como valor predeterminado para cambios riesgosos
En operaciones de mayor importancia, se debe hacer que la visualización sea el comportamiento predeterminado. En lugar de una función de aplicación que actúe de inmediato:
apply_change()
se debe exponer una cuya opción predeterminada segura sea una prueba en modo simulado:
apply_change(dry_run=True)
El agente primero recibe una descripción del efecto.
Would modify:
src/auth.py
tests/test_auth.py
Solo un paso explícito y separado, idealmente uno que requiera aprobación, permite pasar de la visualización a la ejecución. Esto brinda tanto al verificador como a cualquier revisor humano algo concreto para inspeccionar antes de que se produzca cualquier cambio.
Nivel 5: ingeniería de contexto
Cada token que se incluye en el contexto cuesta dinero, compite por la atención del modelo y, en tareas largas, tiende a acumularse más rápido de lo que se elimina. Supongamos que el agente necesita una función de un archivo de 5,000 líneas. Un enfoque ingenuo envía todo el archivo, luego la salida completa de la siguiente búsqueda, luego el resultado de la siguiente herramienta, y así sucesivamente. Pronto el contexto contendrá todo esto:
Task
+ entire repository
+ previous searches
+ tool output
+ logs
+ previous reasoning
+ repeated instructions
Técnicamente el modelo puede ver cada token, pero la visibilidad no equivale a la comprensión. Un diseño mejor trata el contexto como una tubería que condensa la información antes de que llegue al agente principal.
Main Agent
│
├── Search Agent
│ │
│ └── 50,000 tokens
│
│ ↓
│
└── 1,000-token summary
Aquí un agente de búsqueda puede gastar 50,000 tokens en su exploración, pero la sesión principal recibe solo un resumen de 1,000 tokens con lo más importante. Esto es un argumento sólido a favor de los subagentes. Claude Code, por ejemplo, describe a los subagentes como entidades que operan en sus propias ventanas de contexto aisladas y que solo devuelven su resultado final a la conversación principal, lo cual evita que las investigaciones secundarias extensas sobrecarguen el contexto principal. La desventaja es que un resumen podría omitir algún detalle del cual el agente principal necesite hacer uso posteriormente, por lo que los resúmenes deben incluir indicaciones (rutas de archivo, rangos de líneas) que permitan al agente obtener información específica cuando sea necesario.
La economía: el precio por token no es el costo por tarea
La gestión del contexto también es una cuestión presupuestaria. Recuerde el estudio que encontró una diferencia de hasta 40 veces en los tokens por tarea resuelta entre los diferentes entornos, con diferencias mucho menores en la tasa de éxito. Eso cambia la pregunta que merece hacerse. En lugar de “¿cuál modelo es el más barato?”, pregúntese cuántos tokens necesita todo el sistema de agentes para completar una tarea. Compare dos configuraciones.
Agente A: modelo más barato, entorno ineficiente
Model:
$X / million tokens
Task:
500k tokens
Agente B: modelo más caro, entorno eficiente
Model:
2X / million tokens
Task:
100k tokens
El Agente B paga el doble por token, pero utiliza una quinta parte de los tokens, por lo que cada tarea completada cuesta aproximadamente el 40 por ciento de lo que gasta el Agente A, sin siquiera considerar las diferencias en la tasa de éxito. La fijación de precios del modelo es un factor de entrada; la economía de los agentes está determinada por cuánto trabajo el sistema hace que el modelo realice. Nuestro modelo de costos basado en la arquitectura para la IA agente explora este tema con más profundidad.
Turnos inútiles y políticas de terminación
Parte del desperdicio es invisible en las métricas por solicitud. Imagine un agente atrapado anunciando sus intenciones sin actuar:
I should inspect the repository.
y nuevamente en el siguiente turno:
I should inspect the repository.
y una vez más:
I should inspect the repository.
Nada cambia, pero cada turno consume tokens, tiempo de latencia, recursos computacionales, espacio de contexto y posiblemente dinero. El mismo estudio sobre los mecanismos de gestión describe este sobrecosto como un impuesto por espera por tarea, y no simplemente como un impuesto por tokens: los usuarios esperan turnos que no logran nada. Estos mecanismos necesitan reglas de terminación, y la más sencilla es establecer un límite máximo de turnos.
MAX_TURNS = 30
if agent.turns >= MAX_TURNS:
stop()
Un límite es una red de seguridad, no una estrategia. Los mecanismos de gestión más útiles detectan las señales que indican que una ejecución se ha estancado.
No progress
Repeated tool calls
Repeated identical observations
No state change
Test suite unchanged
Agent oscillation
Budget exhausted
Las llamadas repetidas al mismo herramienta, las observaciones inmutables, la ausencia de cambios en el sistema de archivos, un conjunto de pruebas que sigue fallando de la misma manera, las oscilaciones entre dos estados o un presupuesto agotado indican que continuar es poco probable que ayude. En ese punto, el sistema de gestión debería detenerse, resumir la situación y elevarla a niveles superiores. Nuestra guía sobre bucles de agente limitados en TypeScript muestra estos patrones en código.
De envoltorio de herramienta a plataforma
El diseño de harnesses está emergiendo como una disciplina por sí misma. Un estudio reciente del código fuente de once sistemas de agentes de codificación en producción encontró patrones arquitectónicos recurrentes en todos ellos: ejecución de herramientas, gestión de contexto, controles de seguridad, orquestación y superficies de extensión. Sus autores concluyen que los harnesses de codificación han pasado de ser herramientas simples a convertirse en plataformas. Los agentes iniciales eran los siguientes:
LLM + tools
Los sistemas actuales se asemejan a una pila.
LLM
↓
Agent loop
↓
Tool router
↓
Policy engine
↓
Sandbox
↓
Context manager
↓
Memory
↓
Verification
↓
Observability
↓
Orchestration
El modelo sigue siendo el núcleo, pero el entorno de ejecución alrededor de él, desde el enrutador de herramientas y el motor de políticas hasta la zona de pruebas, el gestor de contexto, la memoria, la verificación, la observabilidad y la orquestación, se ha convertido en un producto por derecho propio.
Un diseño de referencia para un agente de codificación
Una arquitectura inicial razonable para un agente de codificación coloca el bucle del agente directamente debajo del modelo y se divide en tres componentes: un enrutador de herramientas, un gestor de contexto y la memoria. Las llamadas a las herramientas pasan por un motor de políticas hacia el entorno aislado; los resultados son verificados, y todo queda registrado mediante mecanismos de observabilidad.
┌──────────────┐
│ Model │
└──────┬───────┘
│
↓
┌─────────────────┐
│ Agent Loop │
└────────┬────────┘
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Tool Router Context Memory
│ Manager │
↓ │ ↓
Policy Engine │ Persistent State
│ │
↓ ↓
Sandbox ←────── Tools
│
↓
Verification
│
↓
Observability
Haga que cada componente sea independientemente probable: realice pruebas unitarias al motor de políticas con llamadas sintéticas, pruebe la gestión de rutas y evalúe al verificador con parches conocidos defectuosos, todo sin necesidad de llamar al modelo.
Desarrolle el sistema a partir de los fallos, no desde un framework
No necesita un framework de agentes masivo para obtener estos beneficios. El bucle central puede mantenerse pequeño incluso después de añadir mecanismos de políticas, aislamiento y verificación.
while turns < MAX_TURNS:
action = model.next_action(context)
if action.is_final:
return action.answer
if not policy.allows(action):
context.append("Action denied")
continue
result = sandbox.execute(action)
verification = verifier.check(result)
context.append(
summarize(result, verification)
)
Tenga en cuenta el orden: la verificación de políticas se realiza antes de la ejecución; una acción denegada se reporta al modelo en lugar de hacer que el bucle fallen. La ejecución siempre pasa por la zona segura, y lo que vuelve al contexto es un resumen del resultado y su verificación, no la salida bruta. A partir de ahí, solo se debe añadir complejidad en respuesta a un fallo detectado.
Agent deleted something?
→ add execution policy
Agent accessed the wrong file?
→ strengthen sandbox
Agent forgets architecture?
→ add persistent project memory
Agent produces bad code?
→ add verification
Agent becomes expensive?
→ optimize context
Agent loops?
→ add termination detection
Cada síntoma se corresponde con exactamente una capa. Esto es mucho más saludable que introducir cincuenta abstracciones antes de saber cuál es el problema. Para una discusión más amplia sobre si construir este bucle por uno mismo o adoptar uno ya existente, consulte runtime harnesses vs composed frameworks.
El repositorio como base de conocimientos del agente
En el desarrollo impulsado por agentes, un repositorio es más que código fuente. Puede contener todo lo que un agente necesita para trabajar en el proyecto: decisiones de arquitectura, comandos de desarrollo y pruebas, vocabulario del dominio, esquemas, planes, manuales operativos e instrucciones específicas para el agente, todo versionado junto al código que describen. Los propios escritos de OpenAI sobre ingeniería de aprovechamiento resaltan este punto, considerando los artefactos versionados almacenados en el repositorio como el sistema de registro de lo que un agente debe conocer para comprender y modificar un proyecto, y recomiendan utilizar un mapa que indique documentos específicos en lugar de un único archivo de instrucciones enorme. La conclusión es clara: una decisión de diseño que solo existe en la mente de alguien o en un hilo de conversación no existe para el agente. Hacer que el conocimiento sea discoverable se ha convertido en parte de la arquitectura de software.
Gancho: comportamiento que el modelo no necesita recordar
Los ganchos se encuentran entre las primitivas de arnés más útiles. Un gancho permite que el tiempo de ejecución reaccione a un evento del ciclo de vida con código determinista. El más obvio sirve para controlar las llamadas a herramientas.
Before tool call
↓
Check policy
↓
Allow / deny
Otro mantiene la calidad del código consistente después de cada edición.
After file edit
↓
Run formatter
↓
Run type checker
Un tercero protege el conocimiento antes de que el contexto sea comprimido.
Before context compaction
↓
Persist important state
Un cuarto crea un registro de auditoría.
After task completion
↓
Generate audit record
Claude Code documenta los ganchos como comandos activados por el ciclo de vida que se ejecutan de manera determinista y pueden, entre otras cosas, bloquear una llamada a herramienta antes de que se ejecute. Su poder proviene del hecho de sacar el comportamiento por completo del razonamiento del modelo. En lugar de escribir “por favor, recuerda ejecutar el formateador” en una solicitud y esperar, el tiempo de ejecución simplemente ejecuta el formateador cada vez.
Nunca dejes que el modelo controle los límites
Los modelos son probabilísticos; los límites de seguridad no deben serlo. Este antipatrón delega la decisión en el modelo:
if model_says_safe:
execute()
Este patrón la delega en la infraestructura, que no puede ser convencida de cambiar su respuesta:
if operating_system_allows:
execute()
Utilice el modelo para decisiones que se benefician del juicio, y una infraestructura determinista para aquellas que necesitan garantías. En la práctica, cada capa responde a su propia pregunta.
Model:
Should I modify this file?
Harness:
Is this file inside the workspace?
OS:
Can this process write to the file?
Human:
Should this high-risk action proceed?
El modelo decide si un cambio es una buena idea, el mecanismo de control verifica que el destino esté dentro del área de trabajo, el sistema operativo decide si el proceso puede escribir en el archivo, y una persona decide si se debe proceder con una acción de alto riesgo. Estas respuestas por capas son mucho más robustas que esperar que un solo componente haga todo correctamente.
Los mecanismos de control amplifican a los modelos; no los reemplazan
Es tentador concluir que los arneses son más importantes que los modelos. La evidencia no lo respalda. En el escenario estudiado, la elección del arnés tuvo efectos significativos en la eficiencia de los tokens, pero efectos mucho menores en el éxito de la tarea; además, ninguna cantidad de ingeniería de tiempo de ejecución puede convertir a un modelo débil en un ingeniero de software competente. Una forma clara de separarlos es:
Model capability
=
What the agent can reason about
Harness quality
=
How effectively that capability is deployed
Un modelo brillante dentro de un entorno de ejecución deficiente desperdicia enormes cantidades de recursos y dinero. Un entorno de ejecución cuidadosamente diseñado alrededor de un modelo débil sigue tomando decisiones deficientes, pero de manera segura y eficiente. Se necesitan ambos.
Cinco preguntas que hacer antes de desplegar cualquier agente
1. ¿Qué puede hacer?
Inventario cada herramienta y señale todas las operaciones peligrosas.
read
write
delete
execute
network
deploy
send_message
2. ¿Hasta dónde puede llegar?
Las definiciones de las herramientas solo cuentan parte de la historia. Verifique a qué puede acceder realmente el proceso:
filesystem
network
environment
secrets
processes
credentials
3. ¿Qué sobrevive a un reinicio?
Reinicie el agente y descúbralo:
What does it remember?
What does it forget?
Where is important state stored?
4. ¿Quién verifica el resultado?
Para operaciones con consecuencias, un flujo de trabajo de dos pasos no es suficiente:
generate → approve
Inserte verificaciones independientes entre la generación y la aprobación:
generate
↓
test
↓
review
↓
approve
5. ¿Cuál es el costo real de cada tarea?
Los conteos de tokens por solicitud son engañosos por sí solos:
tokens per request
Mida los resultados en su lugar:
tokens per successful task
latency per successful task
tool calls per task
retries per task
human interventions
Los tokens, la latencia, las llamadas a herramientas, los intentos de reintentar y las intervenciones humanas por tarea completada son las cifras que indican si vale la pena mantener en funcionamiento el sistema.
Una definición funcional de un agente de producción
Al combinar las capas se obtiene una definición más precisa.
Agent =
Model
+ Tools
+ Execution Environment
+ Policy
+ Memory
+ Context Management
+ Verification
+ Observability
Cada elemento tiene su lugar. Sin el modelo no hay inteligencia; sin herramientas no hay acción; sin un entorno de ejecución y políticas, el agente puede ser peligroso; sin memoria, las tareas largas se vuelven frágiles; sin gestión de contexto, los costos aumentan exponencialmente; sin verificación, los errores se propagan sin ser detectados; y sin capacidad de observabilidad, no se puede reconstruir lo que sucedió cuando algo falla.
Conclusión
La conversación en la industria está pasando de determinar qué modelo supera una prueba de referencia a averiguar qué entorno de ejecución permite que un modelo realice tareas útiles de manera fiable. Los proveedores se están alineando en los mismos componentes básicos: OpenAI ahora vende infraestructura de agentes gestionados que incluye entornos aislados, manejo de contexto, búsqueda de herramientas, llamadas a herramientas desde código y ejecución prolongada, mientras que Anthropic ofrece instrucciones persistentes, habilidades, subagentes y mecanismos deterministas. La investigación está comenzando a evaluar estos componentes como variables experimentales en lugar de tratar al modelo como el sistema completo. Estas características evolucionan rápidamente, por lo que consulte la documentación actual.
La receta simplista para crear un agente es breve:
Pick LLM
+
Add tools
=
Agent
La receta realista se ve así:
Model
↓
Agent Runtime
↓
┌─────────┼─────────┐
↓ ↓ ↓
Policy Context Memory
↓ ↓ ↓
Sandbox Tools Persistence
└─────────┼─────────┘
↓
Verification
↓
Observability
El modelo toma decisiones; el marco define las condiciones bajo las cuales esas decisiones se convierten en acciones. Antes de elegir un framework, pregúntese qué sucede cuando el modelo se equivoca y construya el marco en torno a esa respuesta.
- Aplicar reglas deterministas en el código y los hooks, no en los mensajes de solicitud.
- Tratar las políticas de la herramienta como primera línea de defensa y el entorno aislado del sistema operativo, incluidos los límites de red y recursos, como el verdadero límite.
- Separar el estado de la conversación, del proyecto y del marco según su ciclo de vida, y persistir los datos del proyecto antes de realizar operaciones de compactación.
- Mantener la verificación independiente y hacer que los revisores informen en lugar de corregir directamente.
- Optimizar los tokens por tarea completada con éxito y detener las ejecuciones que dejen de avanzar.
El objetivo no es un agente que nunca cometa errores, sino un sistema en el cual un error del modelo no se convierta automáticamente en un incidente de producción.
Lecturas relacionadas
- Construyendo un agente AI personal en el que puedes confiar: memoria, herramientas y acceso ganado — Cómo un agente personal como Hermes Agent combina memoria, herramientas y enrutamiento de modelos, y cómo desplegarlo de forma segura con roles restringidos, fuentes de bajo riesgo y acceso ganado.
- Diseñando sistemas multi-agente en A2A: nodos, memoria y gobernanza — Una arquitectura de referencia para sistemas multi-agente basados en el protocolo A2A, que abarca módulos de agente, tipos de memoria, orquestación, riesgos de seguridad y una lista de verificación para el diseño.