The design process

Eight steps take you from a business request to a blueprint someone can build. Work through them in order: each step's answer narrows the next.

The eight steps

1. Find the real goal

Ask what successful work looks like, who starts it, who takes part, and which system must hold the final record. Requests that sound identical often aren't. "Create a Salesforce case" can mean logging every chat, logging only escalations, helping staff with cases that already exist, or opening a case mid-conversation. Each one is a different design. See One request, four different designs.

You're done when: you can state the outcome in one sentence, along with how you'll check it happened.

2. Name what starts the work

Choose one starting point: someone asks, a conversation is escalated, a conversation ends, a record changes in your CRM, a schedule fires, an email arrives, or someone starts it by hand. Design one clear path before adding others.

You're done when: you know whether the work happens during a conversation or after it.

3. Find the data and how it changes

List where the information lives: policies, manuals, help articles, tickets, contacts, opportunities, code, sensor readings, meeting history. For each one, decide whether it can be learned (stable and approved), must be fetched live (current, personal or exact), or needs a structured table. See Knowledge vs live data.

You're done when: every data source is marked as knowledge, a table, or live access.

4. Choose the audience and the interface

Decide who uses the solution and where: customers through live chat, email, SMS or voice; employees through Copilot, Microsoft Teams or Claude; or a custom screen for structured tasks such as uploading receipts. Different audiences, or private data, usually mean separate agents and separate knowledge. See Choosing the interface.

You're done when: you know who sees what, and where they see it.

5. Decide who may act

List every system the solution touches and separate reading from writing. Settle the details that change the build: whether a case is created every time or only on request, whether an email can be sent without approval, which CRM fields must be filled, and who owns the record.

You're done when: every write action has a named tool, a reason and an approval rule.

6. Choose the agents and the workflow

Use a light, fast model for routine conversations. Add a specialist agent with a stronger model only where the work is consequential, such as creating records. Add a Loop only when the work needs a trigger, a delay, branching, an approval or a record of each run, not to make an ordinary conversation look more sophisticated. See Loops and outbound.

You're done when: you can justify every agent and every Loop step.

7. Plan for exceptions and oversight

Decide what happens when information is missing, a customer can't be verified, a tool fails, a record match is ambiguous, or an approver says no. When an action is new or consequential, put a person in front of it first. Automate further only once the results justify it.

You're done when: every failure has a defined next step, and none of them is silent.

8. Define success and test it

Write tests for the things that must be true: the right sources are found, records are matched correctly, only allowed tools are used, actions leave evidence, routing is correct, and escalation reaches a person. Save your test scenarios and review the conversation history in Copilot and the run history of each Loop. See the Blueprint checklist.

You're done when: a named person has seen the tests pass.

Ask the smallest useful question

You rarely need a long discovery workshop. Find the one missing fact that would change the design most, and ask that first. Where you can, show a draft design with your assumptions marked, rather than asking everything up front.

What you need to know	A question that settles it	What it changes
Who is the audience?	Will customers use this, employees, or both?	Separate public and private agents, knowledge and channels
Where does the work start?	Does someone ask the agent, or should an event or schedule start it?	Agent only, or a Loop with a trigger
What needs recording?	A case for every interaction, only unresolved ones, or only when someone asks?	End-of-conversation webhook, or escalation
Where do the sources live?	Where are the approved articles, manuals or records today?	Import connector, live access, or manual upload
How fresh and exact must data be?	Can it use stored reference material, or must it check current records every time?	Knowledge, a table, or live access
Are changes allowed?	Can it create or change records itself, or should someone approve first?	Tool permissions, approvals and failure paths
Do we know who the user is?	Will people be signed in to your app?	How identity is verified before private data is used
What are the business rules?	How do you define priority, fit, resolution or a good score?	Instructions, examples and branches
Is it a campaign?	Are you messaging a list, or responding to individual new leads?	raia Control, or an event-triggered Loop
Does it need its own screen?	Do people need to upload files or review structured forms?	A custom front end alongside raia

When two designs both work

Compare them in this order, and say out loud when you trade one for another:

Permissions are right. No public route to private information and no unapproved changes.
It fits the business. It delivers the real outcome and respects the agreed system of record.
It produces evidence. Exact data and tool-backed results wherever accuracy matters.
It's simple. Fewer agents, connections, steps and custom applications.
It's observable. You can see what happened and what failed.
It's fresh and fast. Current facts where they matter, without unnecessary lookups.
It's efficient. Light models for routine work, stronger ones only where they earn their cost.

This order is a design guide drawn from how the raia team builds, not a platform scoring rule.