GitLab

AI coding tools have changed how fast software gets written, but not how fast it ships. As code generation accelerates, the bottleneck moves downstream into verify, review, and ship. Those stages still run on human time. While agents write fixes in minutes, delivery slows on constant wait times and manual handoffs. Reviewer signoffs, pipeline alerts, scan triage, and step-by-step prompting are examples of obstacles DevOps teams face in maintaining on-time delivery. At GitLab Transcend, we announced new agent orchestration capabilities in GitLab Duo Agent Platform to eliminate that delay. Goal-driven flows take the outcome you define and run it end to end, through review, tests, security scans, and approvals from Duo CLI, headless mode, or Agentic Chat. GitLab for Slack starts work from the conversation where it was requested, like turning a thread into an issue or kicking off a flow to fix a failing pipeline. Custom Flows let you define your own multi-step sequences and start them from GitLab events like a mention, an assignment, or a pipeline. All three run under your identity, policy, and evidence chain. ## How agentic orchestration speeds up delivery Faster coding, process checklists, and single-chat coding agents all contribute to delays in software delivery. With agentic orchestration capabilities, you can accelerate each stage and reclaim time for your development team. Fewer handoffs. You name the goal, and the flow keeps working across review, tests, scans, and approvals instead of stopping between each step. Start work where the request already is. A Slack thread becomes an issue or a flow immediately from where you’re already discussing the work. Automate the process your team already follows. Custom Flows let you define your own multi-step sequences and start them from a mention, an assignment, or a pipeline. Stay in control. Flows run under the same identity, policy, and evidence chain as the rest of GitLab, so governance stays with the work. Foundational agents and flows already cover plan through analyze stages in the GitLab UI, your IDE, and Duo CLI, and you can enable more from the AI Catalog, bring in external agents, and connect tools through the MCP client and the MCP server. ## Goal-driven flows: Set your objective Goal-driven flows give agents the finish line instead of the next step. You describe the objective and what done looks like, and the flow keeps working until it gets there. Goal-driven flows automate handoffs, so review, tests, security scans, and approvals run as one connected sequence. You start one with the /goal command, for example: /goal Fix the checkout timeout. Continue until tests pass and CI is green. A separate model checks the work against your goal at each step, and you can stop or redirect a run at any point. You can start a goal-driven flow in Duo CLI, in headless mode with duo run --goal, and in Agentic Chat. ## GitLab for Slack: Start where the work gets discussed GitLab for Slack lets you start work in GitLab without leaving Slack. Mention @GitLab in any channel or thread and describe what you need, such as "fix the failing pipeline," and a flow starts. Duo streams its progress back into the thread, so your team follows the work where the conversation is already happening. The flow runs under the same identity and policy as any other GitLab flow, so governance stays in GitLab. You can also use @GitLab to ask questions about your codebase or create an issue from the conversation. ## Custom Flows: Turn your process into a flow Custom Flows chain agents together to match the process your team already follows. You define a flow once, start it from GitLab events like a mention, an assignment, or a pipeline, and run it in CI/CD pipelines. A self-healing pipeline, for example, can analyze a failed test, generate a fix, commit it, and notify your team, with human-in-the-loop checkpoints at sensitive steps. Each flow runs under the same identity, policy, and evidence chain as every other flow, so governance stays in GitLab. ## Put agent orchestration to work To achieve the benefits of agent orchestration, start with goal-driven flows. The documentation for Duo CLI slash commands walks you through /goal. Goal-driven flows are available on GitLab.com, GitLab Self-Managed, and GitLab Dedicated, on the Premium and Ultimate tiers, and require GitLab 19.3 or later and Duo CLI 9.17.0 or later. Then extend that orchestration to your team's processes and channels with Custom Flows, which are generally available, and the MCP server and GitLab for Slack, which will be generally available later this month. To design the foundation for your software factory, check out GitLab Duo Agent Platform. New to GitLab? Start a free trial of GitLab Duo Agent Platform. Already on Premium or Ultimate? Turn on GitLab Duo Agent Platform and use the GitLab Credits included with your subscription.

Costs multiply with every task you hand to an agent. Each task consumes tokens and credits, and as agents spread across your teams and automations, consumption can grow faster than usage. If you run the platform, you own that growth, including which teams and workflows drive it and whether the usage ships work. At GitLab Transcend, we introduced the governed software factory, our architecture for agentic software engineering, and new capabilities in GitLab Duo Agent Platform that bring that growth under control. GitLab-managed open-weight models matched frontier-model task completion at a fraction of the cost in GitLab's benchmark, so you can align your model to the task to improve your team’s cost efficiency. GitLab Orbit gives agents lifecycle context so they retry less. Duo Agent Platform Impact Analytics and credit caps show where credits go and put a limit on them. ## Control costs in the governed software factory A usage total tells you what you consumed, and leaves hard questions open: how much routine work sat on an expensive model, how many agent runs were wasted retries, and which users and teams burned through the credits. When the dashboard only shows tokens, platform and engineering leaders end up debating a number neither side can stand behind. If you can't attribute the usage, set a limit, and cut the waste, you can’t optimize or justify your spend. Breaking that pattern starts with the architecture. The governed software factory is built in layers, and cost grows where those layers don't connect. Two of those layers matter most for cost. The first is agent orchestration, where open weight models put routine work on lower-cost models. The other is data and context, where Orbit, Duo Agent Platform Impact Analytics, and credit and usage controls give humans and agents the context to produce high-quality outcomes at the lowest possible cost. You can see the problem in a shadow software factory, where each stage has its own tool, with no shared policy or context between them. Agents spend tokens searching for context across systems that were never built to integrate. A governed software factory gives agents shared context, shared policy, and one place to measure what they cost. When every AI credit counts, you can: - Spend fewer credits for the same work: Match models to the task at hand with open weight models, and ground agents in lifecycle context with GitLab Orbit so they retry less. - Trace spend to its source: See credits by user, team, task, and model in Duo Agent Platform Impact Analytics and the GitLab Credits dashboard so you can point to what drove the growth. - Set a ceiling before the next spike: Cap usage per user with credit caps, with overrides where needed, so agent loops stay inside the limits you set. ## Match the model to the task Agent cost starts with the price of each model call. GitLab Duo Agent Platform lets you pin a default per feature and control what your teams can use: your own model, self-hosted or from your provider, GitLab-managed frontier models, or GitLab-managed open-weight models, new in GitLab 19.4. Three open-weight models are now hosted in GitLab Duo Agent Platform: GLM 5.3, Kimi K3, and MiniMax M3. In GitLab's internal benchmark with Duo agents, GLM 5.3 matched Claude Opus 5's task completion at approximately one-fifth the cost, Kimi K3 matched Claude Fable 5.1 at one-third the cost, and MiniMax M3 matched GPT-5.5 at one-eighth the cost. Model choice is an admin setting. In your top-level group's GitLab Duo settings, open Model Selection, select Manage Models, and pin a model to each feature. For example, pin Kimi K3 to Agentic Chat and MiniMax M3 to agents and flows, so routine work does not default to a frontier model. Group Owners also choose which models their teams can use. ## Cut retries with the right context Model choice sets the price of each call, and retries multiply the number of calls. Gartner found that a team of 40 developers spent 23 times more on AI because agents kept retrying without the right rules and context. Agents retry when they lack context. Across a monorepo or several repositories, an agent spends its first stretch crawling files to work out what connects to what, and every retry resends the full context window. GitLab Orbit maps your code, work items, merge requests, pipelines, deployments, and security findings into a single graph that stays current as your teams ship. Agents in GitLab Duo Agent Platform query it natively. External agents like Claude Code and Codex connect through Model Context Protocol (MCP), and custom tooling connects through the REST API. Every agent sees exactly what its user can see in GitLab. With that context, an agent asks the graph and gets a precise answer faster and more efficiently. In GitLab testing, the same task in Claude Code needed up to 45x fewer retries with Orbit and, separately, used 4.5x fewer tokens to get the right context the first time. Orbit is in free beta on GitLab.com today and reaches general availability next month across all deployment options. ## Manage what you can measure Models and context lower the cost of each task. Impact data shows whether it worked. Duo Agent Platform Impact Analytics answers the two questions platform leaders ask: how much are we spending, and where is that spend concentrated? It breaks spend down by team, task, and model for the teams and date range you choose, and it shows how an open weight model stacks up against your current model mix, so you compare with data instead of guessing. The GitLab Credits dashboard adds detail below the team level, tracing usage to the user and session behind it. Visibility pairs with limits. Without a limit, the only lever left is asking everyone to use less. Credit and usage controls set caps at the subscription, group, or user level, with alerts at 50%, 80%, and 100% of spend and an automatic pause once usage reaches the cap. A flat per-user cap, such as 1,000 credits per user/per month, applies to every team member, and an individual override, such as 500 additional credits, gives an engineer who is experimenting room to work without asking for more. Per-user caps apply once a user has consumed their included credits, and only the capped user loses access to credit-consuming features, until the next billing period or until an administrator raises the cap. Duo Agent Platform Impact Analytics shows credit consumption alongside the work that reaches production, so you can see whether usage is turning into delivered work. See Duo Agent Platform Impact Analytics in action in this demo from our Transcend global event: ## Put agent cost control to work Start your agent cost control journey with the model. GitLab-managed open-weight models are generally available. In Model Selection pin GLM 5.3, Kimi K3, or MiniMax M3 to a routine workload, such as a flow that runs on every merge request. Next, cut retries. GitLab Orbit is in free beta on GitLab.com today. Turn it on for the group that runs the most agent sessions. Orbit reaches general availability next month across all deployment options. Then, measure and set limits. Duo Agent Platform Impact Analytics is in early access, so you can see spend by team, task, and model. Credit and usage controls are generally available. Set a per-user cap for GitLab Credits with overrides for your heavy users. After a few weeks, compare usage by team and model against the previous period. Design the foundation for your software factory with GitLab Duo Agent Platform. If you're new to GitLab, start a free trial of GitLab Duo Agent Platform. If you're on Premium or Ultimate, turn on GitLab Duo Agent Platform and use the GitLab Credits included with your subscription.

If you run application security across more than one top-level group, getting a single organization-wide view of your risk has meant manually pulling together data. That is operational work rebuilt in spreadsheets and one-off scripts every time someone asks. This manual work is easy to get wrong, and is often out of date the moment it is published. Every hour spent assembling that view is an hour your security team is not spending on strategic work to drive down risk. With GitLab 19.4, the security dashboard now gives you a consolidated view of risk at the organization level. Across every top-level group and every scanner your teams run, you can see how your whole application security program is doing, find where the real risk is concentrated, and act on it, without stitching anything together by hand. Your team spends its time remediating vulnerabilities instead of assembling reports, and when leadership or an auditor asks where the organization stands, you have a current, defensible answer on one screen. The organizational level security dashboard is available in beta for GitLab.com users. ## See total risk, then triage down to the project The risk score quantifies the risk level across the entire organization. This score is calculated based on the severity and age of your open vulnerabilities, whether each one appears on the Known Exploited Vulnerabilities (KEV) list, and its Exploit Prediction Scoring System (EPSS) score. The risk score helps security leaders prioritize what area of the organization is most susceptible to threats, rather than a raw count that treats every finding as equal. The charts around the risk score also proactively answer follow-up questions. The Vulnerabilities over time view shows whether risk is trending up or down across the organization over 30, 60, or 90 days. Vulnerabilities by age shows what is going stale and slipping past your remediation targets. Open vulnerabilities by severity and the top 10 Common Weakness Enumeration (CWE) show the shape of the risk, so a weakness that recurs across the whole organization gets interpreted as a training or policy gap rather than a series of bugs. Filter the entire dashboard by project or by report type to focus on static application security testing (SAST) or dependency scanning vulnerability types. ## Consolidate every scanner into one view The organization dashboard isn’t limited to GitLab's own scanners. Any third-party scanner that outputs Static Analysis Results Interchange Format (SARIF) reports can feed its findings into GitLab. These become vulnerability records like any native finding and roll up into the same risk score, charts, and per-project view. For a security team running multiple tools across the organization, you get one consolidated read on risk, including GitLab's scanners and those you already run, rather than a separate dashboard per tool and manual efforts to combine them. ## Turn on the organization security dashboard The organization security dashboard is available in beta on GitLab.com for Ultimate. It reads the data your projects already produce, so switching it on depends on having the right pieces in place. Before the dashboard can display your org-level risk, confirm four things: - You have created an Organization with multiple top-level groups using the Organizations (Beta) feature. To do this, Owners can Create Organizations under Settings > General > Advanced. - You have Owner role access to the Organization-level in GitLab. - Advanced search and advanced vulnerability management are active. These power the rollup across top-level groups, and on GitLab.com they are on by default. - Your projects run at least one security scanner and have a completed scan on their default branch, so there are vulnerabilities to aggregate. With that in place, go to the top bar, select Search or Go to, and choose your Organization. In the left sidebar, select Secure, then Security dashboard. The organization view opens with the risk score and the charts across every top-level group in the organization. Not on GitLab Ultimate yet? Start a free trial today to get organization-level visibility into your risk posture.

Every software build is assembled from open source packages, base images, and libraries, with your code on top. When one of those components is missing or has drifted, the build fails. At agent speed, those failures multiply, and no team can clear them as manual exceptions. Project-by-project registry sprawl makes it worse because retention rules, storage limits, and publish access all live separately inside each project. Project-level design works when a person sets up each registry by hand, but breaks down when agents are running continuously across hundreds of projects. At GitLab Transcend today, we announced GitLab Artifact Central: one organization-level registry that replaces hundreds of project-level ones, so every pull or publish by a human or an agent runs through the same governed door, enabling platform teams to assemble the right software the first time. Here is more on why we developed Artifact Central, and how it can help your team. ## Set policy once, enforce everywhere In GitLab, retention rules, storage limits, and who can publish all live inside each project’s free package and container registry, configured on its own. GitLab Artifact Central moves that job up one level. Teams assign retention rules, quota settings, and access policies once at the organization level, instead of recreating them in every project underneath it. Every repository is closed by default: Being a member of the organization is the gate, not the grant. Organization membership alone doesn't unlock a single repository until a role grants it. We’ve built four roles specifically for artifacts: Admin, Manager, Contributor, and Viewer. These roles are kept separate from GitLab's existing project roles, so granting someone access to a repository never touches their privileges anywhere else. ## One URL for publishing, proxying, or both Instead of navigating an internal wiki page explaining what is where, developers point to one URL for everything. GitLab Artifact Central does this through three repository types: - Hosted — The private packages and images your teams build and publish. - Remote — A proxy in front of an external source, like Docker Hub or Maven Central, with the connection tested before anything depends on it. - Virtual — A single endpoint that brings hosted and remote repositories together. GitLab checks the hosted repository first, then falls back to the remote source. The first external pull is cached, so subsequent pulls come directly from GitLab without another trip to the internet. Virtual repositories matter most for teams comparing GitLab with other artifact management solutions. They give developers the familiar single-endpoint experience without requiring them to think about where an artifact lives. Whether it was built internally or pulled from an external registry, developers request it the same way. During the beta period, Artifact Central supports Maven, npm, Docker, and OCI, with more formats to follow. ## Trace anything back, automatically Here's the part that's hard to replicate outside GitLab. Every artifact that publishes through GitLab Artifact Central carries its build provenance automatically: which pipeline built it, which branch and commit it came from, who triggered the job. Since it is the same platform that ran the build, the registry already knows. Authentication works the same way. Publishing and pulling use CI_JOB_TOKEN, the identity your pipelines already have, for people and agents alike. An agent publishing or pulling through CI pipelines uses that exact same job token, not a bolted-on service account with separate permissions to maintain. With a standalone registry, tracing an artifact back to its source means separately correlating IDs across your CI system and your registry – using a script someone owns and maintains. With Artifact Central, the pipeline, branch, commit, and job are already attached to the artifact itself. ## Answer 'what did we publish?' in seconds Artifact Central lives in the same platform as your code, merge requests, and pipelines, so artifacts published from CI carry their build provenance: the pipeline that built them, the commit, and who published them. Next, we plan to connect that across your organization through GitLab Orbit, so "which of my running services are affected by this vulnerability?" becomes one question with one answer, instead of a manual search across four or five tools. ## Pair Artifact Central with Dependency Firewall GitLab Dependency Firewall, a separate GitLab product now in early access for Premium and Ultimate customers, works out of the box with Artifact Central. With Dependency Firewall, you can stop risky packages before they ever reach a build. You add its check to each pipeline using the glab CLI, so coverage is pipeline by pipeline, no matter which package manager your teams use. Next, we plan to enable tighter integration between the two capabilities, so that one policy for your whole organization blocks risky packages by vulnerability, license, or package age the moment they're pulled. ### Two benefits of the same registry Here's what that looks like from two different desks: a developer shipping code, and the platform team making sure the whole thing holds together. A developer publishing from CI. Your pipeline publishes a Maven artifact using the job token it already has without any new secrets to manage. If that same developer needs an internal package alongside something from Maven Central, they point at one virtual repo URL and let GitLab Artifact Central sort out where each one actually lives. A platform team setting policy once. Instead of configuring rules across 100s of separate projects, an admin sets storage quotas and repository access rules at the organization level, one time — and every repository underneath inherits it. When someone asks how much the company is storing, and where, there's one dashboard with the answer. ### Migrating your artifacts Most companies aren't starting from zero, and switching cold from an existing registry isn't realistic. With GitLab Artifact Central, you can add your existing repos as remotes behind a virtual repo, so developers point at one URL and artifacts move over only when a build actually asks for one. There is no need for bulk copies, weekend migration windows, or moving petabytes of data across your network. Your old registry remains the system of record. When you're ready, you convert that remote to a hosted repo on Artifact Central. Your migration is safer and gradual. ## Try Artifact Central, free in beta GitLab Artifact Central is available today in beta for GitLab.com, with availability on GitLab Self-Managed planned for later this month. There's no billing during the beta, and nothing to purchase. We're tracking usage to shape pricing ahead of general availability, and we'll share details then. ### Help us continue to build GitLab Artifact Central None of this would be where it is without our design partners, who've been running Artifact Central with real workflows for weeks. Their feedback already shaped what's shipping today, and your feedback will shape what comes next. No invitation is required to participate in the beta of Artifact Central, just sign up on our website and a member of our team will be in touch to help enable it for your account. If you don’t have a GitLab account yet, you can also sign up for the beta, and a member of our team will reach out. We can't wait to see what you build. > Watch the replay of our Transcend event to see demos of new platform capabilities and explore what it takes to carry the speed of agentic AI across the full software lifecycle.