Run Task Agent

Execute the Task Agent with a user message. The agent will: 1. Process the message using the configured LLM 2. Reason about which task tools to invoke 3. Execute relevant Tasks as needed 4. Return a streaming response Send `application/json` for text, correlation fields, and optional base64-encoded files. Send `multipart/form-data` to upload binary files directly. Both formats require `message`. Responses are streamed using Server-Sent Events (SSE). The first SSE event emitted after successful stream setup is: - `event_type: "session_id"` with the resolved `session_id` in `metadata` Use `revision_id` to execute a specific TaskAgent revision. New sessions can run any revision belonging to the TaskAgent. Existing sessions remain pinned to their original revision; passing a conflicting `revision_id` is rejected. Subsequent events include tool calls/results, text responses, metadata-only `memory_compaction` events when compaction memory runs, and the terminal `done` or `error` event. Compaction metadata may include token-threshold configuration such as `trigger: "auto"`, `token_threshold`, and `event_retention_size` when token-aware compaction is active. If the model proposes a tool call gated behind `require_approval`, the stream ends early with an `event_type: "approval_required"` event instead of a terminal `done`/`error` event. Its `metadata` carries `approval_request_id`, `tool_type`, `tool_name`, `tool_args_preview`, optional `agent_reason`, and `expires_at`; the run's status becomes `waiting_for_human` and stays paused until a human approves or rejects the request (see the approval-request endpoints) and a caller invokes the resume endpoint. Treat `agent_reason` as plain untrusted model-authored text. Example stream for a normal run — the agent classifies the message, looks up the account in a connected integration, drafts a reply with a Task tool marked as the output formatter, and completes: ``` data: {"event_type": "session_id", "metadata": {"session_id": "..."}, ...} data: {"event_type": "tool_call", "tool_name": "customer_support_analyzer", "tool_args": {"message": "..."}, ...} data: {"event_type": "tool_result", "tool_name": "customer_support_analyzer", "tool_result": {"result": {"sentiment": "concerned", ...}, "task_run_id": "..."}, "tool_outcome": "success", ...} data: {"event_type": "tool_call", "tool_name": "sheets_spreadsheets_values_get", "tool_args": {"spreadsheet_id": "...", "range": "Customers!A2:F500"}, ...} data: {"event_type": "tool_result", "tool_name": "sheets_spreadsheets_values_get", "tool_result": {"range": "Customers!A2:F2", "values": [[...]]}, "tool_outcome": "success", ...} data: {"event_type": "tool_call", "tool_name": "draft_support_reply", "tool_args": {"ticket_summary": "...", "customer_record": {...}}, ...} data: {"event_type": "formatted_output", "content": "Hi Dana, ...", "tool_outcome": "success", "metadata": {"is_formatter_output": true, "task_run_id": "..."}, ...} data: {"event_type": "done", "metadata": {"run_id": "...", "session_id": "...", "duration_ms": 9130, "total_tokens": 2250, "used_fallback_model": false, "fallback_model_id": null}, ...} ``` Terminal `done` and `error` SSE events include fallback metadata when a run is known: `used_fallback_model` and `fallback_model_id`. Terminal `error` events also include stable `error_code` and `termination_reason` values. Current error codes are `CONTEXT_WINDOW_EXCEEDED`, `INTEGRATION_NOT_CONNECTED`, `INTEGRATION_REAUTH_REQUIRED`, `INTEGRATION_AUTH_REQUIRED`, `UNSUPPORTED_INTEGRATION_TYPE`, `INSUFFICIENT_CREDITS`, `APPROVAL_CAPTURE_FAILED`, `FORMATTER_FAILED`, `FORMATTER_EMPTY_OUTPUT`, `TASK_AGENT_NOT_FOUND`, and `EXECUTION_ERROR`.