Comparison
CoreBase vs Phrony
Two governance layers with almost the same policy vocabulary. The difference is who the agent is for: Phrony runs agents you declare and deploy; CoreBase governs agents you ship to other people's users.
Phrony is a runtime you deploy agents to. You declare the agent in a YAML manifest — its policies, tool restrictions and limits — publish it as a versioned entity, and the runtime executes sessions against it, emitting a structured trace and letting you roll back to a previous version.
CoreBase does not ask you to redeclare your agent. It sits between whatever agent you already have and the systems it reaches, deciding per request which tools that specific caller gets, and holding the risky calls for a person.
Short version: if you want your agents to be versioned, portable artefacts governed by an open spec, look at Phrony. If your problem is that your agent serves many different people and each must reach only their own data, that is the part Phrony's documentation does not cover.
Feature comparison
| Capability | CoreBase | Phrony |
|---|---|---|
| Positioning | ||
| What it is | Governance layer over your existing agent | Runtime you declare and deploy agents toSource |
| Keep your own agent and frameworkPhrony's model is the point of Phrony: an agent becomes a versioned artefact rather than application code. That is a real benefit and a real migration. | Yes | Agent declared in a manifestSource |
| Policy | ||
| allow / deny / require-approvalNear-identical vocabulary. Both evaluate before the tool runs rather than asking the model to behave. | Yes | YesSource |
| Human approval gates | Yes | YesSource |
| Conditions on the call's arguments | Yese.g. amount > 100 | Not documentedSource |
| Approval bound to the stored callCoreBase replays the exact held call server-side, so the model is never asked to regenerate it. Phrony's docs describe pausing a session and attributing the decision, but not what the approval binds to. | Yes | Not documented |
| Multi-tenancy | ||
| Per-end-user identityPhrony's only identity concept in the reference implementation is PHRONY_ACTOR, the audit identity for publish and deploy. Nothing covers the person a session is being run for. | Yes | NoSource |
| Tenant isolation in the database | YesPostgreSQL RLS, forced | Not documentedSource |
| Per-caller tool listRestrictions in Phrony belong to the deployed agent. In CoreBase the tool list is assembled per request from what that caller may reach. | Yes | Per-manifest, not per-callerSource |
| Per-end-user quotas & rate limits | Yes | Token & loop limits per agentSource |
| Connectivity | ||
| Databases, REST, GraphQL, MCP servers, 50+ SaaS appsPhrony runs the tools you give it; the catalog is yours to supply. | Yes | Not applicable |
| On-prem & private-network databases | YesOutbound-only bridge | Not applicable |
| Shipping to your customers | ||
| Embeddable chat widget | Yes | Not documented |
| OpenAI-compatible endpoint | Yes | gRPC runtime APISource |
| Operations | ||
| Structured trace of every session | YesExecuted + blocked calls, with the policy version | YesModel turns, tool calls, decisions, approvalsSource |
| Versioned agent deploy & one-command rollbackPhrony's clearest advantage. CoreBase versions the rules a call was decided under, but does not version the agent as a deployable artefact. | No | YesSource |
| Deployment & trust | ||
| Open specificationPhrony publishes the manifest schema, policy model, runtime contract and trace format so anyone can implement a conformant runtime. | No | YesSource |
| Open-source implementation | CoreMCP bridge + widget (Apache-2.0) | YesReference runtimeSource |
| Managed cloud | Yes | Self-hosted runtimeSource |
| Pricing | ||
| Published pricing | Yes$0 / $79 / $249 / Enterprise | Not publishedSource |
Where the two models actually differ
Both stop a call before it runs, and both let a person release it. The difference is where the restriction lives. In Phrony it belongs to the deployed agent: the manifest declares which tools that agent may use, and the runtime holds it to that. In CoreBase it belongs to the request: the same agent, asked the same question by two different people, is handed two different sets of tools.
That distinction does not matter at all when there is one agent with one set of credentials — an internal assistant, an operations bot. It becomes the whole problem the moment the agent is answering your customers, because there is no manifest you can write that is correct for all of them.
What Phrony does that CoreBase doesn't
- Versioned agents with rollback. An agent is a published artefact you can roll back in one command. CoreBase versions the policy a call was decided under — enough to explain a past decision, not enough to redeploy a past agent.
- An open specification. The manifest schema, policy model, runtime contract and trace format are published so anyone can build a conformant runtime. CoreBase open-sources its on-prem bridge and widget, but the governance layer is a product, not a spec.
- A runtime you host entirely yourself, today. CoreBase offers self-hosted and air-gapped deployments, but the default is managed.
How we checked
Every claim in the table was read off Phrony's public site and the reference runtime's README on 11 August 2026, and each row links its source. Where the documentation is silent we wrote Not documented rather than No — absence of a claim is not proof of absence, and this page is meant to survive being read by the people who built the other product.
Verdict
These two overlap more than either overlaps with an observability tool, and the honest summary is that they answer different questions. Phrony asks: what is this agent, and can I prove which version of it ran? Manifests, versioned deploys, rollback and an open spec are a genuinely good answer, and CoreBase does not have them.
CoreBase asks: who is this call for, and may they have it? Per-request tool lists, an end-user identity carried into the database, database-level tenant isolation, and an approval bound to the exact stored call. Nothing in Phrony's published documentation covers that, which is consistent with what it is: a single-tenant runtime for agents you operate yourself.
So: your own agents, versioned and portable — Phrony. Agents serving other people's users, where each must reach only their own data — CoreBase.
Frequently asked
- Is Phrony a competitor to CoreBase?
- Partly. The policy vocabulary is close to identical — allow, deny, require approval, plus limits and traces. Where they separate is tenancy: Phrony's documentation describes a runtime for agents you deploy and operate, with no per-end-user identity or tenant isolation, while that is the specific problem CoreBase is built around.
- Can I use both?
- In principle yes — they sit at different points. Phrony governs the agent as a deployed artefact; CoreBase governs what a given caller may reach when that agent runs. Nobody has wired them together that we know of, and we would not claim an integration that doesn't exist.
- Phrony is open source. Is CoreBase?
- Partly, and it's a fair point in Phrony's favour. CoreMCP — the bridge that reaches databases inside your own network — is Apache-2.0, and the embeddable widget is published on npm. The governance layer itself is a commercial product with self-hosted and air-gapped deployment options.
- What does Phrony do that you'd want?
- Versioned agent deploys with one-command rollback, and publishing the policy model as an open spec rather than a product surface. Both are good ideas and we say so on the page rather than leaving them out.