Guides
The rest of these docs are organised by surface — Configuration, Agents, Tools, Knowledge base — because that's how the product is organised, and it's the fastest way to answer "what does this setting do?"
Guides are the other way round. They start from something you're trying to achieve and cross whatever surfaces the job needs.
Start where you are
Most people arrive here with one of two sentences in mind.
"I'm building something new and want the shape before I commit." → a build guide. One outcome, taken end to end.
"Mine works, but it's too expensive / gets things wrong / feels clumsy." → a practice guide. One concern, applied across a whole system.
They're different jobs. A build guide is read once, in order. A practice guide is read repeatedly, at different stages, by someone who already has something running.
The shape of the work
Whatever you're building, it moves through the same four stages — and it's a loop, not a line. You'll go round it many times; only the first lap starts at the beginning.
Each stage has one question that tells you whether to move on:
| Stage | The question | If you can't answer it |
|---|---|---|
| Design | What are we building, and what shape does each piece take? | You'll discover the shape was wrong after it's wired together, which is rework rather than a refactor |
| Build | Does it do the job, including when things go wrong? | The unhappy paths become incidents instead of branches |
| Prove | Would we notice if a change broke something else? | Every release is a guess, and the first identity tweak is when you'll wish you'd started |
| Operate | What does it cost, and where is it failing? | You optimise the thing that's easiest to see rather than the thing that's actually expensive |
Build guides walk you around the loop once. Practice guides are what you reach for on every lap after that.
Build guides
One outcome, built end to end — the decisions, the screens, and the unhappy paths.
Practice guides
One concern, across everything you've built. These are the questions that only appear once a system is real — and none of them is answerable from a single settings page, which is why they belong here rather than in the reference.
On the way. Each will follow the same shape: what actually drives it, where it leaks ranked biggest-first, a decision table, how to measure the change, and the optimisations that backfire.
| Guide | The question it answers | What it will cover |
|---|---|---|
| Control cost | Why is this costing what it costs, and which lever is worth pulling? | What each turn actually pays for — tools weighed per turn, conversation history, payload size, how many agents share the routing prompt, and where a cheaper model is safe |
| Keep it accurate | Why does it pick the wrong thing? | Triggers and exit descriptions that overlap, tool descriptions as the only basis for selection, the branch ceiling as a design signal, and where a weaker model starts costing you accuracy |
| Stop it inventing things | Why did it say something that isn't true? | Grounding answers in tools and knowledge rather than the prompt, why policy in a prompt goes stale silently, and the difference between "no result" and "couldn't answer" |
| Design for the channel | Why does this feel worse on a phone call? | What silently doesn't happen on voice, turn length and menu size, covering waits, and always leaving a way through to a person |
| Prove it still works | How would we know if a change broke something else? | Building a regression set from real conversations, what to test beyond the happy path, and what must be true before publishing |
On the way
| Guide | What it will cover |
|---|---|
| Migrate from Cloud to Nexus | What carries over, what has to be rebuilt, and a staged order that avoids an outage |
| Build a returns and refunds assistant | Policy answers, the returns procedure, order systems, and going live across channels |
| Take an agent to voice | What changes on a phone call, voice settings, telephony, and testing by call |
| Connect your systems | Choosing between a workflow, a function, an API tool and an integration — and handling failure |
If there's an outcome you'd like walked end to end, tell us through the feedback control at the bottom of any page.
Related
- Quickstart — one agent, one tool, one test, in about 15 minutes. Start here if you've never built on Nexus.
- Create an agent — a shorter router: which type of agent fits the job you have.
- Agent node recipes — the two node shapes almost every multi agent is built from.