​

Conversation goals

Conversation goals are a list of what has to be established during the call. The platform marks them off itself and keeps reminding the agent what is already confirmed, so the agent stops re-asking for what it already has. The reminder does not live in the message history but in the service part of the instruction and is refreshed on every turn, so it never falls out of memory — not even on a long call. The platform marks a goal, not the model. The decision comes from a checkable condition rather than a judgement call: the field value is visible in the call record and can be verified. The mechanism makes no extra language-model calls — it affects neither call latency nor cost. The summary is mixed into the instruction automatically and never appears in the conversation transcript.

• Track conversation goals — the master switch. While it is off, or the goal list is empty, the mechanism is fully disabled.

Each goal is added with Add goal:

​

Conditions and where values come from

A condition is an expression over call fields: {{full_name}} exists, {{consent}} == "yes", {{amount}} > 1000, {{intent}} CONTAINS payment, {{crm_check_success}} == true, with AND and OR. Comparisons are case-insensitive. Expressions with brackets or a mix of AND and OR are edited as text only. The “the agent reached this step” check is added as a Node visited card — the node is picked from a list. Field values come from three sources: extraction from the conversation, results of calls to your systems (every configured request automatically exposes {{name}}_success, {{name}}_status, {{name}}_error plus the fields you mapped from the response), and data known before the call — call and campaign variables.

​

Preconditions instead of order

Goals cannot be ordered, by design: a real person does not answer down a list, and a mechanism demanding a strict sequence would fight that. Preconditions take the place of order. Two consequences:

• An answer given early is not lost: the value is kept, and the goal closes the moment its precondition is met.
• An unavailable goal is not shown to the agent at all — neither among confirmed facts nor in what remains, otherwise the agent would raise a blocked topic too early.

​

Revising a fact

When “Value may be revised” is on and a cancellation condition is set, then once that condition becomes true the goal stops being closed, goals that depended on it become unavailable again, the “all goals closed” flag goes out, and a Goal reopened event appears in the history with its reason. Nothing has to be cleared by hand: the state is recomputed every turn, and if the fact is confirmed again the goal closes again. The choice is mandatory in both directions: without revision a cancellation condition is forbidden — so that no placeholder conditions appear that look like a safeguard but guard nothing.

​

The “all required goals closed” flag

Once every goal marked required is closed, the platform raises a flag. Optional goals do not hold it back. The call does not end automatically — a conversation rarely ends on the last checkbox, and an automatic hang-up would produce calls cut off mid-sentence. What to do with the flag is up to your flow: put the goals_completed() formula condition on the transition you need and route it to a farewell block, a handover to an operator, or a final confirmation. The “all goals closed” flag and the call success evaluation are different things: they are computed independently and both are visible in the record. The first means “everything planned was established”, the second “the call succeeded by your criterion”.

​

What is visible in the call history

The conversation timeline gains Goal closed events (showing which utterance closed it), Goal reopened (with the reason: the cancellation condition fired, the completion condition stopped being true, or a precondition was revoked), and Goal condition error. Besides the events, the record keeps the final picture: which goals closed and on which utterance, which stayed open, which were reopened and why, and whether the “everything established” flag was set. There is no aggregate screen or per-period goal statistics yet; the data has been recorded from day one and will be available for past periods once the screen exists.

​

Errors

The draft accepts any structurally sound document, so an unfinished goal will be saved — but it blocks publishing the agent and making a test call. The blocking causes: an empty name, identifier, completion condition, or statement; a condition that is malformed and cannot be evaluated; two identical identifiers; a precondition pointing at a non-existent goal or at itself; preconditions forming a cycle (A requires B, B requires A); the “may be revised” checkbox disagreeing with the cancellation condition; goals_completed() used inside a goal’s own condition, which would make the goal depend on its own result. In every case you see the cause and the name of the goal it belongs to. If a condition breaks during a call — a field was renamed, say — the call is not interrupted: the goal counts as not closed, a “Goal condition error” warning is written to the timeline once, and the conversation continues normally.

​

Limitations

• Does not work with speech-to-speech (realtime) agents: they do not fill fields as the conversation goes, and without fields there is nothing to check. The checkbox can be turned on, but it will have no effect.
• Does not replace mandatory disclosures. A call-recording notice, identification before discussing a debt, and similar requirements are not goals: a goal hints to the agent, and a hint can be ignored. Where something must be said, the flow needs a hard route; goals may reflect the state of a disclosure but do not guarantee it.
• Does not impose conversation order and does not end the call itself.
• In a rigid flow a field is only filled once the conversation reaches a step with extraction or a call to your system: a goal on a field the flow never fills will not close. Free-mode agents have no such limitation.
• Goals are configured on the agent and versioned with it (draft and published version).