> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pathors.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Pathway Design Guidelines: Per-Turn Routing and Tool Limits

> How many nodes an agent can move through and how many tool steps it can run in a single turn, and how to control when it speaks between nodes

Two limits are worth knowing before you design a pathway. They are not knobs for you to tune — they are the safety net that pulls a conversation back when a flow misbehaves. Understanding them lets you predict how your agent behaves in edge cases.

## The two limits

A "turn" is one round trip: the user says something, the agent replies. Within a single turn:

* **At most 4 node transitions** (moves from one node to another)
* **At most 4 tool steps** (calling several tools at once still counts as one step)

The two limits are **independent**: using up all four node transitions does not consume tool budget, and vice versa. When either limit is reached, the agent **never goes silent** — it always closes the turn with a spoken reply.

| Limit reached    | What the agent does                                                                                              |
| ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| Node transitions | Stays on the current node for the rest of the turn, but can still look things up, call tools, and reply normally |
| Tool steps       | Stops calling tools and answers the user with the information it already has                                     |
| Both             | Stays on the current node and answers with what it has; the next turn starts fresh                               |

Both limits reset every turn — they are not a total for the whole conversation. A long call moving through dozens of nodes is perfectly normal.

## Moving through several nodes in one turn is intentional

The first time you see a turn cross three nodes, it can look like a broken flow. Usually it isn't — it means the **user said a lot in one breath**.

Picture a service-booking flow designed as four nodes: ask for the service → ask for the vehicle → ask for the mileage → confirm everything. If the user opens with:

> "I'd like to book a routine service. It's a 2019 model, around 80,000 kilometres."

All three questions are already answered. The correct behaviour is to **jump straight to the confirmation node**, not to walk the node order and ask "What service would you like?", "Which model?", "What mileage?" all over again. Re-asking what the user just said sounds like the agent wasn't listening — one of the most damaging habits in a voice conversation.

So multi-node turns are a feature, not a defect. The limit exists only to keep them from running away.

## Making the agent speak at every node

If your scenario genuinely needs step-by-step confirmation (reading each detail back so the user can verify it), that is a **prompt-level requirement, not a flow-level one**. How to do it:

* Say so in the node prompt: "Read back the information collected so far and get confirmation before moving on."
* Add a precondition such as "the user has confirmed" to the outgoing edge condition, so moving on without a reply isn't possible.
* Step-by-step confirmation makes calls longer. Add it only to nodes that genuinely need verification, not to the whole pathway.

<Warning>
  Do not put an instruction like "route to the next node without speaking" in your global prompt. That explicitly authorises the agent to chain transitions in complete silence — which the user experiences as an unexplained pause after they finish talking. "Don't speak" and "speak at every step" are opposites, and it is easy to write the wrong one.
</Warning>

## About cyclic pathways

If your pathway contains a cycle (A → B → A), the node transition limit is the last line of defence: the agent won't loop forever, and once the limit is reached it stays put and finishes the turn.

Don't treat that as permission to design cycles loosely. A cycle without a clear exit condition will already have the user listening to the agent go in circles before the limit is reached. Give every loop-back edge an explicit condition (for example, "the information provided is still incomplete") and make sure at least one path always leads out.