Gates

The checkpoints that stop iHarness: what gates guard, where approvals happen, and per-tool approval modes.

A gate is the checkpoint between a proposal and the real world. iHarness can think, plan, and draft freely; the moment an action would commit something, budget, sends, credits, a change to your CRM, it stops at the gate and waits for a human.

What gates guard

Gates sit exactly where spend and consequence sit: activating a play, pushing an audience to a channel, writing to CRM records, committing budget. Reading, scoring, and drafting never need a gate, which is why the system can be always-on without being dangerous.

One approval, anywhere

An approval request reaches you where you are: in Pulse, in chat, in Slack. It is the same request in every surface, and approving in one place resolves it everywhere. The approval itself, who, when, for what, is recorded on the decision's trace.

Per-tool approval modes

Gates are tunable per tool, three modes:

• Always allow: the action runs without asking. For reads and low-stakes writes you trust.

• Needs approval: the default for anything that writes. The action waits for you.

• Blocked: the action is off entirely.

Writes default to needs-approval. As trust builds, you widen specific gates deliberately, which is the practical mechanics behind Autopilot vs approval-first.

Gates are not friction

A gate fires once per commitment, not once per step. Approve a play and it runs, within its bounds, without re-asking on every send. The design goal is a system that asks rarely, asks clearly, and never acts beyond what you granted.