Ask Joget AI

Runtime & Reliability Settings

A group of agent-wide settings that control how the agent behaves at runtime: how its responses appear, how it copes with slow or failing model calls, how it stays within a model's context limit, and how it runs tools. You find them all in one place, alongside the core agent properties.

Where to find these
Open your agent in the AI Agent Builder, go to Settings, and scroll past the AI Agent Properties section. Every setting on this page lives in that same panel and applies to the whole agent, not to a single task.

What it does

These settings tune the agent's behaviour for real-world conditions: a model that streams its answer token by token, an API that occasionally times out or rate-limits, a long conversation that risks overflowing the context window, and tasks that call several tools at once. The defaults are sensible for most agents, so you only change them when you have a specific reason.

When to use it

Reach for these settings when you move an agent from a quick prototype toward something people rely on:

Going to production: Tighten timeouts and retries so a flaky model call does not hang or fail a run.
Long conversations: Keep multi-turn agents within the model's context limit without manual trimming.
Better responsiveness: Stream tokens to the user and run independent tools in parallel.

Token streaming

By default, an agent waits for the model to finish, then shows the whole reply at once. With token streaming, the reply appears word by word as the model produces it, which makes the agent feel far more responsive on longer answers. Streaming works in both the Preview screen and the live runtime UI.

Setting	What it controls	Default
Enable Token Streaming	Streams the model's response tokens to the interface in real time instead of waiting for the complete reply.	Off

How it behaves:

All tokens for one model reply land in a single message bubble, including any follow-up text after a tool call.
Streaming needs the agent to run in SSE streaming mode. The Preview screen and the standard agent UI both use it, so you normally do not configure anything beyond the toggle.
If a run is not in streaming mode, the agent falls back to a single complete response automatically, so turning the toggle on never breaks a run.

Parallel tool execution

When a model decides to call several tools in one response, the agent runs them one after another by default. If those tools are independent say, three separate lookups running them at the same time can noticeably cut the wait. Parallel tool execution does exactly that, using a small thread pool.

Setting	What it controls	Default
Enable Parallel Tool Calls	Runs multiple tool calls from a single model response at the same time instead of one by one.	Off
Parallel Tool Call Threads	How many tools may run concurrently. Only applies when parallel calls are enabled.	4

When it kicks in (and when it does not):

Parallelism only applies when the model returns more than one tool call in the same response. A single tool call always runs on its own.
The thread count is automatically capped at the number of tools in the batch, so you never spin up idle threads.
Some tools always run sequentially even with this enabled: the User Input tool (it pauses the run to wait for a person) and the Group tool. If a batch contains one of these, the whole batch runs in order.
Results are always returned in the model's original order, so parallel execution never changes the outcome, only the timing.

Use it for independent work only
Parallel execution suits tools that do not depend on each other's results, such as several read-only lookups. If a tool writes data that another tool in the same batch reads, run them sequentially (leave this off) to keep the order predictable.

Tool call depth limit

A tool can return a result that prompts the model to call another tool, which calls another, and so on. Usually this is exactly what you want. But a misconfigured tool can trigger itself in a loop that never ends. The tool call depth limit caps how many of these recursive rounds a single task may run before the agent steps in.

Setting	What it controls	Default
Max Tool Call Depth	The maximum number of recursive tool-call rounds within one task.	100

What happens at the limit
When a task reaches the limit, the agent does not crash. It skips any remaining tool calls, notes that the depth limit was reached, and makes one final model call without tools to produce a plain-text answer. The run continues normally from there.

Not the same as Max Iterations
Max Tool Call Depth limits recursive tool calls inside a single task. Max Iterations (a separate setting, default 50) limits how many tasks a whole run may execute, guarding against runaway jumps between tasks. They protect against different kinds of loops.

LLM timeouts

A model call goes out over the network, and networks stall. Without a timeout, a single slow or hung call can tie up a thread indefinitely. These two settings bound how long the agent waits, so a stuck call fails cleanly instead of hanging.

Setting	What it controls	Default
LLM Socket Timeout (seconds)	How long to wait for data once the connection is open. Guards against a model API that accepts the request then goes quiet.	120
LLM Connect Timeout (seconds)	How long to wait to establish the network connection to the model API in the first place.	30

Tuning the socket timeout
The socket timeout is the one you are most likely to raise. Large prompts, long outputs, or extended-thinking models can legitimately take a while to respond, so a too-short socket timeout will cut off slow-but-healthy calls. If you see timeouts on big requests, increase this value rather than the connect timeout.

LLM retries

Model APIs occasionally return a rate-limit error or a temporary server error. Rather than failing the run, the agent can wait briefly and try again, increasing the wait after each attempt so it backs off politely under load.

Setting	What it controls	Default
LLM Retry Max Attempts	Total attempts per model call, including the first. Set to `1` to disable retries.	3
LLM Retry Initial Delay (ms)	How long to wait before the first retry. The wait doubles with each further attempt (exponential backoff).	1000
LLM Retry Max Delay (ms)	The ceiling on any single retry wait, no matter how many attempts have passed.	30000

When a retry happens

Retries trigger on HTTP 429 (rate limit) and 5xx server errors, failures likely to clear on their own. A permanent error, such as a bad API key, fails immediately without retrying.
The wait grows as initial delay × 2 each attempt (for example 1s, 2s, 4s), capped at the max delay, with a small random jitter so many agents do not all retry at the same instant.
To turn retries off entirely, set LLM Retry Max Attempts to 1.

Context window management

Every model has a limit on how much text it can read in a single call. A long conversation, large file or list input, or a chain of tool calls can push past that limit and make the call fail. Context window management trims older messages automatically before each call so the agent stays within the limit.

It is on by default and works invisibly: it only removes messages when the conversation grows too large, and it always keeps the parts that matter most.

Setting	What it controls	Default
Enable Context Window Management	Master switch for automatic trimming before each model call.	On
Trimming Strategy	How messages are removed once a limit is reached. Truncate drops the oldest removable messages one at a time. Sliding Window keeps only the most recent messages (set Max Messages).	Truncate
Max Characters	Total character budget across all messages before trimming starts. Roughly 4 characters ≈ 1 token. `0` turns this check off.	400000 (≈100K tokens)
Max Messages	Maximum number of non-system messages to keep. Required for the Sliding Window strategy. `0` turns this check off.	0 (off)
Preserve System Messages	Always keep system messages, such as the agent's persona and instructions.	On
Preserve First User Message	Always keep the original task description so the agent stays on topic.	On
Warn Threshold (%)	Logs a warning when the conversation reaches this percentage of Max Characters, before trimming begins. `0` turns the warning off.	80

What it never drops

System messages and the first user message are preserved by default, so the agent never loses its instructions or its goal.
Tool calls and their results are kept together. When trimming removes a message that is part of a tool call, its paired result is removed too, so the conversation sent to the model is never left half-finished.
Trimming uses a character count as a stand-in for tokens (about 4 characters per token). It is a safety net, not an exact token meter.

Sliding Window needs Max Messages
The Sliding Window strategy only has an effect when Max Messages is greater than 0 . Leave it at the default 0 and Sliding Window has nothing to trim by, so set a message budget when you choose that strategy.

Created by Debanraj Ravindran Last modified by Debanraj Ravindran on Oct 11, 2026

Runtime & Reliability Settings

Summary

Prerequisites & Step-by-Step