In a blog post this week, GitLab put a name on the abstraction it wants delivery teams to build around: Duo Agent Flows, packaged multi-step runs meant to carry the same access controls, triggers and review gates as any other pipeline object. If your team already runs on GitLab, the practical question is smaller than the announcement: what does an agent get to do on your repo when nobody is watching, and can you audit it the same way you audit CI?
What GitLab is naming
Per the post, an agent flow is a named, multi-step run that GitLab manages the same way it manages other platform work. The three example flows GitLab calls out are ordinary delivery chores dressed for an agent: implement an issue, fix a pipeline, and review a merge request. Each chains several steps into one unit with a defined entry, a defined exit, and a place in the platform's permission model.
The framing GitLab gives is worth quoting in the vendor's own terms. Chat that only answers still leaves every handoff to the user. Homegrown scripts don't inherit changes in access controls, new triggers or updated review gates when the platform ships them. A flow is meant to sit between the two: a repeatable unit the platform wraps in the same controls it applies to everything else on the review path.
