A short guide for building agents that process many bookings at once, for example a disruption or crisis assistant that scans your book of business to find every traveler affected by an event.
Recent platform updates make these list-heavy jobs faster and far more reliable. Most of the benefit is automatic. There is one prompt change that unlocks the biggest gain, and this guide walks you through it.
What you get automatically (no changes needed)
These apply to every agent with no action from you:
Leaner data fetches. When an agent pulls a booking, it now retrieves a compact summary by default instead of the full record. Batch jobs process many more bookings before reaching a turn limit.
Stable under load. A single heavy agent can no longer exhaust a worker and affect other users.
Graceful on very long chats. If a conversation grows past the model’s limit, older content is trimmed automatically and, if needed, the agent ends the turn with a clear message instead of a cryptic error. Cut-short turns are marked incomplete so nothing looks silently finished.
The one change that matters: fan-out for big lists
When an agent has to ask the same question across many bookings, the naive approach is to pull each booking into the conversation one after another. That fills up the chat quickly and the agent stalls.
Instead, instruct the agent to use the built-in for_each tool. It runs each booking in its own isolated workspace, so a list of a hundred-plus bookings never clogs the main conversation. Each item comes back as a compact one-line result.
This is opt-in: the agent only uses it if your system prompt tells it to.
Copy-paste prompt block
Paste this into your agent’s system prompt and fill in the two placeholders:
When you need to assess many bookings against the same question, do not pull them into this conversation one at a time. Use the `for_each` tool: - items: the list of booking IDs, one per entry - instruction: what to check for a SINGLE booking, and the one-line verdict to return (for example: "Return: booking ID, lead traveler, affected? yes/no, and the affected flight or service") - tools: ["<YOUR-BOOKING-CONNECTOR>"] so each booking is fetched and evaluated in its own isolated context Process at most 200 booking IDs per call. If there are more, call `for_each` again for the next batch. Then summarize the returned one-line results, listing the affected bookings first.
Replace:
<YOUR-BOOKING-CONNECTOR>with the name of the read connector your agent uses to fetch a booking.The example
instructiontext with the specific check your use case needs.
Worked example: a disruption impact assistant
You are a disruption impact assistant. When the user reports an event (an airport closure, a strike, a supplier failure) affecting a region and date range, identify every affected booking.
First, get the candidate booking IDs for that region and date range. Then, for the assessment, use the for_each tool:
items: the candidate booking IDs
instruction: “Fetch this booking. Decide whether any flight or service falls within the disruption window and location. Return one line: booking ID, lead traveler name, affected (yes/no), and the specific flight or service at risk.”
tools: [“acme-bookings”]
Handle at most 200 IDs per for_each call; batch larger lists. Then present a summary table of affected bookings first, followed by a count of those checked and cleared.
Extra tip for extraction and export agents
If your agent loops over many bookings to build a report or CSV, add this so it goes even faster and never loses completed work:
On every booking fetch, request only the fields you actually extract, never the full record. After each batch, re-write the full output file with all rows completed so far, so a run that stops at a limit still delivers everything done up to that point.
Good practices and limits
Scope the query. Fan-out raises the ceiling; it does not remove it. Narrow big jobs by region, date window, or supplier rather than running the entire portfolio in one turn.
200 items per call. Larger lists are automatically split by instructing the agent to batch, as shown above.
Reads happen in isolation; actions stay with the main agent. Each item can fetch its own data, but any change (updating a record, sending a message) is performed by the main agent, where it stays visible and, if you have approvals enabled, gated for review.
Keep the per-item instruction tight. Ask for a short, structured one-line result. This keeps the summary fast and clean.
Need help adapting this to a specific agent? Your Nezasa contact can tailor the prompt to your connectors and use case.