# Worked examples

> Three short jobs an agent can do in Signalbox. Build a flow from a sentence, explain why a lead went where it did, and review a flow.

Each example shows what you ask, what the agent does and the level it needs. The agent picks its own tools. The lists below show the usual order.

## Build a flow from a sentence

**Needs:** Build. Publish as well, if the agent is to publish.

You ask:

```text
Build a Signalbox flow. Companies under 11 people answer four questions,
then book with the company's owner. Everyone else goes to the Inbound queue
and sees the calendar.
```

The agent follows the `build-a-flow` skill:

1. It calls `get_started` to read the rules and the state of the workspace.
2. It asks you anything the sentence leaves open, such as what the four questions are.
3. It looks up what the flow will point at: `list_queues` for the Inbound queue, `list_meeting_types` for the meeting, `list_node_types` for the steps and their settings. A flow holds IDs, not names, so it looks each one up.
4. It writes the draft with `create_flow` and `save_flow_draft`.
5. It reads the issues that come back with each save and fixes them. Each says what is wrong, which step it is on and how to fix it.
6. It calls `dry_run_flow` with sample leads, one for each branch, and checks each takes the branch you meant.
7. It shows you an outline of the flow in words, with a link to the flow in the app:

```text
Form submitted -> If / else: sopro.headcount is less than 11
  Yes: Ask questions (4)
    Answered: Assign to existing owner
      Owner: Show calendar "Intro call" (rep)
        Booked: Create deal in "Sales" -> End
        Not booked: Create task -> End
        Cancelled: Create task -> End
      None: Assign from queue "Inbound" -> (joins Show calendar "Intro call" (rep), above)
      Away: (joins Assign from queue "Inbound", above)
    Left: End
  No: (joins Assign from queue "Inbound", above)
```

8. It publishes with `publish_flow` only when you say so, and only if it has the Publish level. Otherwise you open the link and press **Publish** yourself.

Nothing a visitor sees changes until the flow is published and given to a form.

## Explain why a lead went where it did

**Needs:** Read, with the leads switch on.

You ask:

```text
Why did yesterday's lead from the pricing form go to the queue
and not to the company's owner?
```

The agent follows the `explain-a-lead` skill:

1. It finds the lead with `list_leads`.
2. It reads the lead and its trace with `get_lead`. The trace holds each step the lead passed through, the exit it took and why.
3. It reads the flow with `get_flow`, to match the trace to the steps.
4. It tells you in plain words. For example: the Assign to existing owner step found an owner, the owner was away, so the lead took the Away exit to Assign from queue.

What the visitor typed is marked as data in what the agent reads. The agent does not act on it.

## Review a flow

**Needs:** Read.

You ask:

```text
Review my "Inbound demo" flow. Tell me where a lead could get stuck
or fall through.
```

The agent follows the `review-a-flow` skill:

1. It reads the flow with `get_flow`.
2. It reads the issues that come with the flow: errors and warnings, each with its step.
3. It reads the conditions for leads that fall through. A common one: a lead whose company was not found has blank `sopro.` fields, fails every positive test and lands on the last exit. See [the blank rule](/flows/conditions/#the-blank-rule).
4. It reports dead ends, missing branches and steps in a poor order, such as a slow step before the visitor is shown something.

At Read the agent changes nothing. To have it fix what it found, connect it at Build. The fixes go into the draft, and nothing is live until someone publishes.