Three Teams, One Pattern: What PM, Security, and Infrastructure All Built for Agent Governance

A project management platform with 50 API endpoints and 15 specialized agents. A security team at GitLab building detection engineering assistants. An infrastructure provider shipping policy-as-code for cloud compliance. Three teams in three domains, solving three different problems.

They built the same thing.

Not similar things. Not “aligned” things. The same four structural patterns, in the same order of priority, without any coordination between them. When that happens once, it is coincidence. When it happens across domains this different, it is architecture revealing itself.

The Three Systems

PM Agent OS is a governed project management platform built by Deepesh Kumar Gupta. It exposes 50+ REST API endpoints across 15 specialized agents, each scoped to a specific PM function. The system includes a Policy Center with source allowlists, PII masking, and data retention rules. An RBAC engine gates access per module and per data type. Every allow and deny decision writes to an immutable GovernanceEvents audit log. Multi-reviewer approval gates sit between agent output and user-facing delivery.

The design principle is explicit: “The model never invents metrics, data, or citations.” That sentence is a governance policy compressed into nine words.

GitLab’s Detection Engineering Assistant is a different animal entirely. Matt Coons and his team built a custom agent to help security engineers write detection rules. The system prompt runs 1,870 words across 337 lines. It maps findings to MITRE ATT&CK. It generates draft detections that human engineers review, refine, and approve.

Coons described the system prompt as “a living document,” which is worth pausing on. The prompt is not configuration. It is policy. It encodes what the agent may conclude, how it must structure findings, and where human judgment is required. When the team learns something new about false positive patterns, they update the prompt. Policy iteration at the speed of a text file edit.

His assessment of the agent is equally precise: “Doesn’t replace a skilled detection engineer, but amplifies one.” This framing matters. The agent is not autonomous. It is constrained by design, producing structured output that feeds into an existing human review process.

Pulumi’s OPA integration operates at the infrastructure layer. Levi Blackstone’s team shipped pulumi-policy-opa v1.1.0, making Open Policy Agent and its Rego language first-class citizens in infrastructure governance. The system enforces three levels (mandatory, advisory, disabled) across three governance layers: audit-time evaluation, preventative checks at pulumi preview, and self-hosted policy execution. Existing Gatekeeper .rego files work without modification. Pre-built compliance packs cover CIS, NIST, and PCI DSS.

Three teams. Three domains. Zero coordination.

Pull the architectures apart and the same skeleton appears in each.

Pattern 1: Approval gates before output reaches production. PM Agent OS uses multi-reviewer gates. GitLab’s assistant produces drafts for engineer review. Pulumi blocks deployments at pulumi preview when mandatory policies fail. In every case, agent output passes through a checkpoint before it touches anything real.

Pattern 2: Audit trails recording every decision. PM Agent OS writes immutable GovernanceEvents for every allow and deny. GitLab’s MITRE ATT&CK mapping creates a forensic record of what the agent found and how it classified it. Pulumi’s three-layer evaluation produces logs at each enforcement point. None of these teams built audit as an afterthought. It was structural from day one.

Pattern 3: Structured output requirements. The PM platform enforces data schemas through its API endpoints. The GitLab assistant’s 337-line system prompt specifies exact output formats for detection rules. Pulumi’s Rego policies define typed resource evaluation. Agents do not get to choose how they express their results. The format is fixed.

Pattern 4: Policy-as-code. PM Agent OS implements RBAC as engine logic. GitLab encodes policy in the system prompt itself. Pulumi uses OPA/Rego as a literal policy language. Three different implementations, one principle: governance rules are executable, not advisory.

As we explored in The Cage Pattern, Stripe, Cloudflare, and OpenAI converged on a similar principle at the infrastructure level: maximum autonomy inside structural constraints. These three new implementations extend that convergence beyond infrastructure into PM tooling and security operations. The pattern is spreading.

The Non-Obvious Insight

Here is the part that most commentary on AI governance misses.

These four patterns are not new. Approval gates predate software. Audit trails are a requirement in every compliance framework from SOC 2 to ISO 27001. Structured output is what APIs have enforced since the first REST specification. Policy-as-code has been an infrastructure practice since HashiCorp launched Sentinel in 2017.

None of these teams invented governance for AI agents. They applied existing governance patterns to AI agents. The agent is a new actor in an old system, and the old system’s controls work.

This is the argument we made in The Governance Layer That Was Already There, where three practitioners (Pocock, Beck, Osmani) independently rediscovered that engineering discipline is governance. What is different now is the evidence base. That piece described individual developers applying discipline to AI coding assistants. These three implementations are production systems built by teams, with real architectures, serving real users. The principle scales from individual practice to team infrastructure without modification.

The reason it scales is simple. Governance patterns are not about the actor performing the work. They are about the work itself. Whether a human analyst or an AI agent writes a detection rule, the rule still needs peer review. Whether a developer or an agent provisions cloud infrastructure, the provisioning still needs policy evaluation. The governance requirement comes from the operation, not the operator.

Where This Breaks Down

The convergence is real, but it has limits.

Approval gates work for discrete, reviewable outputs: a detection rule, a deployment plan, a formatted report. They do not work well for continuous agent operations (monitoring, real-time response, autonomous remediation). An agent that must pause for human approval before responding to a security alert has defeated its own purpose.

Audit trails assume someone reads them. The PM Agent OS logs every GovernanceEvents entry. At scale, that means thousands of records per day. Without automated anomaly detection on the audit stream, the trail becomes a compliance artifact rather than a governance tool. You have evidence that decisions were made. You do not have evidence that the decisions were correct.

Structured output solves the formatting problem but not the accuracy problem. GitLab’s assistant can produce a correctly formatted MITRE ATT&CK mapping that is substantively wrong. The structure creates reviewability. It does not create correctness.

And policy-as-code assumes the policy is right. Pulumi’s Rego integration is only as good as the rules written in Rego. In What 220 Controls Teach About AI Governance Frameworks, we examined how GitLab cut SOC controls by 58% because most of them did not fit. Policy-as-code at scale requires policy curation, not just policy enforcement.

What This Means for Organizations Building Agent Systems

If three unrelated teams in three unrelated domains converge on the same four patterns, those patterns are likely necessary conditions for governed agent deployment. Not sufficient. Necessary.

Start with what you have. Most organizations already run approval workflows, audit logging, API schemas, and some form of policy enforcement. The work is not building these from scratch. The work is extending them to treat agents as actors in the existing system.

Treat the system prompt as a policy document. GitLab’s 337-line prompt is not a convenience. It is a governance artifact, versioned, reviewed, and updated as the team learns. If your agents run on prompts that were written once and never revised, you have policy drift.

Build audit trails that are queryable, not just loggable. The PM Agent OS approach (immutable event streams) is right. But the value comes from what you do with those events. Can you answer “which agent decisions were overridden by reviewers last month?” If not, your audit trail is decoration.

Do not build agent-specific governance. Build governance that includes agents. The Cage Pattern piece established this at the infrastructure level. These three implementations confirm it across domains. Separate governance systems for AI mean double the maintenance and half the coverage. One system, expanded to recognize agents as participants, is simpler and more reliable.

The Convergence Is the Signal

When Stripe, Cloudflare, and OpenAI converged on the Cage Pattern, you could argue it was because they are all Bay Area tech companies with similar engineering cultures. That argument does not hold here. A PM platform, a security team, and an infrastructure provider have nothing in common except the problem they are solving.

The patterns are converging because they are correct. Approval gates, audit trails, structured output, and policy-as-code are the minimum viable governance for any system where automated actors make decisions that matter. This was true for CI/CD pipelines. It was true for robotic process automation. It is true for AI agents.

The question is not whether your organization needs these four patterns. You do. The question is whether you will build them deliberately or discover them through failure.

This analysis synthesizes PM Agent OS by Deepesh Kumar Gupta (March 2026), GitLab Duo Agent Detection Gap by Matt Coons (March 2026), and Pulumi OPA Full-Stack Governance by Levi Blackstone (March 2026).

Victorino Group builds governed agent systems using patterns that work across domains, not frameworks that work in theory. Let’s talk.