Comparison
Cordum vs LaunchDarkly AgentControl
AgentControl changes how an agent behaves. Cordum decides whether a specific action the agent attempts may run. They work at different points and fit together.
Short answer
LaunchDarkly AgentControl manages agent configuration outside your code: prompts and instructions, model and parameters, and attached tool definitions. Teams target, roll out, compare and roll back those changes without redeploying, with judges and per-variation metrics. LaunchDarkly does not proxy model calls, and its docs leave tool execution to your application.
Cordum is an action firewall for AI-agent actions. It evaluates the action itself (a Claude Code shell command, a file write, an MCP tool call, an agent job) before it runs, and returns ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE or ALLOW_WITH_CONSTRAINTS with redacted evidence.
Use AgentControl to change behavior safely. Use Cordum to bound what any behavior can do: a new prompt or model does not change Cordum policy.
What LaunchDarkly AgentControl is
- Announced by LaunchDarkly on 2026-05-19. Its docs list AgentControl as an add-on whose access depends on your LaunchDarkly plan, enabled through your account team and not available in LaunchDarkly federal environments.
- Configs, in completion or agent mode, hold instructions or messages, model and provider settings, and versioned tool definitions. AI SDKs for .NET, Go, Node.js (server-side), Python and Ruby return the evaluated config to your app.
- Targeting rules, segments and percentage rollouts choose a variation per context. Guarded rollouts can pause or revert a change when monitored metrics regress. An off variation applies when targeting is off, and an in-code fallback value applies when LaunchDarkly is unreachable.
- Judges use an LLM to score responses for accuracy, relevance, toxicity or custom criteria on sampled live traffic; the docs also cover offline evaluations against datasets. Scores can drive guarded rollouts; blocking a response at runtime is left to your code.
- Monitoring tracks tokens, cost, latency, time to first token, errors and user satisfaction per variation, with traces through LaunchDarkly's observability plugin.
- LaunchDarkly does not proxy model requests: your app calls the provider and runs tools. Online evaluations send LaunchDarkly only a score, and config changes can require approval before they take effect.
What Cordum is
- Edge first: cordumctl edge claude launches Claude Code with a PreToolUse hook registered for every tool. The hook sends a redacted action envelope to a local cordum-agentd, which asks the Cordum Gateway and Safety Kernel for a decision before the tool runs. The wrapper is a developer path; fleet rollout uses managed Claude Code settings and endpoint controls.
- MCP governance second: on the Gateway HTTP/SSE path, Cordum's MCP server has an opt-in per-tool policy gate (mcp.policy_gate_enabled) with approval holds and argument redaction.
- Platform third: the Safety Kernel evaluates jobs before the scheduler dispatches them, so actions your own agents run as Cordum jobs are evaluated by the same policy.
- Five decisions: ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE and ALLOW_WITH_CONSTRAINTS. Rules match attributes of the action: topic, capability, risk tags, labels, actor, tenant, and MCP server, tool or action.
- Policy changes ship without redeploys: the Safety Kernel reloads policy on a 30-second default interval, bundle changes can be simulated against a request before publishing, and bundles must be Ed25519-signed in production.
- Customer-managed and source-available under BUSL-1.1; the documented Edge path builds its binaries from source. SSO, SCIM, advanced RBAC, SIEM export, legal hold, velocity rules and agent identity are Enterprise license entitlements, and license tiers cap custom policy bundles.
Side by side
Each row is checked against LaunchDarkly's and Cordum's documentation as of 2026-10-26.
| Evaluation area | Cordum | LaunchDarkly AgentControl |
|---|---|---|
| Question it answers | May this specific action run now, and does a person need to approve it? | Which prompt, model, instructions and tools should this agent use for this context? |
| What it controls | Actions: Claude Code shell and file operations and other tool calls through the Edge hook, MCP calls through Cordum's policy gate, and jobs before dispatch. | Configuration: instructions, messages, model and parameters, and attached tools, served per context. |
| Where it runs | In the action path, on infrastructure you operate: local hook and agentd, Cordum Gateway, Safety Kernel. | An AI SDK in your application fetches the config; your app calls the model provider and executes tools. |
| Per-action decision | ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE, ALLOW_WITH_CONSTRAINTS. | Not documented. Tool invocation depends on your application; judges record scores. |
| Approvals | Per action: the approval is single-use and bound to the tenant, action hash, input hash and policy snapshot. | Per config change: approvals review a change before it becomes active. |
| Changing behavior safely | Policy reloads without redeploys; bundle changes can be simulated before publishing; first match wins and the default is deny. | Targeting, percentage rollouts and guarded rollouts that pause or revert on regressions; experiments and offline evaluations. |
| Quality signals | Does not score model quality. Output policy can redact or quarantine job results with secret, PII or injection findings. | LLM judges for accuracy, relevance, toxicity or custom criteria on sampled live traffic; offline evaluations against datasets. |
| Observability | Decision and approval evidence per session with redacted descriptors and hashes; Prometheus metrics for Edge decisions. | Tokens, cost, latency, time to first token, errors and satisfaction per variation; traces through the observability plugin. |
| Data handling | Edge events store redacted summaries, hashes and artifact pointers; raw prompts, tool payloads and secrets are excluded. | Model requests are not proxied and online evaluations send only a score; playground and offline evaluation runs send prompts to LaunchDarkly. |
| Availability | Customer-managed and source-available under BUSL-1.1; enterprise features are license entitlements. | Add-on to a LaunchDarkly plan; not available in federal environments; enabled through your account team. |
When to choose AgentControl
- You change prompts, instructions or models often and want to ship those changes without a redeploy.
- You want progressive or guarded rollouts, experiments and LLM judges tied to each variation.
- You need per-variation cost, latency and quality metrics, or you already run LaunchDarkly for feature management.
When to choose Cordum
- The risk is the action, whatever prompt produced it: a destructive shell command, a credential read, an MCP mutation, a production job.
- A person must approve specific actions, not only configuration changes.
- Decisions and redacted evidence must run on infrastructure you operate.
Using both together
AgentControl decides what the agent is told and which model it uses. Cordum decides what it may do. There is no integration between them; each runs its own layer.
- Your app fetches the AgentControl config for the current context: instructions, model and tools.
- The agent proposes an action that runs through Cordum, such as a job submitted to the Cordum Gateway or a tool call to Cordum's MCP server.
- Cordum evaluates the action against policy that does not depend on the variation, then allows, denies, holds for approval, throttles or constrains it.
- AgentControl records quality and cost for the variation; Cordum records the action decision. A guarded rollout can revert a variation while Cordum keeps denying the actions your policy denies.
Related comparisons
Frequently Asked Questions
Is LaunchDarkly AgentControl a guardrail product?
Its docs describe runtime configuration, targeting, rollouts, judges and monitoring. Targeting can serve an off variation or a safer configuration, and judge scores can drive guarded rollouts. The docs do not describe approving or blocking an individual tool call; tool execution stays in your application.
Does Cordum replace AgentControl?
No. Cordum does not manage prompts or models, run experiments or score output quality. It decides whether governed actions run, and records the decision with redacted evidence.
When did AgentControl launch, and who can use it?
LaunchDarkly announced AgentControl on 2026-05-19. As of 2026-10-26 its documentation lists it as an add-on that depends on your LaunchDarkly plan, is enabled through your account team and is not available in federal environments.
Can a new prompt or model variation bypass Cordum policy?
Not for actions that pass through a path Cordum governs: the Claude Code hook, Cordum's MCP policy gate, or jobs submitted through Cordum. Policy is evaluated per action and does not depend on the variation. Cordum does not see actions that bypass those paths.
Do approvals mean the same thing in both products?
No. LaunchDarkly approvals review a configuration change before it becomes active. A Cordum approval authorizes one specific action, bound to its hashes and policy snapshot, and is consumed on the first matching retry.
Do Cordum and AgentControl integrate?
No. Cordum does not read AgentControl variations or judge scores, and AgentControl does not call Cordum. They run side by side: one shapes agent behavior, the other gates the actions that behavior produces.
Sources
All sources accessed 2026-10-26. Vendor descriptions are paraphrased from the pages below.
LaunchDarkly
Change the agent freely. Gate what it does.
Start with Claude Code shell and file actions, then put the same policy, approval and evidence path in front of MCP tool calls routed through Cordum.