Connic

A human in the loop
where it matters

Pause sensitive tool calls for human review. Approve or reject in the dashboard or via REST API. Time-bounded, conditional, audited.

Start Building FreeRead the deep dive
Read the approvals docs

Approvals

Pending
order-handler
stripe.refund
2m ago
customera.smith@acme.com
amount€129.00
reasonduplicate charge
The flow, end to end

Pause. Review. Decide.

A sensitive tool call enters the queue. A human decides. The agent picks up where it left off, or stops with a clear reason.

  1. 01

    Agent calls a gated tool

    process_refund(amount=129)

  2. 02

    The run pauses

    Status flips to Awaiting Approval. The agent stops; the request stays alive.

  3. 03

    Reviewers are notified

    Email and in-app by default. Optional webhook forwards to Slack, Teams, PagerDuty, or your own workflow.

  4. 04

    A reviewer decides

    Approve or reject from the dashboard or via REST API.

  5. 05

    The run resumes

    Or fails with the rejection reason. With on_rejection: continue, the agent adapts instead.

Define a gate

From one line to a policy

List the tools to gate. Add a condition to scope approval to the calls that actually matter.

Simple
agents/order-handler.yaml (snippet)
approval:
  tools:
    - order_tools.process_refund
  timeout: 600
  message: "This refund requires manager approval."

Every call to order_tools.process_refund pauses the run until a project member approves.

Conditional
agents/order-handler.yaml (snippet)
approval:
  tools:
    - order_tools.cancel_order                          # always gated
    - order_tools.process_refund: param.amount > 1000   # conditional
  timeout: 3600
  message: "This action requires manager approval."
  on_rejection: continue

Small refunds fly through. Larger ones pause for review. With on_rejection: continue, the agent adapts instead.

Reviewer's view

The Approvals page

Pending approvals sit at the top of the Approvals page with full context: agent, tool, parameters, age. Approve or reject in place, or open the run detail drawer for the full picture.

Approvals
4 pending
  • order_tools.process_refundawaiting approval
    on order-manager · order_id=ORD-1234 · amount=129
    2m
  • order_tools.process_refundawaiting approval
    on order-manager · order_id=ORD-1287 · amount=2400
    5m
  • order_tools.cancel_orderawaiting approval
    on order-manager · order_id=ORD-1199 · reason=customer_request
    11m
  • db_deleteawaiting approval
    on support-triage · table=conversations · id=42819
    23m
Audit trail

Every decision, on the record

Approval decisions land in the project audit log next to deploys and config changes. They also show up on the run's trace view, next to the tool calls they gated.

Who decided

Every approval and rejection is recorded with the team member who made the decision and when.

What was called

Tool name and the exact parameters at the moment of decision are captured alongside the action.

On the run trace

Approval events show up on the run's trace view too, with wait duration and reviewer next to the gated tool call.

Keep exploring

Observability

Trace every step, every token.

Judges

Score every run. Catch drift early.

A/B testing

Compare variants in production.

Tools

Predefined, custom Python, or MCP.

Testing

Assertions and judges, in CI.

Environments

Per-env config and secrets.

Frequently Asked Questions

The timeout follows the same path as a rejection. With the default on_rejection: fail the run terminates; with on_rejection: continue the run resumes and the agent is told the tool was not executed. Timeouts are clock-time, not run-time.

By default a rejection ends the run with a FAILED status that includes the reviewer's reason. Set on_rejection: continue and the tool call returns a rejection message to the LLM instead. The agent can then try a different approach, ask the user for input, or skip the action.

Yes. Use a condition expression like 'param.amount > 1000 and not context.is_admin' next to the tool name in the approval block. Conditions read tool parameters via param.<key> and middleware values via context.<key>. If the expression can't be evaluated, the call pauses for review. Fail-safe by design.

All project members get an email and in-app notification by default. Routing is configured in the Notification Config drawer on the Approvals page: pick which members get notified for which agents. An optional webhook URL forwards each request to Slack, Teams, PagerDuty, or your own approval workflow.

Yes. List, approve, and reject approvals via the REST API with API key authentication, alongside the rest of the platform endpoints. Useful when your existing approval workflow lives in another system.

Any project member can approve or reject from the dashboard or API. Project roles (Owner, Admin, Member) govern dashboard access. The approval gate itself isn't restricted to a specific role.