How much should an AI decide without asking you first?

Any AI product that does things, not just says things, runs into the same decision problem sooner or later. The AI assistant can ask before acting, or act and tell you afterward. Both easy answers are wrong. If it asks every time, you stop reading the questions and click yes on reflex, so the questions end up protecting nobody. If it never asks, everything is fine until the first time it does something you didn’t expect, and that single surprise is enough to end your trust in it.

We’ve been working on this problem in Sidekick, Zapier’s new AI workspace. This is how it has gone so far, including the parts we got wrong.

Why neither extreme scales

Rubber stamping is easy to picture. Imagine an assistant that asks permission to read a file, then another file, then to search the web. By the tenth card nobody is evaluating anything, so the eleventh, which happens to email a customer, gets approved with the same thumb. The opposite failure is quieter. An assistant that never asks can run for weeks without a problem, and then one Tuesday it deletes the wrong folder, and the good weeks don’t count for much.

The question worth asking is which decisions belong to you and which belong to the AI. How often it interrupts you follows from the answer.

Iteration one: ask about every tool

We started where most agent products start. The first version of the agent split its tools into two groups. Reading ran on its own. Anything that changed something, like writing a file, editing a document, or moving or deleting things, stopped and showed a card with three choices: Block, Once, or Always.

That was enough to ship, but the problems showed up one at a time. First, the approval request only existed in the browser window you had open. If you closed the tab, the request disappeared. You also couldn’t answer it from anywhere else, like Slack. And if you picked “Always,” Sidekick forgot your choice as soon as you refreshed the page. We fixed this by saving approvals on our servers, so you can answer from any place you use Sidekick.

Other problems made the experience confusing. If an action fails, Sidekick may ask you to approve it again and again. Approval requests sometimes got hidden inside collapsed sections of the conversation, where you couldn’t see them. And Sidekick showed a request even for harmless steps like reading a file, so the important questions got lost among the routine ones. Finally, the buttons “Once,” “This chat,” and “Always” didn’t provide enough information to decide. We rewrote them to say exactly what you’re allowing, for example, “Allow editing files for this chat.”

In hindsight, asking was cheap to build and hard to make meaningful.

Iteration two: put the rule on the resource

A few months later, we found a deeper problem. Sidekick had two separate systems deciding what needed your approval. One covered its built-in abilities, like editing a file. The other covered the small programs Sidekick writes and runs to work with your apps, like Slack. They had been built at different times and didn’t share rules, so they sometimes gave different answers about the same kind of action. That made Sidekick hard to predict, and hard for us to explain.

There was a second problem. Every rule was tied to a tool, so the question on the card was really “may I use the write tool?” But that isn’t what you care about. You care about what’s at risk, such as your Slack account, a particular folder, or one important doc. A rule about the tool couldn’t say “never touch this doc” or “only message me, not my coworkers.”

So we rebuilt it around the thing being protected. Rules now attach to the file, the connected app, the website, or the automation itself, and one set of rules applies however Sidekick tries to act. You can say “never change anything in this folder” or “only send Slack messages to me,” and that holds whichever way Sidekick goes about it.

We also made the rules strict and predictable. If any rule says “never,” that wins. Otherwise, if a rule says “ask first,” Sidekick asks. Only if nothing blocks it does Sidekick go ahead without asking. The same situation gets the same answer every time, so you aren’t guessing what Sidekick will do.

The card got simpler: Cancel, Allow, or Allow and configure rule. The agent also got a skill for reading and editing its own rules so it could explain why something had been blocked. We added a guardrail we’re glad we have. The agent can’t propose a blanket “allow all code execution” rule, even if the user would click through it, because one click that quietly grants everything would wear away the trust the system exists to protect.

The result was correct but hard to understand. Not everyone on the team saw the difficulty as a flaw. One tester had built a good share of their business on Sidekick because the permissions were deterministic, and a single faulty call can do real damage. Whatever came next had to keep that floor.

Iteration three: make the ask legible

A permission prompt with no specifics is worse than no prompt, because it hands someone a decision and withholds what they’d need to make it. We had our own examples. For a while, the card for “change my permissions,” the highest-stakes request the agent can make, showed the proposed rule as a block of raw JSON. We replaced it with readable rows showing an Allow, Ask first, or Deny badge, the scope, an “Only when” line, and account names in place of connection IDs. The agent writes a friendly label for each rule, but the real scope always appears underneath, so a label can’t hide what is being granted.

Then there was “Allow and configure.” The button promised to set up a permission, but it only left a note for the agent, which often forgot. People clicked, saw nothing change, and got asked the same question again. Internally, we saw it as the thing most likely to make a new user give up. We fixed it in stages, and the version that stuck opens a side chat that handles the setup without blocking the main conversation. A single line lands in the transcript when it finishes, something like “Permission configured: only sending DMs to myself for Slack.”

We also tried to get ahead of the question. A suggested permissions flow reads someone’s past one-off Allow and Deny decisions and proposes standing permissions as cards they can toggle. Another experiment let the agent rewrite its own code and retry when it nearly matched something the user had already allowed. We shelved that one but kept the instinct behind it: to spend the AI’s effort before a person’s attention.

Chat is a poor place to review things

Chat is built for trading messages, which makes it awkward to stop and review a proposed action carefully. You can bury the detail in a text bubble where nobody reads it, or you can interrupt so firmly that approving things feels like filling out a form.

So we stopped asking for review inside the conversation. Approval requests, questions from Sidekick, and proposed plans no longer appear as messages in the chat. They now sit in a panel attached to the box where you type, so they’re hard to miss and don’t get buried under the messages around them. This also meant review no longer depended on chat at all. The same panel works when you’re editing a document with no conversation next to it.

Next we had to decide how much attention that panel should demand. One option was to require you to set up permissions before Sidekick started working. The other was to keep the panel out of the way while Sidekick works and open it when there’s something for you to review. We chose the second. You had already decided to let Sidekick take on the task, so making you stop and configure things first felt like a toll booth.

The last gap was approvals you never saw. If you left the screen where a task was running, a request could sit there waiting without you knowing. So approvals now also appear in an inbox you can open from anywhere in Sidekick.

The pivot: rules in your own words

A few months later, one of our engineers argued that we were pushing uphill. The strict rules worked well for protecting people, they said, but most people want to manage permissions by saying what they mean in plain English, not by writing rules. They built a prototype of an “auto mode.” In it, an AI reviewer reads the rules you’ve written in your own words and decides on your behalf whether an action is okay. They were upfront about the cost: it means trusting an AI’s judgment with more decisions.

The team was split, and the split is the most useful part of this story. The skeptics said predictability was the whole point of the product, and that we should fix the everyday experience before adding anything else. The other side said the everyday experience was already close to intolerable, and that we can’t expect non-technical people to write precise rules. Both had a point, and the design we shipped keeps both. Your rules stay the hard floor, and Sidekick always checks them first. The AI reviewer only steps in when your rules don’t cover a situation.

That gave us two modes, each with a different promise. In Auto mode, an AI reviewer checks each uncovered action against our baseline safety guidance and your rules, and asks you when it isn’t sure. In YOLO mode, short for “dangerously skip permissions,” Sidekick simply allows everything your rules don’t cover, with no AI check at all. We built YOLO as a plain “allow everything” setting instead of just telling the AI reviewer to be more relaxed, for three reasons. A relaxed reviewer can still slip past a rule that says “ask first” or “never.” It still costs an extra AI check on every action. And its answers can vary from one time to the next. Even in YOLO mode, your “never” and “ask first” rules still win, and Sidekick still has to ask before it changes its own permissions.

What happened when people tried Auto and YOLO modes

A few weeks after the modes were released to pilot users, someone reported that YOLO mode was requesting permission. Their reasoning was fair, since they understood the whole point of YOLO to be that it doesn’t ask. The agent had been trying to edit its own permissions, one of the cases YOLO deliberately refuses to skip. The behavior was correct, and the name had promised something the system would never deliver.

Of everything we learned, the hardest part was writing the rule for the middle ground: what the AI reviewer should do when none of your rules apply, and it has to use its own judgment. Our first wording told it to be careful with anything that reached beyond your own data. Then it stopped to ask permission before a simple search of your own files, because it read “search” as reaching outside. Nothing was broken. The instruction was just unclear in a way we couldn’t see until we tried it on real actions. We fixed it by spelling out that reading your own data is fine. The lesson is that a rule written in plain English is part of the product, and it needs testing against real actions like any other feature you ship.

Where the next mode is heading

In mid October, we told the people testing YOLO that it was going away. Skipping every approval turned out to be the wrong shape for the feature. We’re now working on a new mode that builds on everything we’ve learned. It’s still in progress, so details may change before it ships.

The idea behind it is simplicity. There is one set of rules, and it applies no matter which mode you’re in. Switching modes no longer changes which rules are in force. It only changes what happens when none of your rules cover an action.

It also puts the earlier lesson to work. The judgment call for those uncovered cases rests on the two ideas we started this post with: how easily an action can be undone and the context it happens in, now written down as a plain instruction. Writing it down made it testable, which is how we found the file search problem.

Unlike YOLO, the new mode doesn’t mean giving up protection. Every action is still checked against your rules, and sensible defaults are built in. Anything that reaches outside Sidekick, like sending a message, asks first. Agreeing to legal terms and making payments are never allowed. If you want fewer prompts, you edit your rules and leave the mode alone.

How to judge permission prompts in any AI product

Email assistants that draft replies, coding agents that edit files, and scheduling tools that move meetings all live with this tension. Zapier’s guide to human-in-the-loop AI workflows covers the same problem from the workflow side. Coding agents have gone through a similar sequence in public, from approving everything to allow lists to an auto mode where a second model reviews each action.

Whether a product asks permission tells you very little. A better test is whether you understand what you’re agreeing to when it does ask. Our experience added a second test: whether you can state your rules in your own words and whether the product tells you which one applies.

We started by asking, “May I use this tool?” and we’re ending up closer to, “Here are my rules, and this is the one that fired.” A product can ask a hundred times a day and still be easy to trust, if each question shows you what is about to happen. The next time an AI tool does something on your behalf, check its permission settings and see whether you can explain, in your own words, why that action was allowed.

Get AI and automation tips, delivered straight to your inbox

We’ll email you 1-2 times per week—and never share your information.