I think most “AI agent” projects fail because people skip the boring permission layer

I’ve been building an AI chief-of-staff style product in public, and the thing I keep coming back to is this: The model is not the product. The permission system is. A lot of AI agent demos look impressive because the agent can “do stuff”: read emails summarize Slack create tasks draft replies edit files update CRM records schedule meetings Cool. But the scary part is not whether the agent can call the tool. The scary part is whether it should. Here’s the permission architecture I’m using mentally now: 1. Read-only layer The agent can inspect context but cannot change anything. Examples: read docs summarize recent messages analyze CRM notes inspect project status 2. Draft layer The agent can prepare an action, but not execute it. Examples: draft email create proposed task list prepare invoice follow-up generate meeting agenda 3. Approval layer The agent shows what it wants to do, why, and what data it used. I like this format: 4. Limited execution layer The agent can execute low-risk tasks within constraints. Examples: tag lead as “needs reply” move task to “waiting” create draft calendar block update internal note 5. Audit layer Every action gets logged. Not just: “Agent sent email.” But: what triggered it what context it used what tool it called what changed whether user approved it rollback path if possible My current rule: If the agent touches something external, expensive, customer-facing, or hard to undo, it needs an approval gate. This makes the product less “magical” in demos, but way more usable in real businesses. Curious how others are handling this: do you let agents execute actions directly, or do you keep them in draft/recommendation mode?