Why do jobs stop after agent rejection?

In version 1.3 and later, job dispatch stops after the first rejection by default. If you're seeing jobs fail to route after an agent rejects them, this is the expected behavior.

Rejection-based routing (legacy)

If you need to maintain the old behavior where rejected jobs continue to bounce around until finding an accepting agent, you can use:

job_request.reject(terminate=False)

However, this approach incurs significant dispatch latency and is not recommended for production use.

Recommended approach: Explicit agent dispatch

Instead of using rejection as a routing mechanism, the preferred method is to use explicit agent dispatch with named agents.

1. Assign distinct names to your agents

Give each agent deployment a unique name like my-agent-v2 when creating the agent.

2. Configure explicit dispatch

For SIP calls: Use the dispatch rule configuration in your SIP setup:

{
  "dispatch_rule": {
    "rule": {
      "dispatchRuleIndividual": {
        "roomPrefix": "call-"
      }
    },
    "name": "My dispatch rule",
    "roomConfig": {
      "agents": [{
        "agentName": "inbound-agent",
        "metadata": "job dispatch metadata"
      }]
    }
  }
}

For non-SIP applications: Set the agents field when calling CreateRoom, or use the CreateDispatch method to add an agent to an existing room.

Important notes about named agents

• When you set an agent's name, automatic dispatch is disabled for that agent
• Named agents must be explicitly dispatched to rooms through configuration
• Agents without names automatically receive jobs from the "default" dispatch
• If multiple agents share the same name, the system will load balance between them

Related resources

For more details on agent dispatch strategies, see the agent dispatch documentation.