Inicia una sesión

Una sesión es una instancia de agente dentro de un entorno. Cada sesión hace referencia a un agente y a un entorno (ambos creados por separado), y mantiene el historial de conversación a través de múltiples interacciones. Las sesiones siguen un ciclo de vida de dos pasos: primero crea la sesión, luego envía un evento de usuario para iniciar el trabajo. También puedes combinar ambos pasos en una sola llamada con initial_events.



Crear una sesión

Una sesión requiere un ID de agent y un ID de environment. Los agentes son recursos versionados; pasar el ID de agent como una cadena inicia la sesión con la versión más reciente del agente.

ant beta:sessions create \
  --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID"

Para fijar una sesión a una versión específica del agente, pasa un objeto. Esto te permite controlar exactamente qué versión se ejecuta y escalonar los despliegues de nuevas versiones de forma independiente.

ant beta:sessions create <<YAML
agent:
  type: agent
  id: $AGENT_ID
  version: 1
environment_id: $ENVIRONMENT_ID
YAML



Inicializa la sesión con eventos iniciales

Puedes crear una sesión e iniciar su trabajo en una sola llamada. initial_events es un arreglo opcional de eventos iniciales para enviar a la sesión en el momento de la creación, procesados en orden. Admite eventos user.message y user.define_outcome, y acepta un máximo de 50 eventos. Una lista no vacía inicia el bucle del agente en la misma llamada: la sesión se crea directamente en el estado running, sin ninguna solicitud adicional.

El siguiente ejemplo crea una sesión con un único user.message en initial_events:

SEEDED_SESSION_ID=$(ant beta:sessions create \
  --transform id --raw-output <<YAML
agent: $AGENT_ID
environment_id: $ENVIRONMENT_ID
initial_events:
  - type: user.message
    content:
      - type: text
        text: List the files in the working directory.
YAML
)

# initial_events no se devuelven en la respuesta de creación; lista los eventos
# de la sesión para ver el mensaje sembrado.
echo "Seeded event: $(ant beta:sessions:events list \
  --session-id "$SEEDED_SESSION_ID" \
  --format raw \
  --transform 'data.#(type=="user.message").content.0.text' --raw-output)"

No se acepta ningún otro tipo de evento. Los eventos que responden a un turno del agente (user.tool_confirmation, user.tool_result y user.custom_tool_result) no se aceptan porque todavía no existe ningún turno del agente, y user.interrupt no se acepta porque no hay ningún turno que detener. A diferencia de initial_events en un despliegue programado, los initial_events de una sesión no aceptan system.message.

Cada evento en initial_events se valida y persiste antes de que se devuelva la respuesta de creación, en el orden de la lista, con un ID asignado por el servidor, exactamente como si lo hubieras publicado en el endpoint de envío de eventos inmediatamente después de la creación. Las reglas de contenido por evento también son las mismas que en ese endpoint. Una lista vacía es equivalente a omitir el campo. La validación es todo o nada: si algún evento falla la validación, toda la solicitud se rechaza y no se crea ninguna sesión.

La solicitud de creación se rechaza en los siguientes casos:

Un evento user.define_outcome en initial_events se acepta bajo las mismas condiciones que al enviar uno a una sesión existente; consulta Definir resultados.



Sobrescribe la configuración del agente para una sesión

Puedes pasar agent en tres formas: una cadena con el ID del agente, un objeto de versión fijada (type: "agent") o un objeto de sobrescrituras. La forma de sobrescrituras cambia partes de la configuración del agente para una sola sesión. Úsala para probar un modelo diferente u otorgar una herramienta adicional en una sesión sin versionar el agente. Para la forma de sobrescrituras, establece type en agent_with_overrides y pasa el id del agente y, opcionalmente, una version (omite version para usar la versión más reciente del agente). Luego incluye cualquiera de model, system, tools, mcp_servers o skills con los valores que la sesión debe usar.

Cada campo sobrescribible sigue las mismas tres reglas:

• Omitir el campo: La sesión hereda el valor de la versión del agente a la que hace referencia.
• Establecer el campo en null, o en un arreglo vacío para campos de lista: La sesión se ejecuta con ese campo vacío. Esta regla se aplica en su totalidad a system y skills. Hay tres excepciones:
  • model nunca se puede vaciar. Una sesión siempre necesita un modelo, por lo que model: null devuelve un error 400 agent_model_required.
  • Vaciar tools devuelve un error 400 cuando el skills efectivo de la sesión no está vacío, porque las skills requieren la herramienta read. De lo contrario, tools: null y tools: [] vacían el campo.
  • Vaciar mcp_servers devuelve un error 400 cuando el tools efectivo de la sesión todavía contiene un mcp_toolset que hace referencia a uno de los servidores del agente. Sobrescribe tools en la misma solicitud para eliminar esas entradas mcp_toolset y luego vacía mcp_servers.
• Establecer el campo en un valor: El valor reemplaza el valor del agente en su totalidad. Las sobrescrituras nunca se fusionan con la configuración del agente, por lo que una sobrescritura de tools debe listar todas las herramientas que la sesión debe tener. Hay una excepción:
  • Un nivel de effort dentro de una sobrescritura de model por sesión no se aplica. En su lugar, establece effort en el agente.

Las sobrescrituras se aplican solo a la sesión que creas. No modifican el recurso del agente ni crean una nueva versión del agente, por lo que otras sesiones que hacen referencia al mismo agente no se ven afectadas.

En la respuesta, el objeto agent refleja la configuración con la que se ejecuta la sesión después de aplicar las sobrescrituras. Su id y version siguen identificando el agente y la versión a los que se aplican las sobrescrituras. Esto te permite rastrear una sesión hasta su agente base.

El siguiente ejemplo inicia una sesión que sobrescribe el modelo y vacía la indicación del sistema:

# El `agent` de la respuesta es el snapshot resuelto: cada override reemplaza ese
# campo solo para esta sesión, y el recurso del agente conserva su id y versión.
ant beta:sessions create \
  --transform 'agent.{id,version,model,system}' \
  --format json <<YAML
agent:
  type: agent_with_overrides
  id: $AGENT_ID
  model:
    id: claude-sonnet-5
  system: null
environment_id: $ENVIRONMENT_ID
YAML



Autenticación MCP a través de vaults

Si tu agente usa herramientas MCP que requieren autenticación, pasa vault_ids al crear la sesión para hacer referencia a un vault que contenga credenciales OAuth almacenadas. Anthropic gestiona la renovación de tokens en tu nombre. Consulta Autenticar con vaults para saber cómo crear vaults y registrar credenciales.

ant beta:sessions create <<YAML
agent: $AGENT_ID
environment_id: $ENVIRONMENT_ID
vault_ids:
  - $VAULT_ID
YAML



Iniciar la sesión

Crear una sesión sin initial_events registra la sesión pero no inicia ningún trabajo; el sandbox del entorno se aprovisiona cuando la sesión lo necesita por primera vez. Para delegar una tarea, envía eventos a la sesión usando un evento de usuario. Para proporcionar el primer evento en la solicitud de creación en su lugar, consulta Inicializa la sesión con eventos iniciales. La sesión actúa como una máquina de estados que rastrea el progreso mientras los eventos impulsan la ejecución real.

ant beta:sessions:events send \
  --session-id "$SESSION_ID" <<'YAML'
events:
  - type: user.message
    content:
      - type: text
        text: List the files in the working directory.
YAML

Consulta Flujo de eventos de sesión para saber cómo hacer streaming de las respuestas del agente y manejar las confirmaciones de herramientas.

Consulta Estados de sesión para conocer los estados por los que pasa una sesión.



Próximos pasos