GitLab Duo Agent Platform: Agents, Flows, and Governance

GitLab Duo Agent Platform brings foundational, custom, and external agents into GitLab workflows, with repository context and governance controls close to issues, merge requests, and CI.

This guide focuses on the engineering decision behind GitLab Duo Agent Platform: what to standardize, what to constrain, and what evidence a reviewer should expect before accepting the result.

The core decision

GitLab distinguishes individual agents from flows that combine agents for larger developer tasks. Its documentation also describes tool-governance, audit, and composite-identity concepts, which matter when agent activity must remain attributable to the initiating human and a service identity.

A workflow that holds up in review

Begin with one low-risk workflow and a narrow tool set. Put project guidance in AGENTS.md, keep merge requests under existing approval rules, and test how identity appears in commits, audit events, and protected operations before expanding to custom or external agents.

The failure mode to design around

A broad platform rollout can obscure which capability produced a change. Name the agent or flow in the handoff, preserve its session evidence, and separate experiments from production-approved workflows.

Implementation checklist

Choose foundational, custom, or external agents deliberately.
Map tools to least-privilege policies.
Verify attribution and audit events.
Keep normal merge-request controls in force.

Turn the checklist into operating controls

Choose foundational, custom, or external agents deliberately: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Map tools to least-privilege policies: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Verify attribution and audit events: name the owner, the evidence that proves it happened, and the condition that should stop the run.
Keep normal merge-request controls in force: name the owner, the evidence that proves it happened, and the condition that should stop the run.

The list becomes useful when every item produces visible evidence. Store that evidence with the task or pull request rather than in a private chat. A future reviewer should be able to tell which repository revision was used, which permission profile applied, what stopped or failed, and who accepted the remaining risk. For GitLab Duo Agent Platform, a short, complete record is more valuable than a long narrative that cannot be reproduced.

Move from one run to a repeatable practice

Run the same task packet on a stable starting commit before changing platform policy. Capture setup time, interventions, final diff, validation evidence, and reviewer minutes. Repeat a failed task after fixing only the documented environmental cause; this separates platform capability from a broken repository path. Keep the result dated because product availability and controls move quickly. A defensible platform decision explains both the winning use cases and the cases the team will keep elsewhere.

Before expanding the workflow, ask three review questions:

What evidence shows that choose foundational, custom, or external agents deliberately was satisfied, and would that evidence survive a rerun from the recorded commit?
What evidence shows that map tools to least-privilege policies was satisfied, and would that evidence survive a rerun from the recorded commit?
What evidence shows that verify attribution and audit events was satisfied, and would that evidence survive a rerun from the recorded commit?

Write the answers in the same place as the code review. That creates a compact decision record and lets the team compare later runs without relying on memory.

A practical acceptance test

Run the workflow from a clean checkout at a recorded commit. Give the agent only the documented task packet and the intended permission profile. Then ask a reviewer who did not launch the run to reproduce the important checks, explain the changed behavior, and identify the rollback path. The task passes only when the artifact, evidence, and repository state agree. Keep the failed examples as regression cases; they are more useful than a polished demo because they reveal where instructions, environment, permissions, or tests need improvement.

Primary references

Vendor features, limits, preview labels, and pricing can change. Recheck the linked first-party documentation for the current state before making a purchase or rollout decision.