# AX-SYS-24: Devuelve un identificador de tarea para el trabajo que dura más que una petición

> Recovery and reliability · intermediate · AX-SYS-24

Cuando una operación tarda más que una petición normal, acéptala de inmediato y devuelve un identificador que el agente pueda consultar, cancelar y del que pueda recoger el resultado más tarde, en lugar de mantener la conexión abierta hasta que expire.

## Por qué

Las exportaciones, las compilaciones, los procesos por lotes y todo lo que espera una aprobación humana tardan minutos u horas. Si la única interfaz es una llamada que se bloquea hasta que el trabajo termina, la petición del agente expira, el agente no sabe si el trabajo se hizo y la recuperación obvia (volver a llamar) lanza una segunda copia. HTTP tiene la respuesta desde hace décadas: el 202 Accepted de la RFC 9110 permite a un servidor aceptar una petición para un proceso posterior sin mantener la conexión abierta, y dice que la respuesta debería describir el estado actual y apuntar a un monitor de estado. Los protocolos de agentes ya parten de esa idea. La extensión Tasks de MCP permite a un servidor responder a un `tools/call` con un identificador de tarea en lugar de un resultado final, que el cliente consulta con `tasks/get` y puede detener con `tasks/cancel`. El identificador lleva un `pollIntervalMs` que los clientes deberían respetar y un `ttlMs` tras el cual el servidor puede descartar la tarea. La especificación de A2A se define como asíncrona por diseño para el trabajo de larga duración y con intervención humana: cuando una llamada vuelve de inmediato, quien llama consulta, se suscribe o recibe notificaciones push. Un identificador da acceso al trabajo de alguien, así que la extensión de MCP exige comprobar la autenticación y la autorización en cada petición sobre una tarea.

## Haz

Devuelve un identificador con estado, un intervalo de consulta sugerido y un tiempo de retención, y comprueba la autorización de quien llama en cada consulta.

## No hagas

Bloquear una petición hasta que termine un trabajo largo, ni obligar al agente a reenviar el trabajo para saber si se ejecutó.

## Artefacto

```json
{
  "resultType": "task",
  "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
  "status": "working",
  "createdAt": "2025-11-25T10:30:00Z",
  "lastUpdatedAt": "2025-11-25T10:40:00Z",
  "ttlMs": 60000,
  "pollIntervalMs": 5000
}
```

Valores de estado: `working`, `input_required`, `completed`, `cancelled`, `failed`. Sobre HTTP simple, el mismo contrato es un `202 Accepted` con `Location: /v1/jobs/786512e2` apuntando al recurso de estado.

## Fuentes

1. [MCP Tasks extension (io.modelcontextprotocol/tasks)](https://tasks.extensions.modelcontextprotocol.io/specification/draft/tasks): The extension allows a server to respond to a tools/call request with an asynchronous task handle instead of a final result, allowing the client to retrieve the eventual result by polling; clients SHOULD respect the pollIntervalMs provided in responses, and servers MUST perform authentication and authorization checks on each task-related request
2. [A2A Protocol Specification](https://github.com/a2aproject/A2A/blob/main/docs/specification.md): Async First: designed for (potentially very) long-running tasks and human-in-the-loop interactions; with return_immediately the operation returns right after creating the task, and it is the caller's responsibility to poll for updates, subscribe, or receive updates via push notifications
3. [RFC 9110: HTTP Semantics (15.3.3, 202 Accepted)](https://www.rfc-editor.org/rfc/rfc9110.html#name-202-accepted): The 202 response allows a server to accept a request for some other process without requiring that the user agent's connection to the server persist until the process is completed; the representation ought to describe the request's current status and point to (or embed) a status monitor

---
Source: Agent Experience Principles (axprinciples.com)