Gate any agent action by type, value, or custom condition, and route it to the right person for review before it executes. This guide covers defining gates, routing approvers, and what happens while an action is pending.

What can be gated

Any discrete action an agent takes can be gated — a refund, a data deletion, a production deployment, an outbound email, a database write. Gates are defined per-agent and can be as broad or as narrow as you need.

Defining a gate

Add an approvals block to your agent config:

approvals:
  - action: refund
    condition: "amount > 100"
    approver: finance-team
  - action: delete_record
    condition: "always"
    approver: data-team

approvals:
  - action: refund
    condition: "amount > 100"
    approver: finance-team
  - action: delete_record
    condition: "always"
    approver: data-team

approvals:
  - action: refund
    condition: "amount > 100"
    approver: finance-team
  - action: delete_record
    condition: "always"
    approver: data-team

Each gate specifies the action type, an optional condition (omit condition or use "always" to gate every instance of that action), and who should approve it.

Routing to approvers

Approvers can be an individual (approver: jane@company.com), a team (approver: finance-team, configured in your workspace settings), or a role (approver: role:admin). Sublayr routes the request to whoever matches and notifies them via email, Slack, or both, depending on your notification settings.

What happens while pending

When an agent hits a gated action, it pauses that specific action — the rest of the agent's run continues normally if it doesn't depend on the gated step. The pending request appears in your dashboard's Approval Queue with full context: what the agent wants to do, why, and any relevant data (e.g. the customer record, the refund amount, the exact database query).

Responding to a request

Approvers can respond directly from the notification (Slack) or from the dashboard:

• Approve — the action executes immediately with the exact parameters proposed

• Request Changes — the agent receives feedback and can propose a revised action

• Reject — the action is cancelled and logged; the agent handles the rejection according to its own logic (e.g. notifying the user)

Setting expiration

You can set how long a request waits before escalating or expiring:

approvals:
  - action: refund
    condition: "amount > 100"
    approver: finance-team
    timeout: 4h
    on_timeout: escalate
    escalate_to: finance-lead

approvals:
  - action: refund
    condition: "amount > 100"
    approver: finance-team
    timeout: 4h
    on_timeout: escalate
    escalate_to: finance-lead

approvals:
  - action: refund
    condition: "amount > 100"
    approver: finance-team
    timeout: 4h
    on_timeout: escalate
    escalate_to: finance-lead

Testing approval flows

Before deploying to production, test your approval flow in staging by triggering the gated action manually and confirming it routes to the expected approver, notifies via the expected channel, and behaves correctly on approve, reject, and timeout.