Prompt and plugin presets ignore the selected agent profile at run time #557

Problem

On main (and the released 1.17.0 and 1.18.0), the prompt and plugin presets ignore an automation's selected agent profile when they run. The run uses the default agent instead of the profile's tools, prompt, MCP servers and LLM, and nothing reports that the profile was dropped.

What happens today:

1. Create rejects the profile. POST /v1/preset/prompt and /v1/preset/plugin return 422 "Extra inputs are not permitted" for agent_profile_id (CreatePromptAutomationRequest / CreatePluginAutomationRequest in preset_router.py are extra="forbid" and have no such field). Agent Canvas tracks the UI side as [Bug]: Automation setup offers an Agent profile for Prompt and Plugin actions, but choosing one blocks creation with "Extra inputs are not permitted" OpenHands#17960.
2. Update accepts it. PATCH on the automation stores agent_profile_id (router.py), which is the path Canvas's edit modal uses.
3. The dispatcher passes it on. It sets AUTOMATION_AGENT_PROFILE_ID in the run environment (dispatcher.py:347).
4. The preset scripts never read it. presets/prompt/sdk_main.py:446 and presets/plugin/sdk_main.py:477 build get_default_agent(llm=..., cli_mode=True, ...) client-side. The only reference to the variable outside the dispatcher is tests/test_dispatcher.py.

Reproduction

Verified 2026-10-05 against Agent Canvas with agent-server 1.52.0 and automation 1.17.0. Main and 1.18.0 have the same code.

1. Save an agent profile with a custom tool selection, e.g. tools: [terminal, file_editor, task_tool_set].
2. Create a prompt-preset automation. Adding agent_profile_id to the create request returns 422.
3. Set agent_profile_id on the automation with PATCH; it's accepted.
4. Run it.

Observed: the run's conversation gets the default tools (terminal, file_editor, task_tracker), not the profile's, and the conversation has launched_agent_profile: null.

Expected

A preset run with a selected profile launches that profile, so launched_agent_profile is set and the profile's tools, prompt, MCP servers and LLM apply. Until that works, selecting a profile on a preset automation should be rejected consistently on create and update, rather than accepted and silently ignored.

Context

• The behaviour is already implemented on the factory/automation branch by feat: select agent profiles on automation definitions #453 ("select agent profiles on automation definitions": the backend creates the conversation from the profile and the worker attaches to it), with Apply preset FinishTool hooks to profile-created conversations #457 tracking the preset FinishTool hook on that path. It hasn't reached main or a release, so Canvas and cloud, which consume released versions, still get the old behaviour.
• Related: feat: select an agent profile for delegated automation work #479 and feat: support agent profiles in cloud mode #541 (profile selection plumbing on main), [Bug]: Automation setup offers an Agent profile for Prompt and Plugin actions, but choosing one blocks creation with "Extra inputs are not permitted" OpenHands#17960, and fix(automations): hide agent profiles for preset actions OpenHands#17971 (Canvas hides the profile picker for preset actions on create; the edit modal still offers it).

Acceptance criteria

• On main, a prompt- or plugin-preset run with agent_profile_id launches through that profile (launched_agent_profile matches; the model is offered the profile's tools).
• Create and update agree on whether presets accept agent_profile_id.
• A run whose profile can't be applied fails visibly instead of falling back to the default agent.
• Shipped in a release that Agent Canvas can pin.

OpenHands AI triage

The following comments and acceptance criteria were added by the OpenHands AI agent.

Triage

Verified on main (2da02a5) and in released 1.18.0: CreatePromptAutomationRequest and CreatePluginAutomationRequest (preset_router.py) set extra="forbid" and omit agent_profile_id, so POST /v1/preset/prompt and /v1/preset/plugin reject it with 422. UpdateAutomationRequest and the PATCH path accept and persist it, and the dispatcher sets AUTOMATION_AGENT_PROFILE_ID (dispatcher.py:356), but the only reader of that variable anywhere is tests/test_dispatcher.py — both preset sdk_main.py scripts build get_default_agent(llm=..., cli_mode=True, ...) and never consult it. The field is therefore accepted on update and silently dropped at run time.

Scope: make the two preset endpoints accept agent_profile_id consistently with raw create and PATCH, and make a preset run apply the selected profile (profile-resolved tools, prompt, MCP servers, and LLM) to the launched conversation, with a visible failure when the profile cannot be applied. This reuses the repository's authoritative profile mechanism (ensure_agent_profile_exists / validate_agent_profile_combination for selection, and agent_profile_id + AUTOMATION_AGENT_PROFILE_ID for dispatch) rather than adding a new profile loader. A profile owns its model, so agent_profile_id and model remain mutually exclusive, matching raw create.

Non-goals: the factory/automation branch work (#453) and its preset FinishTool hook follow-up (#457) are not in scope here — this issue is the main-and-release behavior; no UI/Canvas change (tracked in OpenHands/OpenHands#17960 / #17971); no new agent-profile schema, tool, or MCP plumbing; no change to raw /v1 automations beyond keeping preset acceptance consistent with them.

Actual Behavior

Adding agent_profile_id to a POST /v1/preset/prompt or /v1/preset/plugin request returns 422 "Extra inputs are not permitted". Setting it with PATCH is accepted and stored, and the dispatcher exports AUTOMATION_AGENT_PROFILE_ID, but a preset run still launches the default agent: the conversation gets the default tools (terminal, file_editor, task_tracker) and launched_agent_profile is null. No error or warning reports that the profile was dropped.

Desired Behavior

A prompt- or plugin-preset automation that selects agent_profile_id runs through that profile: the launched conversation reports launched_agent_profile matching the selection and offers the profile's tools, prompt, MCP servers, and LLM. Create and update agree on accepting the field (and on rejecting a combined agent_profile_id + model). If the profile cannot be applied at run time, the run fails visibly instead of falling back to the default agent.

Acceptance Criteria

• POST /v1/preset/prompt and POST /v1/preset/plugin accept an optional agent_profile_id, store it on the created automation, and return it in the response (parity with POST /v1 and PATCH /v1/{id}).
• Both preset create endpoints reject agent_profile_id combined with model with the same error as raw create, and an unknown profile is rejected the same way raw create rejects it.
• POST /v1/validate with endpoint: "/v1/preset/prompt" (and /v1/preset/plugin) treats agent_profile_id as valid input and reports a missing or conflicting profile as a field-level validation error, consistent with endpoint: "/v1".
• A prompt-preset run whose automation has agent_profile_id set launches a conversation with launched_agent_profile equal to that id, and the conversation's available tools match the profile's tool selection (verified live, e.g. in Agent Canvas against agent-server).
• The same holds for a plugin-preset run with agent_profile_id set.
• When the selected profile cannot be resolved or applied at run time, the run fails with a visible error (non-success run status and/or an error surfaced to the caller) rather than launching the default agent; no silent fallback occurs.
• An automation with no agent_profile_id continues to run with the existing default-agent behavior (no regression to the model-profile path).
• A regression test asserts that both preset sdk_main.py scripts apply the profile rather than only the model profile, and a test covers create/update parity for the preset endpoints.
• The fix is included in a released version that Agent Canvas can pin.