Human-in-the-Loop

Human-in-the-loop (HITL) workflows allow you to maintain control over critical agent actions by requiring human approval before executing certain tools. This is essential for operations that could have significant consequences, such as database modifications, financial transactions, or external API calls with cost implications.

Overview

When a tool is marked as requiring approval, the agent will pause execution and wait for human approval or denial before proceeding. This creates a checkpoint in the agent’s workflow where human judgment can be applied. The approval workflow is designed to be non-blocking and supports both synchronous and streaming message interfaces, making it suitable for interactive applications as well as batch processing systems.

Key Benefits

• Risk Mitigation: Prevent unintended actions in production environments
• Cost Control: Review expensive operations before execution
• Compliance: Ensure human oversight for regulated operations
• Quality Assurance: Validate agent decisions before critical actions

How It Works

The approval workflow follows a clear sequence of steps that ensures human oversight at critical decision points:

1. Tool Configuration: Mark specific tools as requiring approval either globally (default for all agents) or per-agent
2. Execution Pause: When the agent attempts to call a protected tool, it immediately pauses and returns an approval request message
3. Human Review: The approval request includes the tool name, arguments, and context, allowing you to make an informed decision
4. Approval/Denial: Send an approval response to either execute the tool or provide feedback for the agent to adjust its approach
5. Continuation: The agent receives the tool result (on approval) or an error message (on denial) and continues processing

Best Practices

Following these best practices will help you implement effective human-in-the-loop workflows while maintaining a good user experience and system performance.

1. Selective Tool Marking

Not every tool needs human approval. Be strategic about which tools require oversight to avoid workflow bottlenecks while maintaining necessary controls:

Tools that typically require approval:

• Database write operations (INSERT, UPDATE, DELETE)
• External API calls with financial implications
• File system modifications or deletions
• Communication tools (email, SMS, notifications)
• System configuration changes
• Third-party service integrations with rate limits

2. Clear Denial Reasons

When denying a request, your feedback directly influences how the agent adjusts its approach. Provide specific, actionable guidance rather than vague rejections:

1
# Good: Specific and actionable
2
"reason": "Use read-only query first to verify the data before deletion"
3
4
# Bad: Too vague
5
"reason": "Don't do that"

The agent will use your denial reason to reformulate its approach, so the more specific you are, the better the agent can adapt.

Setting Up Approval Requirements

There are two methods for configuring tool approval requirements, each suited for different use cases. Choose the approach that best fits your security model and operational needs.

Method 1: Create/Upsert Tool with Default Approval Requirement

Set approval requirements at the tool level when creating or upserting a tool. This approach ensures consistent security policies across all agents that use the tool. The default_requires_approval flag will be applied to all future agent-tool attachments:

1
curl --request POST \
2
  --url http://localhost:8283/v1/tools \
3
  --header 'Content-Type: application/json' \
4
  --data '{
5
    "name": "sensitive_operation",
6
    "default_requires_approval": true,
7
    "json_schema": {
8
      "type": "function",
9
      "function": {
10
        "name": "sensitive_operation",
11
        "parameters": {...}
12
      }
13
    },
14
    "source_code": "def sensitive_operation(...): ..."
15
  }'
16
17
# All agents using this tool will require approval
18
curl --request POST \
19
  --url http://localhost:8283/v1/agents \
20
  --header 'Content-Type: application/json' \
21
  --data '{
22
   "tools": ["sensitive_operation"],
23
   // ... other configuration
24
  }'

Method 2: Modify Existing Tool with Default Approval Requirement

For an already existing tool, you can modify the tool to set approval requirements on future agent-tool attachments. The default_requires_approval flag will be applied to all future agent-tool attachments:

1
curl --request PATCH \
2
  --url http://localhost:8283/v1/tools/$TOOL_ID \
3
  --header 'Content-Type: application/json' \
4
  --data '{
5
    "default_requires_approval": true
6
  }'
7
8
# All agents using this tool will require approval
9
curl --request POST \
10
  --url http://localhost:8283/v1/agents \
11
  --header 'Content-Type: application/json' \
12
  --data '{
13
   "tools": ["sensitive_operation"],
14
   // ... other configuration
15
  }'

Method 3: Per-Agent Tool Approval

Configure approval requirements for specific agent-tool combinations, allowing fine-grained control over individual agent behaviors. This method is particularly useful for:

• Trusted agents: Remove approval requirements for well-tested, reliable agents
• Progressive autonomy: Gradually reduce approval requirements as agents prove reliable
• Override defaults: Change the approval setting for tools already attached to an agent

Use the following endpoints to modify approval settings for existing agent-tool relationships:

1
curl --request PATCH \
2
  --url http://localhost:8283/v1/agents/$AGENT_ID/tools/$TOOL_NAME/approval \
3
  --header 'Content-Type: application/json' \
4
  --data '{
5
    "requires_approval": true
6
  }'

Handling Approval Requests

Step 1: Agent Requests Approval

When the agent attempts to call a tool that requires approval, execution immediately pauses. The agent returns a special approval request message containing:

• Tool name: The specific tool being called
• Arguments: The exact parameters the agent intends to pass
• Tool call ID: A unique identifier for tracking this specific call
• Message ID: The approval request ID needed for your response
• Stop reason: Set to "requires_approval" to indicate the pause state

This format matches the ToolCallMessage format intentionally, so that we can handle approval requests the same way we handle tool calls. Here’s what an approval request looks like in practice:

1
curl --request POST \
2
  --url http://localhost:8283/v1/agents/$AGENT_ID/messages \
3
  --header 'Content-Type: application/json' \
4
  --data '{
5
    "messages": [{
6
      "role": "user",
7
      "content": "Delete all test data from the database"
8
    }]
9
  }'
10
11
# Response includes approval request
12
{
13
  "messages": [
14
    {
15
      "message_type": "reasoning_message",
16
      "reasoning": "I need to delete test data from the database..."
17
    },
18
    {
19
      "message_type": "approval_request_message",
20
      "id": "message-abc123",
21
      "tool_call": {
22
        "name": "database_write",
23
        "arguments": "{\"query\": \"DELETE FROM test_data\"}",
24
        "tool_call_id": "tool-xyz789"
25
      }
26
    }
27
  ],
28
  "stop_reason": "requires_approval"
29
}

Step 2: Review and Respond

Once you receive an approval request, you have two options: approve the tool execution or deny it with guidance. The agent will remain paused until it receives your response.

Approving the Request

To approve a tool call, send an approval message with approve: true and the approval request ID. The agent will immediately execute the tool and continue processing:

1
curl --request POST \
2
  --url http://localhost:8283/v1/agents/$AGENT_ID/messages \
3
  --header 'Content-Type: application/json' \
4
  --data '{
5
    "messages": [{
6
      "type": "approval",
7
      "approve": true,
8
      "approval_request_id": "message-abc123"
9
    }]
10
  }'
11
12
# Response continues with tool execution
13
{
14
  "messages": [
15
    {
16
      "message_type": "tool_return_message",
17
      "status": "success",
18
      "tool_return": "Deleted 1,234 test records"
19
    },
20
    {
21
      "message_type": "reasoning_message",
22
      "reasoning": "I was able to delete the test data. Let me inform the user."
23
    },
24
    {
25
      "message_type": "assistant_message",
26
      "content": "I've successfully deleted 1,234 test records from the database."
27
    }
28
  ],
29
  "stop_reason": "end_turn"
30
}

Denying with Guidance

When denying a tool call, you can provide a reason that helps the agent understand how to adjust its approach. The agent will receive an error response and can use your feedback to reformulate its strategy. This is particularly useful for guiding the agent toward safer or more appropriate actions:

1
curl --request POST \
2
  --url http://localhost:8283/v1/agents/$AGENT_ID/messages \
3
  --header 'Content-Type: application/json' \
4
  --data '{
5
    "messages": [{
6
      "type": "approval",
7
      "approve": false,
8
      "approval_request_id": "message-abc123",
9
      "reason": "Only delete records older than 30 days, not all test data"
10
    }]
11
  }'
12
13
# Response shows agent adjusting based on feedback
14
{
15
  "messages": [
16
    {
17
      "message_type": "tool_return_message",
18
      "status": "error",
19
      "tool_return": "Error: request denied. Reason: Only delete records older than 30 days, not all test data"
20
    },
21
    {
22
      "message_type": "reasoning_message",
23
      "reasoning": "I need to modify my query to only delete old records..."
24
    },
25
    {
26
      "message_type": "tool_call_message",
27
      "tool_call": {
28
        "name": "database_write",
29
        "arguments": "{\"query\": \"DELETE FROM test_data WHERE created_at < NOW() - INTERVAL 30 DAY\"}"
30
      }
31
    }
32
  ],
33
  "stop_reason": "requires_approval"
34
}

Streaming + Background Mode

For streaming clients using background mode, approvals are best handled via agents.messages.createStream(..., background: true). The approval response may include the tool_return_message on the approval stream itself, and follow‑up reasoning/assistant messages can be read by resuming that stream’s run_id.

1
# Approve in background after receiving approval_request_message
2
curl --request POST   --url http://localhost:8283/v1/agents/$AGENT_ID/messages/stream   --header 'Content-Type: application/json'   --data '{
3
  "messages": [{"type": "approval", "approve": true, "approval_request_id": "message-abc"}],
4
  "stream_tokens": true,
5
  "background": true
6
}'
7
8
# Example approval stream output (tool result arrives here):
9
data: {"run_id":"run-new","seq_id":0,"message_type":"tool_return_message","status":"success","tool_return":"..."}
10
11
# Continue by resuming the approval stream's run
12
curl --request GET   --url http://localhost:8283/v1/runs/$RUN_ID/stream   --header 'Accept: text/event-stream'   --data '{
13
  "starting_after": 0
14
}'

See background mode for resumption patterns.

IDs and UI Triggers

• approval_request_id: Always send approvals/denials using the approval_request_message.id.
• tool_call_id: Informational only; not accepted for approval/denial.
• UI trigger: Open the approval UI on approval_request_message only; do not drive UI from stop_reason.