> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hubtalk.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Working in the editor
> Document search, agent variables, error checking and testing the flow.
# Working in the editor
The agent editor is a canvas holding the flow, a palette of nodes on the left and an inspector for the selected node on the right. This page covers what helps you **build and check** a flow: document search, variables, the issues tab and testing. What each node does is on [Flow nodes](/v4/platform/agents/nodes).
## Searching the agent document
The **π Find** button is **the first one in the editor toolbar's second row**, to the left of **β Organize**; its tooltip reads "Find in document". It opens a floating search panel above the canvas. **Cmd/Ctrl + F** does the same. The component editor has the same button in its own header.
The search covers node names, prompts, transition conditions, authored node fields and pipeline functions. Dictionaries, output variables and internal identifiers are deliberately left out of the index: a fragment of JSON in the results is unreadable and could expose a secret.
The unit of navigation is a match, not a node: three matches in one node mean three steps. Enter goes to the next, Shift+Enter to the previous, Esc closes; the counter runs across the **Dialog** and **Pipeline** views, and crossing that boundary switches the view for you. The cap is 500 matches, beyond which the panel says plainly that it is showing the first ones.
**Cmd/Ctrl + F yields to input fields.** If the cursor sits in a prompt, in any text field or in the code editor, the shortcut goes to that field β you get the browser's own find rather than the panel. This is deliberate: inside a long prompt the author expects a search of that prompt. Click the canvas to drop the focus, or use the toolbar button.
The browser's find cannot replace this: it only sees the short previews on the cards and cannot pan the canvas to what it found.
## Agent variables
An agent can hold variables that carry data from one node to another. Open the **Variables** tab, add a variable and give it a name, a type and a description.
Variables keep what the conversation produced and what the agent's actions returned. They can be used:
* in node instructions and prompts, for example `{{customer_name}}`
* in **Function** and **MCP Tool** parameters
* in the output of **Code** and **Extract Variables**
* in **Logic Split** transition conditions
* in **Conversation** and **End** messages
* in webhook notifications and post-call analytics
Use clear, unique names and add a description so the agent understands what the variable is for. A value can appear only after the caller answers, after data is extracted or after an external action runs β so check that the node producing it runs before the node that reads it.
### Variables every call starts with
Ten variables are seeded at the start of every call, before the agent's first word, so a prompt, a transition condition or a **Function** parameter can use them straight away. The condition builder and the substitution hints offer them like any other variable.
| Variable | Value |
| ----------------- | -------------------------------------------------------------------------------------------------- |
| `{{direction}}` | `inbound`, `outbound`, or `web` for a call placed through the Web SDK |
| `{{from_number}}` | the caller's number for an inbound call; the caller ID the platform dials from for an outbound one |
| `{{to_number}}` | the number that was dialed for an inbound call; the destination for an outbound one |
Numbers arrive as digits only, with no `+` and no separators β format them in a **Code** node before the agent reads one back to the caller. What the call itself knows overrides the default set on the Variables tab; values passed by a campaign, by the Web API, or mapped from a SIP header are applied after that and win over both. The chat tester has no call behind it, so there these three keep whatever the Variables tab holds.
#### The date and time of the call
Seven more variables carry the date and time of the conversation itself. The platform computes them β they do not belong in the contact file.
| Variable | Value | Example |
| ------------------- | -------------------------------------------------------------- | ------------- |
| `{{call_date}}` | the date, ISO | `2026-09-24` |
| `{{call_date_us}}` | the date, US form | `09/24/2026` |
| `{{call_time}}` | the time, 24-hour | `14:05` |
| `{{call_time_us}}` | the time, 12-hour | `2:05 PM` |
| `{{call_weekday}}` | the day of the week, in English | `Thursday` |
| `{{call_timezone}}` | the zone everything was computed in | `Asia/Almaty` |
| `{{today}}` | `call_date_us` on the US market profile, `call_date` otherwise | `2026-09-24` |
**Which zone the date is computed in.** The platform takes the first that applies: the contact's own day, when the campaign dials in the contact's local time; otherwise the zone chosen for display; otherwise the organization's zone; otherwise UTC. A zone that cannot be resolved falls back to UTC β and `{{call_timezone}}` says `UTC`, so the miss is visible in the call history.
**Do not carry the date as a file column.** A value from the file freezes at upload, so on a redial the agent names the day the file was uploaded rather than today. These seven are recomputed on every call, redials included.
## Error checking
The **Issues** tab lists the errors and warnings found in the agent's settings and flow. Press **Re-check** to run the check again after making changes. When nothing is wrong, the tab shows **No issues found**.
Errors block publication, warnings do not. The check looks at more than the graph: on publication, on a campaign launch and when a demo link is created, the platform also builds the same speech recognition and synthesis objects a real call would, and reports a broken provider setup, a missing knowledge base or audio file, and an unpublished transfer destination before the agent goes to work.
## Test before launch
Use the built-in testing tools to make sure your agent behaves as expected:
* run sample dialogues in the chat tester
* make a live voice call in the telephony test panel
* verify that the agent follows the intended path
* update the prompt and actions if the flow feels wrong
### Starting a test from a selected node
Select a node on the canvas and the test panel gains a **βΆ From node \** button. The session starts at that node directly, without walking the path from **Begin**; **βΊ Restart** replays the same node. It works in both the chat tester and the voice test, and the session record marks the start from a node as its own event. With nothing selected, and on the **Begin** node, the button is not shown.
**Variables along the path are not filled in.** The session only gets the flow's default values, so a node reading a variable set by an earlier step will see an empty value. There is no synthetic conversation history either β the transcript starts at the selected node.
Only the test entry points accept a start node: neither the [Web API](/v4/web-api), nor telephony, nor a handoff to another agent knows the field. You cannot start inside a published component β in a draft, a component node resolves to its own entry point.
## When the caller stops mid-sentence
Real callers pause. "Yesβ¦" *(pause)* "β¦no, I don't want to" is one reply, but the platform hears the end of a turn in the middle of it. Two behaviours protect the flow from that.
**A transition that was never spoken can be taken back.** If a turn is cut off before the agent makes a sound and the caller then continues with something meaningful, the platform treats the transition as not having happened: the fragments are joined and the whole reply is classified from the node it started in, so "yesβ¦ no, I don't want to" does not get classified from inside the **Agreement** branch. The decision is made on what actually happened next β if the agent already began speaking, the transition stands; if the continuation was noise or empty, the current node's reply is played again. A turn that made an outbound call to your systems always stands, because that call cannot be taken back. At most four fragments are joined; anything beyond that is handled the ordinary way.
**A node that speaks and immediately leaves will not leave silently.** A node whose job is to say one line and move on β "Connecting you now" before a transfer, for example β executes on arrival and only then follows its single outgoing edge, so it cannot be skipped in the gap between arriving at the node and the line being spoken. A phrase also counts as spoken only after it is written to the conversation history, so a cancelled turn cannot pass an unplayed line off as delivered.