Feature deep dive
Every feature flag system ships flags, segments, and an MCP server. Actuator goes further by providing features that matter for safe agent integration and debuggable rollouts.
1 — Per-context evaluation history
Actuator can tell what a user actually received at a past timestamp, not just what flag rules were in place.
Evaluation history based on the audit log surfaces every meaningful change (flag, config, or segment edits), making debugging easy.
POST /api/v1/envs/$envId/evaluate/history
{
"context": { "user_id": "u_1001", "plan": "enterprise", "country": "US" },
"since": "2026-04-22T00:00:00Z",
"until": "2026-04-29T00:00:00Z"
}
→ {
"context": { "user_id": "u_1001", "plan": "enterprise", "country": "US" },
"since": "2026-04-22T00:00:00Z",
"until": "2026-04-29T00:00:00Z",
"primitives": {
"checkout.new_flow": {
"type": "flag",
"entries": [
{ "asOf": "2026-04-22T00:00:00Z", "version": 12, "value": false,
"reason": { "kind": "default" } },
{ "asOf": "2026-04-23T14:08:11Z", "version": 13, "value": true,
"reason": { "kind": "rule_match", "ruleIndex": 0,
"detail": { "operator": "$segment",
"segment": "internal_staff" } } }
]
}
},
"truncated": false
}Why this matters
LaunchDarkly, Statsig, Unleash, and PostHog each expose an audit log — a record of edits. Reconstructing what a specific context resolved to over a window means reading every audit row, re-deriving the ruleset by hand, and replaying your own evaluator. Actuator runs that pipeline server-side and returns the timeline as JSON.
2 — Counterfactual preview
A rule edit on a production flag is a write that flips other people's experience. The honest pre-flight check is: against a representative sample of contexts, how does this exact draft rule change resolution vs. the live ruleset? Actuator lets you ask that question without saving anything.
Preview change diffs in the dashboard, CI, or with an agent before committing a change to avoid making costly rollout mistakes in production.
POST /api/v1/envs/$envId/evaluate/preview
{
"spotCheck": [
{ "user_id": "u_1001", "plan": "enterprise" },
{ "user_id": "u_1002", "plan": "starter" }
],
"ruleset": {
"flags": [{
"key": "checkout.new_flow",
"type": "boolean",
"rules": [{ "condition": { "$eq": { "plan": "enterprise" } },
"value": true }],
"defaultValue": false
}]
}
}
→ {
"environmentId": "9f7a32b5-1234-4abc-9def-...",
"liveVersion": 14,
"spotCheck": [
{ "context": {...},
"live": { "checkout.new_flow": { "value": false, ... } },
"preview": { "checkout.new_flow": { "value": true, ... } } },
{ "context": {...},
"live": { "checkout.new_flow": { "value": false, ... } },
"preview": { "checkout.new_flow": { "value": false, ... } } }
]
}Why this matters
None of the major flag systems expose a server-side counterfactual endpoint. You can fake it client-side by running the SDK twice with different rulesets, but only Actuator guarantees the comparison runs through the exact evaluator your production traffic hits — including segment cycles and percent buckets.
3 — Propose & apply
A direct write to a production flag is a one-step action. That's fine for a human operator who's reading the diff and clicking save; it's the wrong shape when an agent is the actor and a reviewer is the gate. Actuator splits the write into two phases: propose stages a change against a captured ruleset version; apply commits it, contingent on the version still matching.
Proposals are single-use and version-aware to prevent drift and conflicts.
POST /api/v1/proposals
{
"envId": "$envId",
"kind": "set_default_value",
"key": "checkout.new_flow",
"value": true,
"expiresInSeconds": 3600
}
→ { "id": "$pid", "status": "pending", "liveVersion": 14, ... }
# Reviewer (or the same agent, after a counterfactual preview)
POST /api/v1/proposals/$pid/apply
→ { "status": "applied", "appliedVersion": 15, "appliedAuditId": "..." }
# OR, if the live ruleset moved
→ 409 version_drift { "liveVersion": 15, "proposedVersion": 14 }Why this matters
Actuator's propose/apply workflow is built in: every proposal records the change, the proposer, and the approver. The full lifecycle is visible in the audit log.
4 — MCP-native server
Every flag system has an MCP server now. The differentiator is which tools. Actuator's MCP surface mirrors the real world usage vocabulary: change proposals, low-risk direct edits, navigation and describe tools, and the read tools an agent uses to reason about impact.
Permission-based enforcement at every step prevents production changes without explicit oversight and approval.
# claude_desktop_config.json
{
"mcpServers": {
"actuator": {
"command": "npx",
"args": ["-y", "@actuator/mcp"],
"env": {
"ACTUATOR_BASE_URL": "https://actuator.example.com",
"ACTUATOR_API_KEY": "act_..."
}
}
}
}Why this matters
Actuator exposes clear verb-based actions that make it easy for agents to understand human intent and accurately plan changes.
5 — Time-travel evaluation
The complement to per-context history. Pass any past timestamp and Actuator reconstructs the ruleset from the audit log. The response is identical to a live evaluation.
POST /api/v1/envs/$envId/evaluate
{
"context": { "user_id": "u_1001", "plan": "enterprise" },
"asOf": "2026-04-23T14:00:00Z"
}
→ {
"environmentId": "9f7a32b5-1234-4abc-9def-...",
"context": { "user_id": "u_1001", "plan": "enterprise" },
"version": 0,
"asOf": "2026-04-23T14:00:00Z",
"evaluations": {
"checkout.new_flow": {
"value": false,
"defaultValue": false,
"reason": { "kind": "default" },
"decisionHash": "sha256:7f3a8d..."
}
}
}Why this matters
Every other flag system in the comparison ships an audit log — the record of what happened. None of them ship an evaluator that consumes it. "What did this flag resolve to last Tuesday?" against Actuator is a single API call; against the others, it is a manual exercise in JSON and assumed evaluator semantics.
6 — Predicate-tree reasoning
The evaluation response carries every operator that fired, every short-circuit, every segment lookup, and every percent-rollout calculation.
Traces allow debugging flag evaluation without inferring why any rules were met or not.
Why this matters
LaunchDarkly, Statsig, and PostHog each return a leaf summary — "rule 3 matched" or "fell through to default." Unleash returns nothing structured at all. Actuator returns the full walk, identical across every SDK and the REST API.
Every capability on this page is in every plan; see pricing for scale and retention differences.
Sign up for free.