Complex tasks hit a wall at the end of every chat turn. Developers already know what they're trying to accomplish. What stalls the work is the handoff back and forth between each step. Without a pre-defined definition of success, the agent stops and waits for direction or clarification, so you end up re-prompting it step by step, effectively acting as its continue button until the task is done.
Depending on the team, that handoff can mean minutes of back-and-forth, or it can mean the request sits until someone is free to look at it again. A back-and-forth like this is manageable for small, well-scoped requests, but it breaks down for the kind of open-ended work developers actually spend their time on: fixing the failing tests, getting this build past checks, or cleaning up the lint errors across a module.
With GitLab 19.4, GitLab Duo CLI includes the /goal slash command, a governed, goal-driven flow that takes on that open-ended work directly, running locally while you stay in control.
Why turn-by-turn chat keeps costing you timeGitLab Transcend returns in October
Coding agents are increasing your speed of development, but your reviews, security policies, and release cycles still have to keep pace. Our Transcend event on October 6 will demonstrate how GitLab is helping teams close that gap and explore what it takes to carry the speed of agentic AI across the software lifecycle.
Register for the livestream today!
This isn't about the assistant getting smarter. Turn-by-turn chat requires someone to keep it moving: read the response, decide the next instruction, send it, repeat. Even a capable model still waits at the end of each turn for a person to unstick it, so a developer's attention stays tied to how long a task takes, not how much of it they actually need to do by hand. That's why AI assistance so far has mostly changed the shape of a developer's time rather than given much of it back.
Delegate it, and get a verified result backWith /goal, you describe the outcome you want and move on. No one needs to babysit the run: work continues, gets checked against what you asked for, and either finishes or tells you what it couldn't resolve. You come back to a completed result and a record of what was verified, the same way you'd check in on something you delegated to a colleague, instead of staying anchored to the conversation until it's done.
You just name the job and define what "done" looks like, and GitLab takes the wheel, staying active and focused until that specific finish line is crossed.
/goal Fix the failing tests. Ensure CI is fully green and the fix is reviewed by Duo Developer.
GitLab then works the problem: It makes changes and runs verification, iterating as needed. A separate model checks that work against your stated goal at each step, deciding whether it's genuinely done or another iteration is needed, up to a configured limit. This is the difference between an assistant that answers questions and one that drives a task to completion.
Automation that stays governedHanding off a goal does not mean losing visibility into it, though. You can stop a /goal run at any point and set a new goal if requirements change, so a session in progress never has to run to its full conclusion if it's off-track.
- Stop the run at any point if you need to step in.
- Set a new goal and restart, if requirements have changed.
- Review what the verifier checked at the end of each turn, so you can see why it decided to continue or stop.
That combination — an agent that can work autonomously toward a defined outcome without requiring a supervising human to stay glued to every step, while still exposing clear points of human oversight — is what makes this a step toward practical automation rather than a novelty.
Getting startedThe /goal slash command is available now in interactive mode. To use it, run:
/goal <task>. <done when...>
For example:
/goal Fix the failing tests in spec/models/user_spec.rb. Continue until all tests pass locally and CI is green.
Watch /goal in action in this demo:
The value of a goal-driven flow depends on the surfaces through which developers can reach it. /goal launches first in the CLI because much of this iterative, hands-on work already takes place in the terminal, but the underlying capability is not limited to any single client. Developers should be able to delegate a goal from within the tools they already use, rather than switching to a separate interface to access this automation.
A GitLab Duo Slack agent is coming soon, letting developers work with GitLab Duo Agent Platform conversationally, right inside Slack. Mention @GitLab in any channel or thread to ask questions about your codebase, trigger an agent flow, or create a GitLab issue from the conversation, with no separate tool, tab, or command syntax required. GitLab Duo streams its progress back into the thread in real time, so the whole exchange — ask, work, and result — stays where the conversation is already happening.
/goal is now available in GitLab Duo CLI, and it marks a first step toward moving the decision-making behind a task, including when a goal is done and when to keep going, out of any single client and into a governed workflow that every GitLab surface can call on. As that same capability extends to Slack, the iterative fixes and verifications your team already runs by hand become governed, goal-driven flows, without asking developers to change where they work.
Ready to try /goal? Start with the documentation for GitLab Duo CLI slash commands.
/goal requires GitLab 19.3 and later, and GitLab Duo CLI 9.17.0 and later. It's available on GitLab.com, GitLab Self-Managed, and GitLab Dedicated, on the Premium and Ultimate tiers.
/goal is part of GitLab Duo Agent Platform, so you'll need it turned on to use this and other agentic capabilities. You can get access with a free trial of GitLab Duo Agent Platform. On the Free tier, you can sign up in a few simple steps.
Already on GitLab Premium or Ultimate? Start by turning on Duo Agent Platform and use the GitLab Credits included with your subscription.
This blog post contains "forward‑looking statements" within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.