dful.
Dful Dark
Tema
Árbol de conocimiento
En esta página

Estado de un agente

Qué debe registrar una aplicación para que un agente pueda continuar una tarea sin confundir contexto, evidencias y estado externo.
Actualizado 6 oct 2026

El estado de un agente vive en la aplicación. El modelo recibe una selección de ese estado en cada llamada, toma una decisión y devuelve una respuesta o una tool call. Mientras tanto, el repositorio, la API o el servicio sobre el que trabaja siguen teniendo su propio estado.

Entorno externo, estado de aplicación y contexto del modelo La observación pasa del entorno externo al estado de la aplicación. Las acciones vuelven al entorno. La aplicación selecciona parte del estado para el contexto del modelo. Entorno externo Repositorio, APIs, servicios Estado de la aplicación Tarea y evidencias Contexto del modelo Selección para la siguiente llamada Observar Actuar Seleccionar Entorno externo, estado de aplicación y contexto del modelo La observación pasa del entorno externo al estado de la aplicación. Las acciones vuelven al entorno. La aplicación selecciona parte del estado para el contexto del modelo. Entorno externo Repositorio, APIs, servicios Estado de la aplicación Tarea y evidencias Contexto del modelo Selección para la siguiente llamada Observar Actuar Seleccionar
El agente observa y actúa sobre el entorno. La aplicación registra esos resultados y selecciona qué parte llega al modelo.

El sentido de las flechas importa. Una observación actualiza el registro de la aplicación. Una acción intenta cambiar el entorno. El contexto solo contiene lo que se envía al modelo para la siguiente decisión. Ninguna de las tres capas es una copia garantizada de otra.

Un registro que se pueda usar

Supongamos que un agente comprueba si user_b puede modificar una factura de user_a en una API de prueba. Su registro de trabajo podría ser:

objective: verify-cross-account-write
scope:
  origin: https://api.example.test
  identities: [user_a, user_b]
  allowed_actions: [read, replay, reversible-write]
observations:
  - id: obs-014
    source: GET /api/invoices/1042 as user_a
    value: "owner=user_a; note=before"
    observed_at: 2026-10-05T09:12:00Z
    evidence: artifacts/requests/obs-014.http
hypotheses:
  - id: hyp-003
    claim: "user_b can change invoice 1042 despite owning a different account"
    based_on: [obs-014]
    status: unverified
actions:
  - id: act-021
    operation: PATCH /api/invoices/1042 as user_b
    marker: auth-check-01
    result: timeout-unknown
    observed_at: 2026-10-05T09:15:00Z
pending:
  - read invoice 1042 as user_a and compare its note with obs-014
checkpoint:
  step: verify-write-effect
  request_log: artifacts/requests/act-021.http

Es un ejemplo de diseño, no un schema obligatorio. Separa lo observado de lo inferido. El log conserva los bytes exactos de la request y obs-014 permite citarla sin copiarla entera. hyp-003 sigue sin verificar hasta que la lectura posterior muestre qué ocurrió. El timeout no puede anotarse como escritura correcta ni como rechazo.

Un path, un ID externo o un hash se guardan literalmente cuando luego habrá que recuperar el mismo recurso. Un resumen puede explicar por qué se probó la factura 1042, pero no sustituye las requests y respuestas. Para tokens, el estado debería guardar una referencia a un almacén controlado, no el valor.

Qué entra en contexto

Para decidir el siguiente paso del ejemplo bastan el objetivo, el alcance de la prueba, la propiedad de la factura, el PATCH sin resultado claro y la verificación pendiente. El log HTTP completo puede quedar fuera si el modelo puede recuperarlo. Tampoco hace falta reenviar todas las requests anteriores.

La selección cambia con la tarea. Después de leer otra vez la factura, la respuesta nueva pasa a ser la evidencia inmediata. El baseline sigue disponible para comparar. Antes de otra request, la aplicación puede recuperar el alcance y las reglas de autorización exactas, además del intercambio HTTP pertinente.

Después de una tool call

El runtime debe registrar qué operación se intentó, sus argumentos, el resultado y cuándo se observó. Un código HTTP aislado no demuestra que una escritura se haya conservado. Una respuesta de error puede indicar que la operación no empezó, falló a medias o terminó pero se perdió la respuesta.

Un timeout después de una acción con efectos es ambiguo. Si el PATCH anterior agota el tiempo de espera, lee la factura como su propietario antes de repetir la escritura. Compara la marca y el valor original, y registra completed, not-applied o unknown. Si la API admite una clave de idempotencia o un ID de operación, consérvalo con la acción.

Datos que caducan

observed_at indica cuándo se vio un dato, no cuánto tiempo seguirá siendo válido. La propiedad de una factura, los permisos, el estado de un job o la respuesta de una API pueden cambiar sin que actúe el agente. Revalida antes de una acción que dependa de ese dato, sobre todo después de una pausa o si otra persona pudo intervenir.

Un checkpoint restaura el paso y las referencias guardadas. Al reanudar, comprueba la factura y el estado de la sesión antes de continuar. El checkpoint no congela el target. Si la marca ya existe o un token ha caducado, la siguiente request cambia.

Referencias