Why AutoFlow
GitLab CI/CD, the GitLab Duo Agent Platform and hand-rolled automation each solve a different problem, and AutoFlow replaces none of them. In one line each: CI/CD runs programs, the Agent Platform does interactive work with AI agents, hand-rolled automation glues one trigger to one reaction, and AutoFlow orchestrates processes that span time, projects and systems.
At a glance
| GitLab CI/CD | Duo Agent Platform | Hand-rolled automation | AutoFlow | |
|---|---|---|---|---|
| Built for | Building and testing software | Interactive, one-off tasks with AI agents | One trigger, one reaction | Automating DevSecOps processes |
| Runs | Containers, binaries, shell scripts | Agents you work with in a UI or IDE | Your own job, webhook receiver or cron script | Small Starlark programs, no containers |
| Waiting for days | A job holds a runner while it waits | A session ends with the task | State, timers and wake-ups are yours to build | sleep, timer and channels; a waiting workflow holds no resources |
| After a crash | Restart the job from the start | Rerun the task | Depends on what you wrote | Replays recorded history and resumes |
| Reaches | Anything a runner can reach | Whatever the agents can reach | Any API you code against | GitLab’s REST API and any system behind a module |
Compared with GitLab CI/CD
Use CI/CD when the work is running a program: a build, a test suite, a container, a shell script, anything that needs CPU or RAM. AutoFlow runs none of that. It adds the layer above: orchestrating pipelines across projects, manipulating GitLab objects through APIs when something happens, and waiting for an unspecified amount of time, possibly days or weeks, before proceeding.
The two differ in how they recover from an interruption. A CI job is restarted from the top, and whether that is safe depends on what the job did. A workflow resumes from its history, and every action it already completed returns its recorded result instead of running again.
Compared with the GitLab Duo Agent Platform
The names overlap, the problems do not. The Agent Platform used to be called Duo Workflow, and it has Flows where AutoFlow has workflow definitions; that is where the question comes from. It is interactive: you work with agents in a UI or IDE on one-off tasks such as understanding a codebase or planning an implementation.
AutoFlow is set-and-forget automation. A workflow runs unattended, and when it needs a person it waits on a channel for their answer rather than holding a conversation. Example: on the 15th of each month, kick off a release process, ping the release managers where a decision is needed, then create branches and tags and, 30 days after the release, lift confidentiality on the fixed issues.
The two combine. Where agent capabilities are reachable through GitLab’s API, a workflow can invoke them as one more step, for example to draft a summary comment on an issue that has seen no activity for 30 days. And a workflow definition is plain Starlark text, which an agent can author.
Compared with hand-rolled automation
Most teams already automate with a webhook receiver, a cron script or a background job such as a Sidekiq worker. That works well when one trigger produces one reaction that finishes in seconds. It strains as soon as the process spans time. A job that has to wait three days for an approval must persist its own state, schedule its own wake-up, deduplicate its own retries, and work out where it was after a deploy restarted it.
AutoFlow turns that machinery into engine guarantees. The workflow definition is straight-line code; sleep and gather express the waits; the history is the state. Retries carry a stable idempotency key, so the receiving system can recognize them.
Where AutoFlow fits
- Waiting for an unspecified time. Days or weeks for an approval, a soak period, a release date or a condition that
pollchecks on an interval. The wait costs nothing while it lasts. - Orchestrating across projects and systems through APIs. The
gitlabmodule reaches every project the caller’s token can see. Other systems are reached through modules, which is how new capabilities arrive. - Reusable, shared workflow blocks. Modules ship Starlark files alongside their actions, so a building block written once is one
load()away for every workflow definition. Self-serve sharing of workflow definition parts is a design goal, see Status and roadmap. - Durability. A workflow survives restarts, instance failures and network outages, and may run for weeks. Its lifetime is bounded: 30 days by default and 60 days at most, see Limits.