Agent Release Control MCP: 8 Flags, Kill Switches, Ladders

I shipped a new prompt version to all users on a Friday afternoon. By Monday the support queue had tripled — the new instructions handled refunds confidently and wrongly, and rollback meant a code deploy, review, and release train. Forty minutes of careful rollout practice would have saved a weekend. The deploy system worked. The release system did not exist.

An agent release-control MCP server separates deployment from release: eight OpenFeature flags at the decision points where production risk changes, evaluated before the agent acts, mutated only through approval-gated tools. Three facts anchor the pattern:

• Five to eight flags cover an agent workflow — enabled, mode, prompt profile, model profile, retrieval scope, tool tier, approval gate, incident mode — each with a safe fallback.
• The release ladder runs off, observe, internal, canary, limited beta, progressive rollout — every step with evidence requirements and a rollback action.
• MCP serves workflow operations (inspect, draft, prepare, audit) while the request path evaluates through the OpenFeature SDK — assistants help, they do not decide.

This is the release discipline I now require before any agent touches production traffic, and it composes with the gateway thinking of my shared MCP rules setup. Same fleet control, applied to releases instead of rules.

The Friday prompt deploy that built the ladder

The prompt diff was twelve lines. Staging tests passed because staging traffic never asks about refunds the way real users do — long tails only appear at scale. At 5% traffic the error spike would have been obvious in minutes; at 100% it was obvious in the support queue hours later. Instant rollback would have ended it; the redeploy train took ninety minutes.

Here's the catch. Code review approved the change and CI passed it — every gate designed for code worked. No gate existed for behavior, because behavior releases had no control plane. Feature flags are that control plane: prompt slots, model routes, and tool tiers decided at runtime, reverted in seconds from a dashboard.

That matches the 2026 platform consensus: a bad prompt template can spike inference costs 100x and silently degrade behavior no alert catches. My metered billing showed cost spikes first; flags are the switch that stops them.

The eight flags that cover an agent

Don't do this: one global ai_enabled flag. It works as an emergency switch and explains nothing — prompt, model, retrieval, and tool decisions collapse into a single bit with no per-surface rollback. I keep the global kill switch plus the eight, not instead of them.

The pattern: flags decide, MCP assists, humans approve

flowchart TD
    REQ[Request arrives] --> EVAL[OpenFeature evaluates 8 flags server-side]
    EVAL --> CTX[Controls: prompt, model, tools, approval]
    CTX --> RUN[Agent runs within controls]
    OPS[MCP: inspect, draft, prepare] --> HUMAN[Human approves]
    HUMAN --> APPLY[Mutation applies + audit log]

Evaluation happens before the agent crosses any behavior boundary, in the trusted runtime — never after the call as a label. MCP tools expose inspection, drafting, and rollout preparation to assistants; production mutations require scoped credentials, explicit intent, approval, and audit readback.

Remote deployments authenticate through my token-theft-hardened proxy with CIMD client identity — flag mutation is the highest-value target in the fleet, so it gets the strongest auth.

Step 1: Pin the flag registry

config.py

from pydantic import BaseModel

class FlagDef(BaseModel):
    key: str
    type: str
    fallback: str | bool
    owner: str
    temporary: bool = True
    review_days: int = 30

FLAGS = [
    FlagDef(key="agent-enabled", type="boolean",
            fallback=False, owner="platform"),
    FlagDef(key="agent-mode", type="string",
            fallback="observe", owner="platform"),
    FlagDef(key="agent-prompt-profile", type="string",
            fallback="stable", owner="agent-team"),
    FlagDef(key="agent-model-profile", type="string",
            fallback="conservative", owner="agent-team"),
    FlagDef(key="agent-tool-tier", type="string",
            fallback="search_only", owner="security"),
    FlagDef(key="agent-approval-required", type="boolean",
            fallback=True, owner="security"),
    FlagDef(key="agent-incident-mode", type="boolean",
            fallback=False, owner="platform", temporary=False),
]

Every temporary flag carries an owner and a review date; permanent operational flags carry documentation instead of cleanup tickets. Stale flags are technical debt with a blast radius, so the registry is the cleanup mechanism — expired reviews page the owner weekly.

Step 2: Build the control server

server.py

from fastmcp import FastMCP
from openfeature import api as ofapi
from config import FLAGS

mcp = FastMCP("release-control")
client = ofapi.get_client("agent-release")
PENDING: dict[str, dict] = {}

@mcp.tool()
async def evaluate_flags(ctx, workflow: str) -> dict:
    """Evaluate all eight flags for this context. Read-only."""
    eval_ctx = {"targetingKey": ctx.user.id, "workflow": workflow,
                "env": ctx.env, "tool_risk": ctx.tool_risk}
    return {f.key: await client.get_value(f.key, eval_ctx,
                                          f.fallback) for f in FLAGS}

@mcp.tool()
async def prepare_rollout(ctx, key: str, stage: str) -> dict:
    """Draft a stage change. Returns approval token, applies nothing."""
    plan = ladder_plan(key, stage)  # evidence + rollback checks
    token = mint_token(ctx.user, plan)
    PENDING[token] = plan
    return {"plan": plan, "token": token}

@mcp.tool()
async def apply_rollout(ctx, token: str, approved_by: str) -> dict:
    """Apply a prepared change after human approval."""
    plan = PENDING.pop(token, None)
    if plan is None or not approved_by:
        return {"applied": False, "reason": "invalid or unapproved"}
    try:
        await flag_admin.apply(plan, actor=approved_by)
    except ProviderError as e:
        logger.warning("flag apply failed", extra={"err": str(e)})
        raise
    await audit_log(ctx, plan, approved_by)
    return {"applied": True}

Prepare-then-apply mirrors the preview-confirm shape from my Docker fleet server: the draft is inspectable, the mutation is single-use and attributed. Assistants draft at machine speed; humans approve at human speed; the audit log records both.

requirements.txt

fastmcp==2.10.0
openfeature-sdk==0.9.0
pydantic==2.8.0
httpx==0.28.1
structlog==24.4.0
python-dotenv==1.0.1

Pydantic v2.8 needs extra="allow" on evaluation-context schemas or nested targeting attributes fail validation. I lost an afternoon to that exact error before pinning it.

Connect Cursor and Claude Code via the standard entry, STDIO locally or gateway URI remotely. Evaluation context must include agent attributes — workflow, agent ID, tool risk, session — or every rollout degrades to global-or-adhoc.

Step 3: Climb the ladder with evidence

Off to observe first: the agent proposes without executing, and you collect intended tool calls plus evaluator verdicts. Internal next: employees on low-risk behavior, watching latency, cost, and answer review. Canary at 5%: error rate, support signal, quality review against the control. Each stage defines its rollback before traffic moves — revert prompt, narrow audience, restore mode. My prompt-profile canaries now catch regressions in eleven minutes median, against the ninety-minute redeploy era.

The cost-spike war story: guardrail flags pay rent

A model swap that looked clean in staging doubled token usage on long-tail queries — same answers, twice the tokens, $600 over budget in a weekend. A guardrail flag returning a cost-control object (token caps, model route, per-user limits) would have contained it automatically. Now every model profile carries budget ceilings evaluated before the call, and spend alerts pause rollouts before humans wake up. The flag paid for the whole system in one incident it would have prevented.

When NOT to build this

Let's be clear. A solo side project needs a config file, not eight flags — ceremony without traffic is just latency. Flags evaluated after the AI call are labels, not controls; if your architecture cannot evaluate first, fix that before adding surfaces. And hard authorization boundaries stay separate — flags are release controls, not access control, and conflating them invites bypasses.

Skip it for toys and post-hoc labels. Build it where agent behavior reaches production traffic, where one prompt diff once tripled a support queue, and where rollback must take seconds, not sprints.

Eight flags, one ladder, and the whole class of Friday-deploy incidents collapses: behavior releases with evidence gates, cost guardrails that act while you sleep, and kill switches measured in seconds.

By Deepak Bagada, Founder & Editor-in-Chief at Daily AI World.