Source: https://docs.cumuluslabs.io/walkthrough
Content version: a80ff089

# Product walkthrough

Use Talos to build an agent visually, test a published version and review what happened in each run. These screenshots show the current application with synthetic demo data; they are illustrations of the interface, not customer outcomes or performance measurements.

## Go deeper with a complete workflow {#examples}

| Workflow | What you will see |
| --- | --- |
| [Build a branching support agent](/docs/advanced-flows) | Verification, HTTP action settings, conditional routing and a reusable component |
| [Investigate a run](/docs/investigate-runs) | Conversation, event timeline, allowed/denied actions and delivery receipts |
| [Test a candidate publication](/docs/regression-testing) | Saved cases, action mocks, version-pinned results and failure evidence |
| [Choose your platform](/docs/choosing-a-platform) | The responsibilities you own with a custom build, Retell or LiveKit Cloud |

## Explore the larger workflows {#larger-workflows}

![A multi-component support workflow with verification, request routing, refund review and escalation](https://docs.cumuluslabs.io/docs-assets/support-resolution-map.png)

[Order resolution](/docs/order-resolution) follows the caller from account verification through policy checks, an external write and a confirmed or uncertain outcome. Inspect the reusable components and action contracts in the guide.

![A qualification flow with structured fields, specialist routing, booking and CRM follow-up](https://docs.cumuluslabs.io/docs-assets/qualification-map.png)

[Qualification and booking](/docs/qualification-booking) shows how requirements become a routing decision and how a requested reservation differs from a confirmed appointment.

![A cloud operations flow with event-triggered and scheduled paths](https://docs.cumuluslabs.io/docs-assets/after-call-map.png)

[After-call operations](/docs/after-call-operations) continues the work as a separate cloud run. The guide explains source-field mappings, schedule input, result schemas and downstream reconciliation.

![An HTTP action editor with credential reference, timeout, endpoint and request schema](https://docs.cumuluslabs.io/docs-assets/support-action-contract.png)

The [action setup](/docs/order-resolution#actions) connects the conversation to your own business service. It makes the endpoint and input contract explicit while the run review records the resulting attempts and receipts.

![A baseline and candidate trial aligned to show where their behavior diverges](https://docs.cumuluslabs.io/docs-assets/regression-baseline-comparison.png)

[Release an agent](/docs/release-an-agent) shows publication changes, pinned test results, assertion evidence, baseline comparison and human judge feedback. These records explain a release decision more precisely than a single demo call.

## Before you start {#prerequisites}

Open [Talos](https://app.cumuluslabs.io) and sign in to your workspace. Choose the intended environment in the workspace switcher. A sandbox is a separate environment with its own agents, runs, secrets and phone configuration; select it before creating test resources. An organization admin manages API keys, credentials and telephony. A member can build agents and start runs; a viewer can review them.

If your workspace has no sandbox or refuses runs, ask your organization admin or Cumulus representative to confirm setup. See [Workspace and access](/docs/operations#environments).

## Build a flow {#editor}

![Talos agent editor showing a demo support flow with greeting, help and end nodes](https://docs.cumuluslabs.io/docs-assets/agent-editor.png)

*Agent editor, synthetic demo workspace. Prompts and connections describe the conversation; the inspector edits the selected node.*

1. Open **Agents** and create an agent from a template, or import a Retell conversation-flow export. Choose a cloud task, cloud chat or phone template that matches the work you want it to do.
2. Edit the global prompt to state the agent's job, boundaries and expected inputs. Select each node to edit its instructions. Add transitions for the decisions that move the conversation to the next node.
3. Add the actions your flow needs. HTTP credentials belong in secrets; use references in the agent instead of embedding credentials in prompts or URLs.
4. Validate the draft. Fix errors before publishing; review warnings for behavior that needs a deliberate choice.

A draft is your working copy. Editing it does not change a published version or a run already in progress. [Agents](/docs/agents) explains nodes, variables, actions and draft conflicts.

## Test a version {#test}

Publish a test version before running a repeatable evaluation. In the API, `live: false` creates the publication without moving the live version. Run a simulation suite against its exact version, review failed assertions, and inspect the trial transcript. For a phone agent, a browser voice session lets you listen and talk to the agent without placing a carrier call.

Simulations answer a different question from voice testing: assertions check conversation behavior, while a browser session helps you assess spoken interaction. A successful simulation does not prove carrier connectivity. Use an authorized test number when verifying a real phone call.

Follow [Test an agent](/docs/testing) and the [publish-and-test recipe](/docs/recipes#import-and-test).

## Review a run {#review}

![Talos run review showing a demo support conversation, run status and transcript](https://docs.cumuluslabs.io/docs-assets/run-review.png)

*Run review, synthetic conversation. A recording appears only when it was requested and is available.*

Open **Runs**, filter by agent, channel or state, and select a run. Review the transcript, timeline, tool calls, analysis and usage. Check the publication version to establish exactly which behavior ran. A run keeps that version even if you publish or roll back later.

For integrations, use the corresponding reads:

| What you need | Endpoint |
| --- | --- |
| Run state and pinned version | [Get a run](/docs/reference/runs.get) |
| Messages and conversation turns | [Get a transcript](/docs/reference/runs.transcript) |
| Live progress and event history | [Read or stream events](/docs/reference/runs.events) |
| Whether an action was allowed and delivered | [Get action receipts](/docs/reference/runs.effects) |
| Structured cloud task output | [Get a task result](/docs/reference/runs.result) |
| Recording availability and an expiring URL | [Get a recording URL](/docs/reference/runs.recording) |
| Extracted fields and disposition | [Get analysis](/docs/reference/runs.analysis) |
| Metered usage and cost | [Get run usage](/docs/reference/runs.usage) |

An admitted run has been accepted; it has not necessarily completed. After completion, an output may still be processing or may be unavailable. Read each output's `state` rather than assuming every run has a recording or result.

## Go live and iterate {#go-live}

Promote the tested publication when you are ready. New runs that omit a version use the live version; existing runs keep their original version. To undo a behavior change, promote an earlier publication. Keep the test suite so you can run it against the next draft's publication and compare results.

For phone deployment, complete [carrier and number setup](/docs/phone) and confirm inbound routing separately if you need incoming calls. For application integration, follow the [API quickstart](/docs/api#quickstart).