Approval gates: what Marg asks before acting

What you'll get

The confidence to hand over real work, which only ever comes from knowing precisely where Marg stops and asks you. The whole model fits in one sentence: an action is gated by how hard it is to undo. The rest of this chapter is that sentence made concrete, tier by tier.

The tiers, from free to gated

The four tiers form a ladder, with the freedom narrowing as the consequences grow:

Reading is free. Pulling your metrics, searching the web, reading your CRM, analyzing your data, all of it runs without ceremony, because the worst case of a read is a wasted minute.

Drafts and files are visible but ungated. Writing analysis, creating a document, building a model in Drive happen as ordinary work, and each one lands somewhere you can see it and undo it.

Money and external changes stop for you. Four categories always pause for an explicit yes before they run: payment actions, database schema changes, merges into protected branches, and bulk changes to CRM records. Each gate shows you the action before it happens, not after.

Some things never run automatically at all. Sending a deliverable to your clients or customers is the clearest example. The Blueprint (chapter 19) ends at a human review step by design, and that pattern holds anywhere Marg's output would otherwise land in someone else's inbox under your name.

The standing guardrails

Underneath those interactive gates sit always-on protections that ask nothing of you. Payment actions are capped at a configurable maximum, 5,000 in account currency by default. Destructive commands are blocked outright. Parallel work is limited so a runaway request cannot multiply itself across your systems. These hold in every session whether or not you remember they are there, which is the point of them.

The steps, when a gate fires

1. Read the gate message. It names the action, the target, and the scale, in plain terms like "create 200 HubSpot records" or "apply migration to production database."

2. Approve or decline in plain words. Approving runs exactly the action named, nothing more. Declining cancels it, and the work continues around the gap wherever it can.

3. Adjust the defaults if your tolerance differs. The payment cap, for one, is a setting rather than a fixed law. Raise or lower it once, deliberately, instead of relitigating it at every transaction.

What this means in practice

You can run Marg with live keys to your billing, your CRM, and your database and still sleep at night, because the blast radius of anything irreversible has to pass through your explicit yes first. The teams move fast inside the safe zone and stop dead at its edge, which is exactly the behavior you want from something acting on your behalf.

If something goes wrong

• A gate fires on something you consider routine: that is the gate erring toward safe, which is the right direction to err. Approve it, and if the same gate becomes real friction, say a weekly bulk CRM update, ask to adjust that threshold rather than living with the nag.
• You declined and the workflow stalled: ask for the alternative. Most gated actions have a reversible cousin, a draft instead of a send, a staging change instead of production, and declining usually routes you there.
• Something external changed that you did not approve: check /marg:status and the task history first, since the append-only log records what Marg ran and when. If the change came from outside Marg, a teammate or another tool, the log shows no entry, and that absence is itself your answer.