> ## Documentation Index > Fetch the complete documentation index at: https://docs.signalmd.dev/llms.txt > Use this file to discover all available pages before exploring further. # Versions > How Signal picks up a new version of your agent, what it compares, and how to read the verdicts it gives. Every time you publish a change to your agent in Retell, a new version goes live. Signal records what changed and compares production calls on the new version with calls on the version before. It calls a change better or worse only when the difference is real, and says so when there are not enough calls yet. ## When Signal picks up a new version Signal picks up a new version within about 10 minutes of publishing, or at once when you publish from the copilot's **Build** page. It then captures the new version's configuration, records what changed since the last captured version, updates your board, and starts a run of your release tests if testing is set up (see [Test a fix](/guides/test-a-fix)). A change records steps, prompts, transitions and tools added, removed or rewritten, a new model, and changed agent settings such as voice, responsiveness and interruption sensitivity. Versions that went live before you connected still appear, because every call carries its version, but Retell serves only the live configuration, so what changed in them is unknown. New calls arrive on their own (see [Connect Retell](/guides/connect-retell#how-signal-gets-data-from-retell)), so a comparison grows as calls arrive on the new version. ## Where to find it On **Agent config**, **History** lists every version with its **First call**, **Calls** and **Got it done**, plus **Handed to a person** when any call ended in a transfer. A version whose configuration was never captured is marked "no config". Below it, each change such as **v7 → v8** shows what **Changed** in the configuration next to its **Effect** on production, with a conclusion tag and a written summary. A change whose configuration was not captured on one side is tagged **Calls only**. Each version is also a marker on the overview board's charts, at its first call. Hover it for the configuration changes and a before-and-after reading of that chart's metric. ## What is compared The **Effect** table uses the overview board's own definitions, so the two never disagree: | Metric | What it counts | Better when | | - | - | - | | **Got it done** | Calls where the caller got what they came for | Higher | | **Calls with a bad outcome** | Calls with at least one bad outcome for the caller or the company | Lower | | **Hung up mid-task** | Calls where the caller left while something was still under way | Lower | | **Handed to a person** | Calls the platform ended in a transfer | Shown, never judged | | **Calls with a failed tool** | Calls where a tool ran and at least one failed or timed out. A tool that ends the call is not a failure | Lower | | **Reply time** | How long the caller waited for the agent to start replying | Lower | **Got it done** is the headline and the others are guardrails, so a change that raises Got it done while breaking something else does not read as a clean win. Got it done and the outcome rows count calls where the caller spoke and the call has been read; **Calls with a failed tool** counts calls where a tool ran. Hover a cell to see its number of calls. **Handed to a person** is never coloured and never counts for or against a version, because for many agents reaching a person is the designed result. A row with nothing on either side is left out. Rows Signal has not finished reading on these calls are left out too, and named under the table after "Not shown". Below the metrics, **Issues that moved** lists up to 5 issues whose share of calls changed by a real amount between the two versions. They count towards the conclusion like the guardrails. ## Verdicts you can see Each row gets a verdict, and the change as a whole gets a conclusion tag. A movement counts only when Signal finds it real and large enough to act on, so a small wobble on a busy agent, or a large swing on a handful of calls, does not read as a result. ### On a single metric | Verdict | Means | | - | - | | A signed difference, such as **+10.0 points** | A real change large enough to act on. Green or red only when the metric has a better direction | | **Too small to matter** | A real movement, but too small to act on. Treat it as unchanged | | **Within noise** | The difference could be chance. Treat it as unchanged | | **Not enough calls** | One side has too few calls to judge yet. **No earlier calls** when the earlier version has none | | **Not comparable** | The two sides were read by different versions of Signal's analysis, so part of any gap could come from Signal rather than your agent. Only rows built from Signal's reading of each call, such as **Calls with a bad outcome**, can show it. It clears once the older calls are read again | ### On a version change The tag next to **v7 → v8** sums up the rows that have a better direction, and the issues that moved: | Conclusion | When | | - | - | | **Observed improvement** | Got it done got better and nothing got worse. Or Got it done did not change and everything that changed got better | | **Observed regression** | Got it done got worse, whatever else did. Or Got it done did not change and everything that changed got worse | | **Mixed result** | Got it done got better while a guardrail or an issue got worse, or the others moved in both directions | | **No better or worse** | Nothing with a better direction changed | | **Not comparable** | Nothing changed, and at least one row could not be compared | | **Not enough calls** | Got it done does not have enough calls on one of the versions yet, whatever else moved | A guardrail can carry the conclusion while Got it done is unchanged: a faster **Reply time** alone reads as **Observed improvement**, and the summary says which row decided it. What to do with each is in [Compare versions](/guides/compare-versions). ### Why a small change can read as unchanged The fewer calls a version has, the larger a change has to be before Signal can tell it apart from chance. On a quiet agent, a modest real improvement can show as **Within noise** for a while; it becomes visible as calls arrive. If you expect a small effect, plan to wait, and use [tests](/guides/test-a-fix) for an earlier answer. ## What a comparison cannot tell you * **It is not a controlled experiment.** Retell ships a version to all traffic at once, so the callers, the season or a system behind a tool may have changed at the same time. * **Several metrics are checked at once.** Now and then one moves by chance alone. A single changed guardrail, with nothing else, is weak evidence. * **Numbers from Signal's reading of each call can shift slightly.** Two readings of the same calls can disagree on a few of them, so treat a borderline result with care. * **It cannot say which change moved an issue.** A version bundles every change in it. For one issue, read the sentence above **By version** on the issue page, which waits for the agent's grace period (7 days by default). See [Did my fix work](/concepts/issues#did-my-fix-work). ## Next steps Read a comparison and decide what to do next. Check a fix on real calls before it reaches callers. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.