The Missing Infrastructure Layer for AI Agents Writing to Production

An AI agent that reads your CRM does no damage. It scans, pulls context, misses a detail at worst. The moment that same agent starts writing — sending emails to real leads, updating 847 records, posting to live channels, processing webhooks — everything changes.

One bad retry and a lead gets two AI calls in 30 seconds. One unresolved template variable and hundreds of contacts receive "Hello {{customer_name}}." One enrichment run with partial data and your CRM is corrupted with no rollback path.

These aren't theoretical. They happened. The teams that experienced them didn't lack engineering talent — they lacked infrastructure for the write path.

The 3 Failure Modes That Keep Happening

Each one had a policy that would have stopped it. None of those policies existed at the time.

The pattern across all 3: the agent had write access, no policy enforced a check, and something shipped that shouldn't have. The fix was obvious in retrospect. The problem is "in retrospect" means the damage was already done.

Why Scattered Approval Logic Doesn't Scale

Most teams handling this build the same thing: a Discord bot, a Slack hook, some custom middleware, a dedup JSON file. We run exactly that stack. It works — until it doesn't.

• Framework HITL is opt-in. LangGraph's human-in-the-loop mechanism is different from CrewAI's, which is different from OpenAI Swarm's. A developer forgets to wire it up. Something ships unchecked.
• No cross-team visibility. Marketing's agents and Engineering's agents aren't sharing an audit log. Nobody knows which agent wrote what, when, or why.
• No verified sender identity. Your Slack bot trusts whoever calls it. An unknown agent triggers approvals the same way a known one does.
• Logs scatter across repositories. Debugging what happened requires hunting through 4 codebases. The post-mortem takes longer than the incident.

Scale from 3 agents to 15 and you scale the chaos proportionally. There's no architecture here — just wires holding things together.

What Zehrava Gate Actually Is

Zehrava Gate is MIT-licensed open source infrastructure — a commit checkpoint between AI agents and production systems. Every agent write goes through a 5-step process before it touches anything real.

1. 1
   Agent proposes an intent

   The agent calls gate.propose(). Gate verifies the sender against an agent registry. Unknown agents are rejected before any policy runs.

2. 2
   Gate evaluates policy

   Schema validation, PII detection, record count thresholds. The team defines the rules. Gate enforces them on every proposal, every time.

3. 3
   Block, auto-approve, or queue for review

   Low-risk writes pass automatically. High-risk writes route to a dashboard. A human decides. The agent waits.

4. 4
   One-time signed execution

   The agent calls gate.execute() after approval. The execution token is signed and expires. A second request returns HTTP 410. Cannot be replayed or reused.

5. 5
   Immutable audit trail

   Every event is logged. Not deletable. Not editable. The record exists regardless of what happens downstream.

Run those 5 steps against the 3 incidents above. Duplicate intents blocked at step 3. Template errors flagged at step 2, queued for human review. 847-record writes caught by the count threshold policy, never auto-approved.

The API

Four methods. That's the entire surface.

# Propose an intent
intent = gate.propose(
    agent_id="kai-outreach-v2",
    action="send_email",
    payload={"to": lead_email, "subject": subject, "body": body},
    idempotency_key=lead_id
)

# Human or policy approves
gate.approve(intent["id"])

# Execute the approved action (one-time, signed)
result = gate.execute(intent["id"])

# Close the audit trail
gate.verify(intent["id"])

Intent Statuses

gate.propose() returns one of four statuses:

• approved — policy passed, no human review required. Proceed to gate.execute().
• pending_approval — policy passed but human review is required. Wait before executing.
• blocked — policy rejected the intent. Inspect blockReason.
• duplicate_blocked — idempotency_key matched an existing intent. Already submitted. Do not retry.

Handle all four. Missing duplicate_blocked is the most common source of retry loops.

status = intent["status"]

if status == "approved":
    gate.execute(intent["id"])
elif status == "pending_approval":
    queue_for_review(intent["id"])
elif status in ["blocked", "duplicate_blocked"]:
    raise GateError(intent["blockReason"])

Cross-Framework Governance

Gate works across CrewAI, LangGraph, OpenAI Swarm, AutoGen, LangChain, Claude Code, and any MCP client. The Gate sits above the framework layer — the framework running the agent is irrelevant to policy enforcement.

Property	Framework HITL	Zehrava Gate
Opt-in vs mandatory	Opt-in. Dev forgets. Ships.	Policy-driven. Always enforced.
Coverage	Siloed per framework	One queue, every agent, every team
Sender identity	Anonymous	Verified against agent registry
Audit trail	Console logs across scattered repos	Single immutable log, all agents
Cross-team visibility	None	One approval queue, all teams

How We Use It

Current governance for the MeetKai stack: Discord reaction approvals, dedup JSON files, a heartbeat check system. It works. It's also exactly the scattered approval logic Gate was built to replace.

Gate replaces the stack with a single layer. One place to define policy. One approval queue across every agent. One audit trail that answers post-mortem questions automatically.

The KaiCalls lead outreach script now proposes to Gate before posting anything to Discord. If Gate blocks — duplicate, template error, policy violation — the Discord message never fires. If Gate approves, the message includes the proposal ID and a link to the dashboard. Approval happens in one place whether the reviewer is in Discord or not.

Install

npm install zehrava-gate
# or
pip install zehrava-gate

MIT licensed. Self-hosted. zehrava.com — live demo and dashboard included.