> For the complete documentation index, see [llms.txt](https://docs.aloop.icustomer.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aloop.icustomer.ai/iharness/gates.md). # 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](/pulse/queue.md), 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](/concepts/decisions-and-traces.md). ## 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](/pulse/autopilot-vs-approval-first.md). ## 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.aloop.icustomer.ai/iharness/gates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.