March 12, 2026
Approval Gates: How Many Is Too Many
Every added approval step reduces risk and adds friction. The design question for any AI-assisted process is finding the smallest number of gates that still catches the mistakes that matter.
The case for fewer gates
A process with an approval step after every single sentence defeats the purpose of automating anything, the partner ends up doing as much work reviewing as they would have doing the task themselves. Over-gating a process is a common overcorrection after a single bad experience, and it usually kills adoption.
The case for more gates
A process with only one gate at the very end, after a long automated chain of research, drafting, and formatting, means a mistake introduced early can compound silently through several steps before anyone looks at it. By the time it surfaces, the fix requires redoing much of the chain.
A workable pattern
Two gates tend to cover most business-development workflows well: one after research and planning, before drafting begins, and one final approval before anything reaches a client or prospect. The first catches a wrong direction early and cheaply. The second is the non-negotiable check on anything client-facing. Anything beyond these two should be justified by a specific, recurring failure mode, not added by default.
Where firms get the gate count wrong most often
The most common mistake is not too many or too few gates in the abstract, it is placing the one unavoidable gate too late in the process, after a long chain of automated steps rather than right before the final send. A firm can run an elaborate five-step automated research and drafting chain internally and still keep to a single external gate, as long as that gate sits at the true point of no return and nowhere earlier is treated as good enough to skip it.
A short audit worth running once a quarter
Pick a handful of recent client-facing deliverables and trace, in writing, exactly which gate each one passed through and when. If any deliverable's trail is unclear or the gate appears to have been skipped under deadline pressure, that is a more urgent finding than any theoretical debate about the right number of gates, and it deserves immediate attention regardless of how the rest of the process is designed.
Where this leaves a firm
None of this is complicated in principle, which is exactly why it gets skipped under deadline pressure. The question worth returning to before treating letting a tool act across several steps responsibly as settled is what a careful reader would actually notice if the firm got it right. On the point raised above under “the case for fewer gates,” the answer is usually specific rather than clever: over-gating a process defeats the purpose of automating it in the first place. Firms that build this expectation into how they train new associates find it easier to sustain once experienced staff move on, because the standard lives in a documented habit rather than in one person's memory. The gap between a firm that talks about letting a tool act across several steps responsibly and a firm that actually practices it shows up over several quarters, not in any single engagement, and it tends to show up most clearly in the small, unglamorous checks that a client never sees directly but benefits from anyway.
It also helps to name, plainly, who is responsible for keeping this working once the novelty of a new tool wears off. Someone should own the point raised under “the case for more gates,” check it periodically rather than assume it stays true on its own, and be the person a colleague asks when a new situation does not fit the pattern described here. Put simply: add gates only in response to a specific, recurring failure, not as a default habit. That kind of ownership, named and specific, is a small addition to a firm's process, and it is usually the difference between a good idea that is followed for a month and a standard that actually holds up over a year of real client work.
None of this needs to be elaborate to be effective. A short, dated note in a shared file, reviewed at the next quarterly check-in, is usually enough to keep the responsibility from quietly disappearing when the person who first cared about it moves on to something else.
Key takeaways
- Over-gating a process defeats the purpose of automating it in the first place.
- Under-gating lets an early mistake compound silently through later steps.
- A two-gate pattern, after planning, and before send, covers most workflows well.
- Add gates only in response to a specific, recurring failure, not as a default habit.