Human-in-the-loop and Gatekeeper patterns for enterprise agents

Enterprise agents fail when they can call irreversible tools without oversight. Two complementary controls matter:

1. Authorization — should this tool call be allowed at all?
2. Human-in-the-loop (HITL) — should a person approve before it executes?

Mixing those up is common. Teams either block everything behind a human (too slow) or authorize nothing and hope the model is careful (too risky).

Gatekeeper-style authorization

In HazelJS, Gatekeeper evaluates protected tool calls with a default-deny posture. The point is not theater — it is a hard stop when a tool is out of policy for that agent, tenant, or context.

Useful properties of this pattern:

• Model confidence is not permission
• Policies can differ by environment (sandbox vs production)
• Denied calls are observable, not silent

Docs: Gatekeeper and Decision Runtime.

Crash-safe HITL

Approvals should survive process restarts. If a refund is waiting on a manager and the pod dies, the run should resume in the same waiting state — not re-fire the refund or lose the request.

Durable HITL typically needs:

• Persisted run state
• A clear resume API or operator UI
• Timeouts and escalation when nobody responds
• An audit trail of who approved what

Designing the approval surface

Bad HITL dumps raw JSON on an engineer. Better HITL shows:

• What the agent intends to do in business language
• Why it believes the action is needed
• What will happen if approved or rejected
• Links to the underlying record (order, ticket, account)

HumanBee designs that UX with your operators — not as a generic chat modal bolted on at the end.

How HumanBee helps

We map irreversible actions, design approval UX, and implement policy with your security constraints — without inventing compliance certifications you do not have.

If you already have an IAM or workflow system, we integrate with it where it makes sense instead of forcing a parallel approval world.

Discuss governance for your agents.