The agent's work cycle

Copy the link to the article

Copied

Contents

1. Runs and iterations
2. The order of a single run
3. The agent can only access the steps allowed right now
4. Work dashboard
5. Steps triggered by events
6. When the agent stops
7. When the system continues the work for the agent
8. Limit on the length of a run

The previous section described how chat events start the agent. Here we cover what happens after the start: how the agent does useful work within a single work session, why it can perform several actions in a row, how it knows which steps are available to it right now, and when it stops.

Understanding this helps you configure scenarios deliberately: it becomes clear why the agent does not see some steps, why one step "leads" to another within a single reply, and why the agent sometimes continues working when it seems it should have stopped.

Runs and iterations

A run is a single session of the agent's work, started by a chat event (most often a message from the client or the assignment of a dialog). Within a run, the agent works in iterations, that is, in turns.

On each turn, the agent does not perform the actions itself but returns a plan to the system: which scenario steps to call and with what data. The system validates this plan, executes the steps together with their actions, and shows the agent the result. After that, the agent decides whether another turn is needed.

This is why a single run can be multi-turn. For example, in response to a single message from the client, the agent can, over several iterations in a row: find the client's order, check the address in it, and then ask a clarifying question. All of this is one run, but several turns.

The fact that the agent only returns a plan, while the system executes it, is an important principle of security and role separation. The set of actions in each step, the data to be collected, and the rules for applying them are defined in advance by the system user: they design the scenario and determine what will be done and how. The agent has no direct access to the actions — it only brings data from the conversation and selects suitable steps from the allowed ones. The actual execution and checks remain with the system. This keeps the agent's behaviour within the bounds the user set in advance.

The order of a single run

Each run goes through several stages:

1. Signal check. Before the agent begins its main work, the system runs the conversation analysis against the configured signals once. If the signal values match the conditions, a step linked to the signal may start — even before the agent's usual reply. This is why signals take priority over ordinary planning.
2. Planning. The agent looks at the available steps and the current state of work and forms a plan: which steps to call.
3. Execution. The system executes the selected steps and the actions within them.
4. Continuation or completion. The system decides whether another turn is needed or the work for this run is finished.

These stages repeat until the agent stops or the system stops it.

The agent can only access the steps allowed right now

This is one of the key ideas of the whole system. The agent does not see the entire scenario at once. Before each request to the agent, the system assembles the current set of steps available at exactly this moment, and the agent can choose only from them.

The available set includes:

• the agent's core capabilities (for example, sending a message to the client);
• steps visible from the very start of the dialog;
• steps opened by transitions from previously executed steps;
• steps allowed by the current conditions.

If a step is hidden or its conditions are not currently met, the agent simply cannot choose it — for the agent, that step does not exist at this moment. This is the main tool for controlling behaviour: step visibility settings (show from the start, hide after completion) and conditions determine which capabilities are available to the agent at each stage. For more details, see the Scenario steps and Conditions sections.

Thanks to this, the scenario becomes predictable: instead of listing all the possible "if…, then…" rules in the instructions, you restrict the agent's choice in advance at each step.

Work dashboard

So that the agent makes decisions based on the current context, before each turn the system shows it the work dashboard — a brief summary of the current state: active scenario tasks, missing data, signal values, temporary instructions, and planned transitions.

The dashboard updates on each iteration and strongly influences the agent's actions. It is from the dashboard that the agent understands what has already been done, what is missing, and what to do next. The composition of the dashboard is described in detail in the Instructions section.

Steps triggered by events

Not every turn requires the agent's involvement. Besides ordinary steps that the agent chooses itself, there are steps triggered by events — for example, on the closing of a dialog, a message from the manager, or a reaction to a signal. The system executes these itself, without starting the agent: such a step does its job (assign tags, save data, schedule a delayed action) and finishes.

There is an important difference here between the two kinds of steps. A step that the agent works with can, after running, by default hand work back to the agent. A step triggered by an event does not do this — by itself it does not wake the agent. For the agent to engage on an event, you need to add the "Call AI agent" action inside such a step, or "Go to another step" to a step managed by the agent. For more details, see the Chat events section.

When the agent stops

A run ends in one of two ways.

The agent stops itself. It reports that the work is finished for this turn: either it replied to the client and is waiting for their reaction, or the task is fully completed and no reply from the client is expected. This is the normal way to end a run.

The system stops the agent by the scenario rules. For example, a step may contain the "Stop AI agent" action, or a scenario branch ended by handing the dialog over to a manager. In this case the agent does not work any further, even if it "would like" to continue.

When the system continues the work for the agent

Sometimes the agent reports that it has stopped, but the system understands that the work is not actually finished and gives it another turn. This happens so that the agent does not "fall asleep" with an unfinished task. Typical cases:

• the agent called a step but did not collect all the required data — the system returns it so that it requests the missing data from the client;
• the executed step opened a transition to the next step — the agent must see the new task and continue with the scenario;
• the step did not run for a fixable reason and is worth retrying.

In all these cases, the system overrides the stop and forces the agent to make one more iteration. This makes the behaviour more reliable: the scenario is brought to its logical conclusion instead of breaking off halfway.

Limit on the length of a run

To keep the agent from looping, a single run has a reasonable limit on the number of iterations. If the work hits this limit, the run ends. In practice it is rarely reached: the agent usually fits within a few turns. But if a scenario is built so that steps endlessly hand control to one another, the limit protects the system from looping — and it is a sign that the scenario logic should be simplified.