<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=604458) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=604458) </details> <!--IssueSummary end--> ## Problem Duo struggles when it operates on large repositories — `gitlab-org/gitlab` being the worst case. The default flow assumes a checked-out working tree: the agent clones the repo (or works in a pre-cloned sandbox), then uses on-disk file tools. On a monorepo that means a ~1 GB+ clone, ~100k+ files, and tens of seconds of setup before the agent does any useful work — for tasks that often only need a handful of files. We don't actually know how much context most agent tasks require. Some need a single file. Some need a dozen. Some need a few hundred. A few need the whole repo. Today we pay the whole-repo cost regardless, and we have no data to tell us which regime each task falls into. ## Proposal Integrate the [`ws` CLI](https://gitlab.com/jcaigitlab/workspace) into Duo Agent Platform as an alternative to a cloned working tree, and **dogfood it** to collect data on how agents actually use repository context. `ws` is an agent-native overlay built on top of existing GitLab REST APIs (no server-side changes). It lets an agent: - **Browse a repo at a ref without cloning** — `ls`, `tree`, `cat`, `grep` fetch on demand and cache; no working tree on disk. - **Accumulate edits in a local overlay** that never touches a branch, preview with `ws diff`, and fold into a single commit with `ws checkpoint`. - **Ask the code graph structural questions** — `def`, `callers`, `calls`, etc. - **Materialize a subset to disk** only when an external tool (compiler, language server, test runner) genuinely needs real files. Every command emits machine-readable output (`-F json`), so it's built for an agent consumer, not a human. Early A/B measurements (identical task, `ws` overlay vs. `git clone` baseline) on GitLab's monorepos: | Task | `ws` footprint / time | clone baseline | |---|---|---| | Rename a method across `gitlab-org/gitlab` + commit | ~168 KB / ~4 s | 1.1 GB (100k files) / ~26 s | | Find 22 definitions in Chromium | 0 bytes / ~3 min | 6.2 GB / ~7.5 min | | Rename a function across Chromium | ~0 / ~109 s | 6.2 GB (469k files) / ~587 s | Both approaches produced the same correct result; the difference is footprint and wall-clock. ## What we want to learn The core hypothesis: **agents choose the most efficient path available to them, and the right path depends on the task's context footprint.** We want data, not assumptions. By giving Duo the `ws` toolset alongside (or instead of) the clone-based tools and instrumenting its choices, we can answer: - How many files does a typical Duo task actually read before it acts? What's the distribution — single file, ~dozen, ~hundreds, whole-repo? - When an agent has both no-clone and clone-based tools, which does it pick, and for what kinds of tasks does it fall back to materializing files? - Where does the no-clone overlay break down (the cases where the agent *needs* real files: running tests, language servers, `grep -r`)? - What's the latency / footprint win in aggregate across real Duo traffic, not just hand-picked A/B tasks? ## Scope (initial) - Wire `ws` into the Duo executor sandbox: inject connection env (`GITLAB_HOST`, `GITLAB_API_PROTOCOL`, `GITLAB_REPO`, OAuth token + `GLAB_IS_OAUTH2`), build `ws` from source in the workflow image. - Override the developer system prompt's `tool_instructions` / `environment_details` so the agent uses `ws` for read/edit instead of assuming a checked-out tree, and knows it's pre-authenticated. - Instrument tool usage to capture the metrics above (files read, tool chosen, fallback to materialize, latency, footprint). - Run on a controlled set of tasks against `gitlab-org/gitlab` first, since that's where the pain is sharpest. Some example MRs: 1. [Example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/242628) of incorporating the ws cli into duo developer workflow 2. [Example MR](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/5985) of using ws cli through a prompt ## Out of scope - Replacing the clone-based flow as the default — this is a measurement/dogfood experiment first. - The server-side workspace API (ambient commits, server-side rebase/conflict resolution, incremental delta tracking). `ws` is a client-side overlay; those gaps are documented separately and inform a future server-side API, but aren't required here. ## Success criteria - Duo can complete representative read and edit tasks on `gitlab-org/gitlab` via `ws` with no clone, end to end. - We produce a dataset / report on the distribution of context footprint across Duo tasks and the agent's tool-selection behavior. - Clear recommendation on whether/when no-clone access should become a default path for Duo.