The setting
's keep code in Git repositories and run automated pipelines, written in YAML, that build, test, and deploy software. Teams run it as a hosted service, on their own servers, or as a managed service for one customer.
Interest in self-hosted models has arrived ahead of a shared route to approved use.
A broad first cohort protects learning across customers, while limited specialist availability favors a narrower introduction.
Who you’d be doing this for
“Security asked who accepts the model setup, and I’ve already booked three meetings trying to find out.”
Chetan Deshpande · DevOps Engineer · a character in this brief
Coordinates the first agent workflow for a regulated customer considering self-hosted models.
What is at stake
Nine regulated customers want self-hosted models, but disagree about when security should enter the launch. You must weigh a cohort broad enough to teach against a readiness bar that scarce specialists can support.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- cohort breadth vs specialist capacity
- shared readiness criteria vs customer security sequences
- early invitations vs credible acceptance
- preparation completion vs approved use
Why Gitlab
The GitLab Duo Agent Platform spans deployment choices whose availability does not by itself establish regulated customers’ readiness to use agents.
Written with these in mind
Not your kind of problem? 30 more at Gitlab, or browse every organization.
Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.
The organization context comes from public information. The situation and characters are written for the brief.
Job postings it was written from
Public descriptions of the work at Gitlab. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.
- Principal Technical Program Manager (opens in a new tab)
- Leading the GitLab Duo Agent Platform from GA through enterprise adoption, including customer onboarding, support models, and billing integration for AI-driven capabilities
- Lead end-to-end technical programs across product, engineering, data, and security, from initial scope through launch and continuous improvement
- Technical Program Manager (opens in a new tab)
- Lead 1–3 strategic technical programs at a time spanning multiple engineering teams and product stages, ensuring clear scope, priorities, and outcomes.
- Drive asynchronous collaboration using GitLab issues, epics, and handbook updates so globally distributed teams stay aligned and informed.
- Senior Manager, Technical Program Management (opens in a new tab)
- Staff Program Manager, CCO Programs (opens in a new tab)
- Coordinate senior stakeholders across Sales, Customer Experience, Product, Marketing, Renewals, Professional Services, Data, and Enablement, holding them accountable without direct authority.
- You'll turn executive intent into workstreams, coordinate senior stakeholders across Sales, Customer Experience, Product, Marketing, Renewals, Professional Services, Data, and Enablement, and make the tactical calls that keep the portfolio honest.
- Customer Experience Enablement Lead (opens in a new tab)
- Scope and build new enablement content, including programs focused on product knowledge, skill development, onboarding, leadership development, and many other areas, specifically for the CX organization.
- It’s a high-impact, cross-functional team focused on improving field productivity, strengthening customer-facing capabilities, and measuring enablement’s contribution to business growth.
Reporting read before this brief was written
The pieces closest to the situation in this brief.
InfoQ's August 2026 panel of practitioners in regulated environments described individual teams racing ahead with AI without a shared foundation, duplicating work and running into compliance controls such as those introduced under DORA.
InfoQ Cloud and DevOps Trends Report - 2026 - InfoQ (opens in a new tab) · infoq.com · Aug 12, 2026
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.
Where similar work appears
Other live briefs connected to this one, and what connects them.
Similar problems at other organizations
Like this one, each of these is about an irreversible change forced by a fixed date.
Enterprise buyers cannot see a repeatable proof that records behind custom agents stay reviewed.
You must weigh a credible readiness bar against a pilot path Knowledge Managers will sustain.
Enterprise data teams lack a shared path from a governed AI trial to production use.
You must weigh fast customer proof against a launch rhythm that can scale beyond the first cohort.
Seven of ten committed customers cannot show who approved an action an agent took, or reconstruct the policy behind it.
You have to set the scope and rollout bar for a launch you cannot take back.
The same setting, from another role
Each is set around Gitlab’s Integrated source control and CI/CD, written for a different role. They’re separate briefs, not the same scenario.
Repository investigations are consuming critical release time because the first plausible cause is hard to verify.
You must decide what AI assembles, what engineers confirm, and how the pilot proves the difference.
Required approvals are appearing after merge requests enter review, creating avoidable rework.
You have to weigh a clear preview against the performance and fidelity of repository rule evaluation.
Agent-written CI/CD changes are creating unexpected runner demand after they merge.
You must weigh early cost guidance against estimates that could overstate risk and slow useful changes.