## :iteration: Decisions | Date | Decision | Context | |------|----------|---------| | 2026-09-25 | Two release gates: dogfood (opt-in, low bar) and internal (customer 0, PM sign-off). Supersedes 09-17 POC agreement. | [thread](https://gitlab.slack.com/archives/C0C1049HT28/p1790338081747339) | | 2026-09-25 | Slack tool approval lands under Web Access. Naming/categorisation feedback tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/629377. | [thread](https://gitlab.slack.com/archives/C0C1049HT28/p1790338081747339) | | 2026-09-25 | Inner-monologue redesign (https://gitlab.com/gitlab-org/gitlab/-/work_items/613296) and approval-placement work proceed in parallel; neither blocks the other. | [thread](https://gitlab.slack.com/archives/C0C1049HT28/p1790338081747339) | | 2026-09-17 | Review-button + modal is acceptable for the POC; not the shipping UX. Alternatives to be prototyped. | [thread](https://gitlab.slack.com/archives/C0B4V7TJPG9/p1789583830510939), [MR note](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255537#note_3844728510) | ## Problem Duo in Slack runs the Duo Developer flow, on CI, under composite identity. That flow was never meant for this, and three problems follow: 1. **Slow.** Every mention starts a CI job — runner pickup, image pull, repository clone, CLI install — before the agent says a word. 2. **Bound to one top-level group.** Composite identity ties the run to a service account in a single group. A user whose default namespace is `gitlab-com` cannot create an issue in `gitlab-org`. Instances with several top-level groups cannot make this work at all. This is our biggest source of user friction. 3. **Needs a project.** CI needs a repository, so we created the `duo-workspace` dummy project. It confuses users and adds a moving part. Most Slack requests are read, search and create-issue work, or delegating a bigger task to a specialised flow. None of that needs a coding environment. ## What we want Duo in Slack runs a lightweight, API-only agent that: - **acts as the user**, so it can do whatever the user can, in any top-level group, and artifacts are attributed to the user; - **starts in seconds**, without a CI runner or a repository; - **needs no dummy project**; the session hangs off a namespace; - **asks before acting when the admin says so**, using the same governance rules as agentic web chat, with approve/deny in Slack; - **delegates coding work to Duo Developer** and hands the user a link to that session. Responses keep arriving where the question was asked, through the messaging adapter that Slack, `@GitLabDuo` mentions and webhooks already share. ## How we get there Three pieces and a cutover. Detail, work split and the reasoning behind each decision are in the [investigation summary](https://gitlab.com/gitlab-org/gitlab/-/work_items/602541#note_3809589499). | Piece | What it gives us | |-------|------------------| | **A new API-only flow** | Our own flow definition behind a feature flag. Runs on CI from day one without clone or setup, so the agent already starts noticeably faster. | | **A headless runtime** | Rails asks workhorse to run the session and returns. No runner, no project, user identity, work across top-level groups. **This solves the actual problem.** | | **Approvals and delegation** | Approve/deny in Slack when a governance rule requires it. The agent can start Duo Developer and reply with the session link. | | **Cutover** | Remove the flag, the Duo Developer fallback and the dummy project. | The pieces land independently, in whatever order is fastest. The flow comes first because nothing is visible without it; the cutover comes last because it needs everything else. Approvals do not need to wait for the headless runtime, and the runtime does not wait for approvals. ## Out of scope - **Memory across mentions.** Mentioning the app again in a thread works as it does today: it starts a fresh session with the thread as context. What is out of scope is the agent remembering its previous session, and sending it messages while it is still working. Only an approval continues a session. Thread-to-session continuity belongs with the Slack agent-pane work and is tracked separately. - **Mirroring Duo Developer's output into Slack.** Delegation replies with a link to the delegated session. Surfacing its result back is a later iteration. - **Billing changes.** Credits work as they do today. ## Guiding principles - **Fastest path to a dogfoodable prototype.** UX decides if this is good or bad. - **Reuse what exists; add one piece.** The messaging adapter, the flow registry, the workhorse-to-DWS path and the governance rules all stay. The single new piece is a headless entry into workhorse that lets Rails start a run and return. We do **not** reuse the legacy chat engine; the flow lives in the same registry as Duo Developer. - **Nothing Slack-specific below the adapter.** Anything we add to the adapter or the runtime must serve @GitLabDuo mentions, webhooks and future surfaces too. - **User identity, not composite identity.** The agent runs as the user; admin governance rules and approvals provide the guard rails. - **Behind a feature flag with a kill switch.** Off means today's `developer/v1` path, so we can flip back at any time. Sits alongside `slack_duo_agent`, which gates Duo in Slack as a whole. ## Related - [Investigation and work split](https://gitlab.com/gitlab-org/gitlab/-/work_items/602541#note_3809589499) — the comment this epic is based on - [!246709](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/246709) — headless workhorse endpoint POC (Igor) - [!234471](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/234471) — earlier headless POC (Kinshuk) - [!247668](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247668) — Slack agent app; routes agent-pane messages through the same path