The interesting finding first, because it is the whole page: Credo AI Agent Governor and Productizer install into Claude Code by the same mechanism — hooks, skills and settings — and govern completely different things. Credo AI’s own white paper puts the mechanism plainly: “At launch, we provide configurations for Claude Code, specifically. The artifacts we generate are hooks and skills, along with configuring Claude Code’s formal settings.” That is a sentence that could have been written about Productizer. Neither is an MCP server, a proxy, a gateway or a wrapper CLI — Credo argues against that shape explicitly, on the grounds that “MCP gateways don’t give governors a window into an agent’s local operations” and that their approach works “without the need for proprietary, ‘sidecar’ infrastructure like an API gateway.” Both quotations are from their Agent Governance Configuration white paper.
Credo AI governs the agent’s behaviour at runtime. Did this tool call violate policy? Allow, deny, escalate, or advise. Their own launch blog words the four outcomes as “allow, block, escalate, or advise”, and the white paper’s Figure 2 is captioned “The agent lifecycle: where governance attaches” — session start, user prompt submission, then pre tool use, tool execution and post tool use, then stop. Policy attaches at each of those points. It is policy about how an agent may act.
Productizer governs the agreement. What is this product supposed to do, which human agreed it, and what happens when a new request contradicts something already agreed. It keeps one living spec per product at .claude/productizer/spec.md: EARS requirements with permanent ids that are never reused and never renumbered, a constitution of P-numbered principles above them, superseded text retained verbatim, and a classification of every new intent against the whole spec — extend, refine, duplicate or contradict. A contradiction halts the work pending a human ruling recorded as a D id. Around that sit nine linear stages, declared checks in a committed checks.yaml, and human gates on deploy and publish as PreToolUse hooks. Its halt is not about a tool call; it is about a requirement.
Both are legitimate, and they are not substitutes. This page does not pretend one wins every row, because it does not. Credo AI leads on runtime coverage, on the expressiveness of its outcomes, on shipping usable policy content on day one, on its evidence trail, and on simply being a company rather than a person — and those get their own section below rather than a footnote. One status caveat holds throughout: Agent Governor is a Research Preview, not generally available. Their product page footer says so in as many words: “Research preview · not generally available · no production SLA. Credo AI Agent Governor is a Beta Service.”
Read the table as two answers to two different questions. Agent Governor answers may this agent take this action right now, and answers it at every point in the loop with four possible outcomes and pre-written policy behind them. Productizer answers what are we agreed this product does, and what happens when today’s request contradicts a decision taken four months ago. Where a row below says a Credo AI property was not found, that means exactly that — searched for across their launch blog, white paper, product page, webinar transcript and public plugin repository, and not located. It is not a claim that the property does not exist internally.
| Productizer | Credo AI Agent Governor | |
|---|---|---|
| What is governed | The agreement — what the product should do, and which human agreed it | The agent’s behaviour — whether a given action in the loop may proceed |
| Primary artifact | A declared living spec — one per product, at .claude/productizer/spec.md | A runtime policy, shipped at three postures — permissive, balanced, strict — drawn from Credo AI’s control library |
| How it installs | ✓ A Claude Code plugin — hooks, skills and settings, as files in your own repo | ✓ The same mechanism — “hooks and skills, along with configuring Claude Code’s formal settings”. No gateway, no proxy, no sidecar, on either side |
| Coding agents supported | ✗ Claude Code only | ✗ Claude Code only too — “At launch, we provide configurations for Claude Code, specifically”, and their webinar says access has “no prerequisite, except using [Claude] Code for the time being” |
| Where it intervenes in a session | ✗ Two points only — PreToolUse gates on deploy and publish, and nothing else | ✓✓ The whole loop — session start, prompt submission, pre tool use, tool execution, post tool use, stop |
| Outcomes available at the gate | ✗ Binary — the change proceeds, or it halts for a human | ✓✓ Four — “allow, block, escalate, or advise”. Strictly more expressive |
| Usable policy content on day one, authored by nobody at your end | ✗ None. Productizer ships no policy content at all — you write the spec, and an empty spec governs nothing | ✓✓ Three postures out of the box, “aligned to EU AI Act, NIST RMF, ISO 42001, and sector frameworks”. A risk function gets value the day it installs |
| Authoring your own policy or spec | ✓ That is the product — the spec is yours, written with the agent, in your repo | Not shipped. Their product page marks “Create your own policy (Coming soon)”, “Upload from your organization (Coming soon)” and “Policy audits (Coming soon)” |
| Control-level framework mapping published | ✗ None — Productizer maps to no framework at all | Framework names only. A search of both blogs, the product page and the public plugin repository for article, clause and control identifiers returns zero matches — no control-level mapping is published, which is not proof they lack one internally |
| A durable, versioned statement of what the product should do | ✓ One living spec per product, versioned in your repository alongside the code | — Not found in public documentation |
| Stable requirement identifiers | ✓ Permanent, never reused, never renumbered | — Not found in Agent Governor. A different Credo AI product — their public governance-intelligence-pro plugin — does carry policy_requirement_ids, but those are regulatory obligations from Credo AI’s own catalog, not your product’s requirements |
| New request classified against everything already agreed | ✓ Extend / refine / duplicate / contradict, against the whole spec | — Not found. The nearest published thing is classifying tool results to prevent exfiltration, which is data classification — a different operation |
| Contradiction between two requirements halts the work | ✓ Halts pending a human ruling, recorded as a D id | — Not found. Agent Governor can certainly block — but on a policy violation by an action, not on a contradiction between two agreed requirements |
| Supersession that keeps the original text | ✓ A superseded requirement keeps its original sentence verbatim; violating that is an ERROR | — Not found. The closest published behaviour is their catalog-drift audit, which “flags requirements that have changed in the catalog since the plan was written” — drift against a vendor catalog, in a different product |
| Verification that shipped code satisfies a requirement | ◐ A committed checks.yaml and a Productizer-Req commit trailer — provenance at the commit, and a check that exits clean having examined less than it declared is hollow and blocks | — Not found in public documentation |
| Evidence trail of what the agent actually did | ✗ None of runtime behaviour. There is a generated read-only dashboard of the spec and the stages, and no record of agent actions at all | ✓✓ Claude Code’s own OpenTelemetry emission, into a Credo-hosted backend reached by a separate login |
| Account / server / telemetry | ✓ None — local only, no account, no server, no telemetry | Hooks and skills are local, but the evidence trail is telemetry to a Credo-hosted backend, and access runs through a gated form |
| Self-hosted or on-premise deployment | ✓ Inherently — there is nothing to host | — Not found. No mention of self-hosting, on-premise, VPC, single-tenant or air-gapped deployment was located on any page fetched |
| Product status | A working open-source plugin, but one person’s project — no SLA, no support contract, no organisation behind it | “Research preview · not generally available · no production SLA. Credo AI Agent Governor is a Beta Service.” Launched 14 July 2026 |
| The organisation behind it | ✗ One person, working in the open | ✓✓ A company, with a control library its policy is drawn from and SOC 2 Type II claimed on its trust centre |
| Licence and price | ✓ Open source — github.com/gitayg/productizer, free, no tier to buy | — Unpublished. The pricing URL returns 404 and no pricing page appears in their sitemap. The only pricing statement anywhere is spoken in their webinar: “it’s early and it’s free… We’re basically looking for design partners” |
Runtime enforcement over a whole agent session — Productizer gates publish and deploy, and nothing else. Productizer’s two PreToolUse gates fire at the very end of the work: something is about to be deployed, or something is about to be published. Everything the agent did on the way there was ungoverned. Agent Governor attaches at every point in the loop the white paper’s Figure 2 names — “The agent lifecycle: where governance attaches” — session start, prompt submission, before a tool runs, after it runs, and at stop. That is a strictly larger surface, and it is the surface where an agent actually does damage.
Four outcomes beat two. Productizer’s gate is binary: the change proceeds or it stops for a human. Credo’s launch blog describes “allow, block, escalate, or advise”, and the difference between escalate and advise is the difference between interrupting a person and leaving a note for one. A governance layer with only a stop button gets turned off; a governance layer that can advise without blocking survives contact with a working team. This is a design lesson, not a marketing point.
Pre-written policy aligned to named frameworks means a risk function gets value on day one without authoring anything — and this is a real advantage, not a hedge. Agent Governor ships policy at three postures, permissive, balanced and strict, drawn from Credo AI’s control library, and its product page says: “Start from out-of-the-box policies aligned to EU AI Act, NIST RMF, ISO 42001, and sector frameworks.” Productizer ships no policy content whatsoever. An empty spec governs nothing, and the first week with Productizer is spent writing one. If the person evaluating this is a risk or compliance function rather than an engineering team, that difference decides it, and pretending otherwise would be dishonest.
An OpenTelemetry evidence trail, and somewhere to look at it. Agent Governor rides Claude Code’s own OpenTelemetry emission into a Credo-hosted backend, reached by a separate login from their main platform. Productizer has no dashboard of runtime agent behaviour at all — its generated dashboard shows the spec, the stages and the release history, and it has no idea what the agent did between them. If the question is “what has this agent been doing across the fleet this month”, Productizer cannot answer it and Credo can.
And there is a company behind it. Credo AI is an organisation with a control library its policy content is drawn from, and SOC 2 Type II claimed on its Vanta-hosted trust centre. Productizer is one person’s free open-source project. No SLA, no support contract, no security programme, no procurement path. For a regulated buyer that is not a small difference, and it is not one that better architecture makes up for.
Nothing in Agent Governor was found to hold a durable, versioned statement of what the product should do. Searching their launch blog, white paper, product page, webinar and public plugin repository turns up no living spec, no spec of record, and no equivalent object. Nor were stable requirement identifiers, supersession, classification of a new request against what was already agreed, a contradiction halt, or verification that shipped code satisfies a requirement found in any of them. Every one of those is not found in public documentation — searched for and not located. None of it proves the capability is absent internally, and the honest reading is simply that Agent Governor is not built to govern that object. It is built to govern actions, and it says so.
The one place they do have something requirement-shaped deserves crediting rather than glossing. A different Credo AI product — the public governance-intelligence-pro plugin in their plugin marketplace, not Agent Governor — references policy_requirement_ids and an audit feature described as “Catalog drift — flags requirements that have changed in the catalog since the plan was written.” Read carefully, that is drift of regulatory obligations from Credo AI’s own catalog against a plan — not contradiction detection between two of your own product requirements, and not in the product this page compares. But it is requirement-shaped, it is theirs, and saying they have nothing of the sort would be false.
The pre-written policy is currently the whole product, and their own page says so. Under authoring, the product page marks “Create your own policy (Coming soon)”, “Upload from your organization (Coming soon)” and “Policy audits (Coming soon)”. The white paper says “We are working to add the features necessary to support organizations in bringing, and even building, policies of their own”, and the webinar says “On our near term road map is supporting organizations to bring their own policy”. Three sources, one answer. That makes the strength and the limit the same fact: what ships is Credo’s policy, and today you take it as given. Productizer is the mirror image — nothing ships, and everything is yours.
Framework alignment is published at framework-name level, and this was measured rather than assumed. The product page names EU AI Act, NIST RMF, ISO 42001 and “sector frameworks”. Grepping both blogs, the product page and the public plugin repository for the shape of a citation — Article N, GOVERN n.n, A.n.n.n, CCn.n — returns zero matches. No named article, clause or control identifier appears anywhere in public Credo AI material. That does not prove the mapping is absent internally, and it should not be read that way: it means a buyer cannot check the mapping from outside, and would have to ask. Productizer, for the avoidance of doubt, maps to no framework at all — this is a row where Credo publishes something and Productizer publishes nothing.
It governs two moments in a session against Credo’s whole loop. Its gate has one outcome where Credo has four. It ships no policy content, so the first week is spent writing a spec that does not exist yet, and an empty spec governs nothing. It has no record of runtime agent behaviour — not a thin one, none — so it cannot answer any question about what the agent actually did. Its lifecycle has never run end to end through CI. Its accuracy is measured on a small corpus written by the same person who wrote the tool. And it is one person’s free open-source project: no company, no SLA, no SOC 2, no procurement path. If what you need is to stop an agent doing something dangerous inside a session, and to hand an auditor a trail afterwards, Productizer is the wrong tool and Agent Governor is aimed squarely at that.
The verdict — a team could reasonably run both. Credo AI decides whether the agent may take an action; Productizer decides whether the change should have been made at all. They attach through the same hooks, they read the same session, and they answer questions that do not overlap. Run Agent Governor when the risk is an agent doing something it should not — exfiltrating a secret, touching production, running a command nobody sanctioned — and you want that caught in the loop with an outcome finer than a stop, plus an evidence trail a compliance function can read. Run Productizer when the risk is shipping something nobody agreed to — when the request in front of the agent quietly contradicts a decision taken months ago and there is no artifact that would notice. Nothing about installing one prevents installing the other, and a page that claimed these were rivals on every row would be a page you should not trust.
Every Credo AI claim on this page was read from their own public material — the launch blog, the Agent Governance Configuration white paper, the Agent Governor product page, the 30 July 2026 webinar and the credo-ai/credoai-plugins repository. Follow the links and check the wording rather than taking this page’s word for it. Quoted phrases are theirs, verbatim, and each is attributed above to the document it came from. Where a row says something was not found, that is the limit of what public material says — searched for and not located, never a proof of absence. Agent Governor launched on 14 July 2026 and was still a Research Preview when this page was written; a preview product changes quickly, so verify specifics against current documentation. The lifecycle event names used here are Credo’s own prose labels, not identifiers they publish. Productizer marks reflect shipped capability in github.com/gitayg/productizer. Credo AI and Agent Governor are the property of their owners; this is an independent capability comparison, and this page is not affiliated with, endorsed by, or partnered with Credo AI.