Build the human gate once, in the platform, and make every workflow pass through it. A gate rebuilt inside each workflow is only as strong as the team that rebuilt it, and the hundredth copy will have a gap. A platform gate applies the same rule to every agent and every path, so no new workflow can quietly route around it.
What goes wrong when each workflow owns its own gate?
Most firms start with one agent in one process. The team building it adds a step: before the refund is issued, send it to a supervisor for approval. That works. Then a second team builds a complaints workflow and adds its own approval step. A third builds a collections workflow and decides a gate is only needed above a certain amount.
Each gate is reasonable on its own. Together they make a patchwork. Thresholds differ for no stated reason. One workflow checks the approver is not the person who raised the request; another forgets. One records who approved and when; another records only that approval happened. When an auditor asks how the firm ensures a person approves every refund over a set amount, the honest answer is "it depends which workflow".
Worse, a workflow can be changed. A developer fixing a bug can reorder steps, or add a shortcut path for a retry, and the gate stops being on the path. Nobody intended to remove it. It simply was not where the action happened any more.
Why does a platform gate hold up better?
A platform gate is attached to the action, not to the route. If the rule is that any payment over the customer's limit is held for a named person, the platform enforces that rule whenever an agent attempts that payment, whichever agentic workflow the agent is running inside.
That gives three properties a per-workflow gate struggles to match.
| Property | Gate in each workflow | Gate in the platform |
|---|---|---|
| Consistency | Thresholds and approver rules drift between teams | One rule, applied to every agent attempting the action |
| Coverage of new paths | A new workflow has no gate until someone adds one | A new workflow inherits the gate automatically |
| Resistance to change | A refactor can move the action off the gated path | The gate sits at the action, so reordering steps cannot skip it |
| Evidence | Each team records approvals in its own format | Every hold and release is filed the same way |
The last row matters more than it looks. When every hold and release lands in the same record with the same fields, you can answer questions across the whole firm: how many payments were held in a given month, how long they waited, who released them. With per-workflow gates, that answer requires stitching logs together by hand.
Is this just workflow automation with extra steps?
No, and the difference explains why platform gates matter more for agents than for older automation. A scripted workflow follows a fixed path. If the gate is on that path, every run hits it. The path is the control.
An agent is different. It chooses its next step from the situation, which is the point of using one, and the reason an AI agent differs from workflow automation. That choice means the path is not fixed. An agent asked to resolve a complaint might decide the best route is a goodwill payment, a route the workflow designer never drew. If the gate lives on the drawn path, the agent's chosen path skips it.
So for agents, the control has to live where the action is executed, not where the designer expected the action to be. The platform is the only place that sees every action regardless of how the agent arrived at it.
Which gates should live in the platform?
Not every approval belongs at platform level. A team may reasonably want an extra review step for its own reasons. The platform should hold the gates that must never be missing.
- Any action at depth 4: moving money or taking actions that are hard to undo.
- Any action above the customer's own limits for that capability.
- Any action resting on a fact whose provenance cannot support it.
- Any action by an agent whose certificate for that capability has lapsed or failed.
- Separation rules, such as the approver not being the agent or the person who raised the request.
Teams can add gates on top. They should not be able to remove these. A platform guardrails register is a practical way to list them, name an owner for each and record when each was last reviewed.
Does this make workflows harder to build?
It makes them easier. A team building a new process no longer has to design, test and evidence its own approval mechanism for each risky action. It can rely on the platform to hold what must be held and spend its effort on the work itself. The guide on how to add a human gate to an agent workflow covers the cases where a team does want an extra step of its own.
The trade-off is central ownership. Someone has to own the platform gates, decide thresholds with the business, and handle requests to change them. That is a real cost, but it is the same cost firms already accept for access control and payment limits. Human gates for agents are the same kind of control.
Where Pryme fits
In Pryme, human gates are part of the minimum chain that every action meets at the moment it runs. An action that needs a person returns the verdict "held": drafted and waiting for a named approver. The gate does not depend on which workflow the agent is in. For the full set of bounds, see the governed agentic operating system, explained.
What should you do differently?
Audit where your current approval steps live. If they sit inside individual workflows, list them, compare their rules and note the differences. Move the ones that must never be missing into a single layer that every agent action passes through, and let teams add stricter steps on top if they need them.
Questions people ask
Can a business unit override a platform gate?
It should be able to tighten one, not loosen one. Loosening a platform gate is a change to the firm's control framework and should go through the same approval as any other control change.
What happens if the approver is unavailable?
The action stays held. A gate that releases automatically after a timeout is not a gate. Set up cover so a held action can reach another named person with the same authority.
Do platform gates apply to agents built by vendors?
They should apply to every agent that acts through your platform, whoever built it. If an external agent can act on your systems without passing through your gates, that is a gap to close before anything else.