You choose a profile with delegation tools. The scheduled run cannot delegate. The proposal moves conversation creation to the backend that owns the profile, then makes the runner attach.
Use plugin-spec automations for the future prompt flow. Let the service launch the selected profile at dispatch. Keep OHE behind the tools-and-secrets fix. A matching profile ID alone cannot prove the right capabilities.
Reading guide to automation #600, including its 19 October decisions. The issue owns the proposal and reported reproduction. Older comments describe superseded designs.
A profile is a saved agent configuration: its model, tools and references. An automation selects work and a trigger. The runner is the process in the sandbox that sends the work to an agent conversation.
The selected profile never supplies the agent. The reported prompt run had four default tools and no task tool.
Profile ignored.
The runner does pass the profile ID. That works locally. On OHE, enterprise owns the profile; the sandbox does not have its record.
Profile cannot resolve.
Runner launch · automation b6fa62d · Store lookup · SDK 1.56.0
Sending the same UUID to a different server does not transfer the profile. The SDK launch request explicitly resolves it using that server’s own stores. Request contract ↗
Reported in #600 on 19 October: automation 1.21.0, agent-server 1.55.1. An interactive control offered five tools, including task_tool_set, and recorded the launched profile. A prompt-preset automation offered terminal, file_editor, task_tracker and FinishTool, with agent_profile_id: null and no profile tag. Supplying a profile to the preset API returned 422; asking the sandbox to resolve the enterprise profile returned 404. These are the issue’s test results, not tests rerun for this page.
Keep backend-specific launch knowledge in the automation service’s existing per-mode backends. Create the conversation once the run’s sandbox is ready. Pass its ID to the runner only after checking the launched profile.
POST /v1/plugin-spec accepts an optional profile ID. Validate it against the manifest’s exact allowlists. Without an explicit choice, use the manifest’s default_name.
Canvas defaults its picker to the user’s active profile at creation. Later active-profile changes do not silently switch this automation.
Re-check the stored profile against the allowlists. Launch via the owning backend. On enterprise, poll the start task for the conversation ID. Verify launched_agent_profile identifies the requested profile.
Pass AUTOMATION_CONVERSATION_ID; the runner uses RemoteConversation.attach(…). Follow-up runs reuse the subject conversation when it exists.
A stock conversation plugin receives the per-automation prompt through configuration. Canvas needs a plugin-spec create flow and profile picker. Legacy preset endpoints remain frozen and continue rejecting agent_profile_id.
Proposal, API fields, follow-up reuse and prompt options: #600 · Proposed solution / Design. Launch work: #601. Launch experience: #609.
Imagine a saved profile called Researcher that allows delegation. These cases illustrate the reported failures and proposed checks. They do not call any backend.
The profile never reaches agent construction.
The issue reports this failure for the prompt-preset run. A profile picker cannot fix a runner that builds its own agent.
The successful local trace is a target acceptance case, not a claim that the new dispatch path is implemented. #600 · Acceptance Criteria
Enterprise can stamp the right profile while constructing a different effective agent. According to #600’s source audit, its current path replaces the profile’s tools with defaults, drops its prompt suffix, and does not apply secret_refs.
Compare launched-profile identity with the requested ID. This detects a wrong profile or the reported fallback to composed settings.
Mismatch → stop before the runner starts.
Verify the model receives exactly the allowed tools and the intended secret scope. A correct ID tag cannot establish either.
Right ID + wrong tools is still a failed rollout.
The manifest’s “all and only these tools / secrets” promise cannot hold while enterprise replaces tools and ignores secret references. #600 treats #763 as a hard dependency. The unknown-profile fallback (#759) and worker secret boundary (#854) also need explicit attention.
These enterprise details are publicly described in #600 · Verified contracts / Known OHE limitations. Linked enterprise issues may require repository access. This page adds no private enterprise source excerpts.
Another distinction: saving a profile ID does not freeze its contents forever. The definition can be edited. Dispatch revalidation and recorded launch revision help explain what a later run actually used; immutable profile snapshots are not a stated requirement of this proposal.
The current plugin-spec runner prepares nothing before creating the conversation. The service already knows the mode, sandbox and user identity. Moving creation there puts failures before runner execution without adding a runner-to-service launch endpoint.
| Option | Attractive because… | Trade-off / current decision |
|---|---|---|
| Chosen: service creates at dispatch | One backend-specific launch boundary; runner only attaches. | Requires a new backend method and provenance check. Keeps existing runner reporting. |
| A · Repair presets | Fixes today’s prompt UI path sooner. | Invests in a path being frozen; also needs finish-policy contracts that plugin specs do not need. |
| B · Runner requests creation from service | Allows workspace preparation first. | There is no such preparation today. An extra endpoint and round trip buy little. |
| C · Runner calls the profile owner | Avoids changing service-side launch. | Duplicates local/cloud API knowledge in runners; uses the user key from the sandbox. |
| D · Service drives everything; no runner | Avoids per-run SDK installation. | Completion, watchdog and progress currently assume a sandbox process. Possible later simplification. |
Either an extensions plugin with arguments rendered from config, or a built-in plugin shipped with the automation service. Both preserve the chosen plugin-spec path.
The plugin-spec runner has no finish hook. Structured TaskOutcome and an independent LLM override are outside this change. The agent profile owns the model.
#600 evolved through four designs: service-driven API execution → runner calls the owner → runner requests creation from the service → service creates at dispatch for plugin specs. The fourth design is the current issue body. The run-conversation endpoint in older discussion is alternative B, not another step in the chosen design.
All options and decisions: #600 · Alternatives considered / Decisions / Revision history.
Implement dispatch creation, attachment, optional profile choice and the prompt plugin. Give every user a usable profile. No enterprise dependency.
Release enterprise #763 and bump it in the chart. Verify exact effective tools and secret scope before enabling the profile-based path.
| Boundary | Work to land | Tracking |
|---|---|---|
| Automation service → conversation owner | Per-backend creation, provenance check, runner attachment; optional selected profile; stock prompt plugin. | #601 · #600 |
| Canvas → automation API | Plugin-spec creation and profile picker; hide the misleading preset pill; show cloud tools editor. | #609 · #18569 · #18656 |
| Profile → effective agent | Usable profile seeding; tools/secrets fidelity and fail-closed enterprise launch. | SDK #5982 · enterprise #763 / #759 / #854 (see #600) |
| Environment | Automation | Plugin-spec API |
|---|---|---|
| Beta | 1.21.0 | Available |
| OHE 0.81 | 1.19.1 | Not yet |
| OHE 0.82 / 0.83 | 1.21.0 | Available |
| SaaS | 1.19.1 | Not yet |
API availability does not mean the proposed fixes or Canvas flow have shipped. The issue audits automation main at 1.22.0 and SDK 1.56.0 separately from those deployed versions. Treat this as a dated report, not live telemetry.
Can a run show both which profile revision launched and which capabilities the model actually received? Keep those as separate pieces of evidence. That catches both the wrong-owner bug and the right-tag/wrong-agent bug.
Acceptance and rollout are taken from #600 · Work breakdown / Acceptance Criteria. The final review question is this walkthrough’s synthesis.