> **TL;DR:** Foundational agents started over MCP (gitlab-org/gitlab!257062) run as CI workloads, although agents never ran in CI anywhere else. Move them onto the Workhorse runtime Slack already uses (`ExecuteRunService`), and remove the CI-only assumptions !257062 had to add. Flows that need the repository stay on CI. ## Why Every session `start_duo_session` creates gets `start_workflow: true, environment: 'ambient'`, so it runs in a CI job. For flows that need a checkout that is right. For agents it is not: in web chat they run without CI, and the assumption for MCP was the same; it was just never written down ([discussion](https://gitlab.com/groups/gitlab-org/-/work_items/21395)). Running agents in CI costs us: - **Latency.** On GitLab.com each turn spent 7–13 minutes cloning `gitlab-org/gitlab` before the agent started, and every reply or resume is a new turn ([walkthrough](https://gitlab.com/groups/gitlab-org/-/work_items/21395#note_3928788161)). - **CI-only assumptions in the agent path.** !257062 had to add rules that only exist because the agent runs in CI (checklist below). They make agents over MCP behave differently from agents everywhere else, and every feature built on them makes the later move harder. ## What already exists From the Duo for Slack work (gitlab-org&23521): - `Ai::DuoWorkflows::ExecuteRunService.new(workflow, event:, runtime: :ci | :workhorse)` (#628435): starts or continues a run, picks the runtime from the flow's coding environment unless the caller overrides it, and on a continuation uses the session's `last_runtime`. - `ServerSideExecutionService` + `Ai::Messaging::ServerSideTurnWorker` (#628429): Workhorse runs the turn via `POST .../workflows/:id/execute`, as the user (no service account), with the same `FoundationalFlowStartParamsResolver` flow config the CI path uses. - The worker only delivers through a messaging adapter when the session has a `messaging_callback_context`, so an MCP session (none) is left for the caller to poll with `get_duo_session`. - Slack switched over in !256183, behind `slack_duo_api_flow`. ## Proposal Behind a new feature flag, for foundational agents only: 1. **Start.** For `agent:` sessions, create the session and start it with `ExecuteRunService(..., runtime: :workhorse)` instead of `StartWorkflowService`. Use the chat-style `environment` the Workhorse path expects, not `ambient`. 2. **Resume.** Route `send_duo_session_input` for these sessions through `ExecuteRunService` with an `input` or `approval` event. It resumes on the session's `last_runtime`, so CI sessions keep their current path. 3. **Coding environment.** Foundational chat agents are not in the `FoundationalFlow` registry, so `Ai::Catalog::CodingEnvironment.resolve` returns the default `full`, which Workhorse refuses. Declare them `none`. 4. **Undo the CI-only rules** below for Workhorse sessions. 5. **Polling.** Give Workhorse sessions a short poll hint in `get_duo_session`; the 120 s "waiting for a CI job" hint does not apply. ### CI-only assumptions from !257062 to undo - [ ] Resuming an agent session requires `execute_duo_workflow_in_ci` and a completed workload pipeline (`resumable?`). A Workhorse session has no workload. It needs its own rule: awaiting input and no turn in progress (Workhorse already rejects a concurrent turn with `409`). - [ ] `list_duo_agents_and_flows` marks agents unstartable when the project cannot run in CI (remote flows off). Web chat agents do not depend on that setting. Gate on the same permission agentic chat uses. - [ ] `start_duo_session` refuses agents when `enforce_composite_identity_for_api_started_workflows` is on, because they have no service account. On Workhorse the run acts as the user, so this refusal does not apply. - [ ] Resume maps the decision onto executor CLI flags (`--approval false --rejection-reason`). Workhorse takes the protojson `approval`; `ExecuteRunService` already translates. - [ ] `send_duo_session_input` waits for "the last CI job has finished", which causes the ~1 minute race between `input_required` and the job ending. Not relevant on Workhorse. - [ ] The 120 s poll hint (see Proposal 5). ## Open questions - **Resume authorization without a CI workload.** The policy change needs an authorization review (the same reviewers as !257062). - **Worker capacity.** `ServerSideTurnWorker` holds a Sidekiq thread for the whole turn and has `concurrency_limit -> { 50 }`, shared with Slack today. Does MCP get its own limit or worker? - **Project or namespace.** Workhorse sessions can hang off a namespace. That would let journey 3 (a support question about the instance) start without a project. Keep project-only first? - **Coordination with #629005**, which moves all server-side starters onto `ExecuteRunService`, and with the planned move of the worker out of `Ai::Messaging`. ## Out of scope - Flows that need a repository (Developer, `fix_pipeline`, and so on): they stay on CI. - Custom flows that declare `coding_environment: none`: same mechanism, separate follow-up. - Flow configurations for the agents that cannot run yet (Planner, Security Analyst, CI Expert, Support Assistant): they fail with `Failed to load flow` on either runtime. - Custom agents over MCP. ## Acceptance criteria - [ ] With the flag on, an `agent:` session over MCP starts and answers without a CI job, and `get_duo_session` returns the answer. - [ ] `send_duo_session_input` continues it without a CI job, for both a reply and an approval. - [ ] Every item in the checklist above is removed or does not apply for Workhorse sessions, with specs. - [ ] With the flag off, behaviour is unchanged. - [ ] Docs explain that agents run without CI and flows that need the repository run in CI. ## Rough size About 3–4 MRs: coding environment for agents (small); start and resume through `ExecuteRunService` (medium); policy for resuming without a workload (medium, authorization review); list, poll hint and docs cleanup (small). The policy review and worker capacity are the main schedule risks. ## Links - !257062 (agents over MCP on CI), #617174 - #628429, #628435, !256183, gitlab-org&23521 (Workhorse runtime for Slack) - #629005 (consolidation) - `ee/app/services/ai/duo_workflows/execute_run_service.rb`, `ee/app/services/ai/duo_workflows/server_side_execution_service.rb`, `ee/app/workers/ai/messaging/server_side_turn_worker.rb`, `ee/app/models/ai/catalog/coding_environment.rb` Part of gitlab-org&21395