Update an existing AI agent’s configuration, tools, or knowledge bases
openai)gpt-4o, gpt-4.1)ACTIVE, INACTIVE)low, medium, high)text or jsonoutput_format is jsonpersonal or organizationalmanager, regular, a2a, curlAIAgent object with all current configuration.
name, instructions, model_provider, model_name, output_format, expected_output, and access_scope. To attach tools or knowledge bases, use the xpander.ai platform or the Python SDK.
deploy=true query parameter to automatically deploy after updatingdeploy=true, changes are staged and require a separate Deploy Agent callattached_tools, knowledge_bases, and graph can now be updated via PATCHAPI Key for authentication
Automatically deploy the agent after updating to apply changes immediately. Without this, changes are staged but not active until a PUT deploy call.
Request model for updating an existing AI agent.
All fields are optional — only provide the fields you want to change. At least one field must be provided. Fields not included in the request will retain their current values.
System-managed fields like organization_id, agent_id, id, status,
version, etc. are set by the service layer and should not be provided.
Set automatically by the API service from the authenticated request.
Set automatically by the API service from the URL path parameter.
Human-readable name for the agent.
A brief description of what the agent does.
Emoji icon displayed next to the agent name.
Avatar identifier for the agent's visual representation.
The agent type. Cannot be changed to 'orchestration' — use the Workflows API.
manager, regular, a2a, curl, orchestration Agent status. Set to 'ACTIVE' to enable or 'INACTIVE' to disable the agent.
DRAFT, ACTIVE, INACTIVE The LLM provider to use.
openai, nim, amazon_bedrock, azure_ai_foundary, huggingFace, friendlyAI, anthropic, gemini, fireworks, google_ai_studio, helicone, bytedance, tzafon_lightcone, open_router, nebius, cloudflare_ai_gw The specific model identifier.
Reasoning depth control.
low, medium, high, xhigh Custom API base URL for the LLM provider.
Reference key to stored LLM API credentials.
Type of credential storage.
xpander, custom Direct LLM credentials object.
Additional HTTP headers for LLM requests.
Structured instructions for the agent.
Description of expected output format.
Response format.
text, markdown, json, voice JSON Schema for structured output.
Execution framework.
Sub-agent delegation strategy.
router, sequence Memory sharing between sub-agents.
full, summarization, original-input End behavior for delegation chains.
return-to-start, finish-with-last Whether sub-agents share a continuous thread.
Enable deep planning mode.
Force deep planning for all tasks.
Connector connections with operation IDs. See CreateAgentRequest.attached_tools for full documentation.
The agent's tool graph. See CreateAgentRequest.graph for full documentation.
Per-tool LLM override settings.
Attached knowledge bases.
Agent trigger entry points.
Deployment infrastructure.
serverless, container Access visibility scope.
personal, organizational Target deployment environment.
External agent connection details.
Agno framework settings.
Task execution strategies.
Task notification settings.
Voice ID for TTS output.
Enable NeMo guardrails.
Enable prompt caching.
Enable supervised mode.
Enable event streaming.
Workflow orchestration DAG nodes. Only for type=orchestration workflows.
Enable OIDC pre-authentication.
Allowed OIDC audiences.
Forward OIDC token to LLM.
OIDC audience for LLM access.
OIDC audience for MCP access.
Successful Response
Enumeration of the agent delegation end strategies.
Attributes: ReturnToStart: when last agent is finished and about to announce "finish" it will summarize and return to the first agent. FinishWithLast: finish at the last agent.
return-to-start, finish-with-last serverless, container personal, organizational Enumeration of possible agent statuses.
Attributes: DRAFT: Agent is in a draft state. ACTIVE: Agent is active and operational. INACTIVE: Agent is inactive and not operational.
DRAFT, ACTIVE, INACTIVE Enumeration of the agent types.
Attributes: Manager: marks the agent as a Managing agent. Regular: marks the agent as a regular agent. A2A: marks the agent as an external agent used via A2A protocol. Curl: marks the agent as an external agent used via a CURL. Orchestration: marks the agent as an Orchestration object.
manager, regular, a2a, curl, orchestration Enumeration of the agent delegation types.
Attributes: Router: Marks the agent as a router agent - xpanderAI's LLM will decide which sub-agent to trigger. Sequence: Marks the agent as a sequence agent - sub-agents will delegate to other sub-agents.
router, sequence Enumeration of the agent delegation memory strategies.
Attributes: Full: The memory object will be passed completely between agents. Summarization: Between each sub-agent delegation, a summarization will occur, and a new thread will be created for each agent. OriginalInput: the sub agent will get the initial task with a fresh memory thread
full, summarization, original-input openai, nim, amazon_bedrock, azure_ai_foundary, huggingFace, friendlyAI, anthropic, gemini, fireworks, google_ai_studio, helicone, bytedance, tzafon_lightcone, open_router, nebius, cloudflare_ai_gw low, medium, high, xhigh text, markdown, json, voice xpander, custom Configuration for event-based notifications.
Attributes: on_success: Notifications to send when an operation succeeds. Maps notification types to a list of notification configurations. on_error: Notifications to send when an operation fails. Maps notification types to a list of notification configurations.
Configuration object for task-level execution strategies.
This model groups optional strategy configurations that control how a task is executed and managed over time, including retries, iterative execution, stopping conditions, and daily run limits.
Attributes: retry_strategy: Optional retry policy configuration that defines how the task should behave when execution fails (e.g., max attempts, backoff rules).
iterative_strategy:
Optional iterative execution configuration for tasks that may run in
repeated cycles/steps until completion or a stop condition is met.
stop_strategy:
Optional stopping policy configuration that defines when the task
should stop running (e.g., timeout, max iterations, success criteria).
max_runs_per_day:
Optional limit on how many times the task is allowed to run within a
24-hour period. If not set, no explicit daily limit is enforced.
agentic_context_enabled:
if agentic memory is enabled and accesible to the executor.