GitLab 19.3 turns plain-English process knowledge into runnable agentic flows

GitLab 19.3, released August 20, adds Flow Creator to the GitLab Duo Agent Platform. Custom Flows were already generally available in 19.2, but creating one required learning GitLab’s Flow Registry schema and writing the definition manually. Flow Creator moves that authoring step into an agent: a user describes a software-delivery automation in plain English and receives a complete flow definition ready to paste into the configuration editor and register. GitLab says the agent consults current documentation before every response, applies rules based on common flow failures, and runs a pre-output checklist for problems such as missing project IDs, broken human gates, bad response targets and missing stopping instructions.

The material change is who can encode an operational process. A release manager, security engineer or platform owner who understands a workflow but not GitLab’s agent YAML can now produce a first runnable definition without handing the process to a schema specialist. That can make repeatable agentic automation easier to spread beyond individual AI-tool users. It does not make generated flows self-governing: maintainers still decide whether to enable them, choose triggers and visibility, and the runtime remains constrained by GitLab’s service-account/composite-identity model and other agent controls. Builders should treat Flow Creator as an authoring accelerator for governed automation, not as permission to run arbitrary natural-language instructions unattended.

GitLab 19.2 moved Custom Flows to general availability, letting teams encode multi-step agent workflows that run from GitLab events and CI/CD. Flow Creator addresses a different bottleneck: producing the flow definition. Instead of starting from the registry schema, an operator can describe the desired sequence and receive a full definition rather than a fragment that still needs assembly.

GitLab says Flow Creator reads the current Flow Registry documentation before each response instead of relying only on model training. It also applies rules derived from real failure modes and performs a checklist before emitting YAML. The checks target operational mistakes including an absent `project_id`, approval gates that do not actually pause, incorrect `sends_response_to` targets and agents that lack explicit stopping instructions.

The output still goes through the normal flow-management path. A maintainer or owner registers/enables the flow, selects triggers and chooses whether it is private, restricted or public. Group owners and instance administrators can disable Custom Flows entirely. That separation between authoring and activation is important: natural-language access widens who can propose automation without automatically widening who can deploy it.

Custom Flows use GitLab’s composite identity model when they execute. The agent acts as a service account on behalf of the triggering human and receives the more restrictive intersection of their access. GitLab documents this as a way to prevent the agent from gaining permissions that neither side has while preserving an audit trail that distinguishes automated actions from direct human actions.

Flow Creator checks whether a requested human-in-the-loop gate is structurally present, but that does not prove every consequential action is gated appropriately. GitLab’s security documentation distinguishes execution modes and tool-governance behavior, so teams still need to decide where approvals, stopping conditions, tool restrictions and network boundaries belong. A syntactically runnable flow can still encode a bad operating policy.