The mental model
Every raia solution is assembled from the same few building blocks. Most of the design work is deciding which block each requirement belongs to.
Four building blocks
Agents
(raia cX)
The intelligence that talks, reasons and acts. An agent's instructions, model, skills, knowledge and tools define what it does. Agents serve people through channels such as Copilot, live chat, email, SMS, voice, Microsoft Teams, and Claude or ChatGPT over MCP.
Knowledge
(raia Command)
Curated, processed information an agent can search: manuals, policies, help articles and approved procedures. Command prepares it and trains it into an agent's vector store. Think of it as what the agent has studied, not as a live database.
Connectors
(raia Command)
Links to the systems you already run. They do two different jobs: importing relatively stable content into knowledge, and giving agents live access to read and act in a system at the moment it's needed.
Loops
(raia Command)
The workflow engine. A Loop starts from a trigger, such as a schedule, a webhook or an incoming email. It runs steps in order, branches, pauses for people to approve, and keeps a record of every run.
Two more products complete the picture. raia Copilot is where your team tests agents, reviews conversations, rates answers and takes over when needed. raia Control runs outbound campaigns to contact lists. It isn't the default for every outbound message: one-to-one follow-up triggered by an event, such as a new lead, is usually better as a Loop.
How the blocks map to deployment
| Deployment step | Product | Building blocks involved |
|---|---|---|
| 1. Connect your systems | raia Command | Connectors and Knowledge |
| 2. Spin up and train the agent | raia cX | Agents and their skills |
| 3. Test the agent | raia Copilot | Agents under review, with human feedback |
| 4. Launch in your tool | Any channel | Agents in channels, and Loops for work that runs without being asked |
Loops can be added at any stage once an agent has proved itself. They're how agents run on a schedule, react to events, and pass work between agents and people.
Five questions that decide the design
1. Is this information learned or fetched?
Stable reference material should be learned. Anything that changes, or is specific to one customer or transaction, should be fetched live from the system that owns it.
| Learn it (knowledge) | Fetch it live (connector) |
|---|---|
| Product manuals and help articles | A customer's account, plan or balance |
| Policies and approved procedures | Open tickets and their status |
| Release notes and event itineraries | Contacts, opportunities and pipeline |
| Troubleshooting guides distilled from past tickets | Inventory, sensor readings and anything that changes by the hour |
2. Is it a conversation or a process?
If someone asks and the agent answers, you need an agent in the right channel, not a workflow. Reach for a Loop when the work needs any of the following:
- It starts without a person asking: on a schedule, from a webhook, or when an email arrives.
- It has several steps in a set order.
- It branches depending on what happened.
- A person must approve something before it continues.
- You need a lasting record of each run.
Inside a Loop, each step is one of three kinds. An agent does the work when the step needs trained knowledge or live tools. The Loop AI processes the result when the step only reshapes, summarizes or scores what came before. A person decides when the step needs approval. See Loops for how each is configured.
3. One agent or several?
Start with one. Split only when there's a real boundary:
- Different audiences. Customers must never reach internal-only knowledge. Give each audience its own agent and knowledge.
- Different businesses. Business units have different products, owners and rules. Copy a proven agent, then configure and connect each copy separately.
- Different risk. A light, fast agent handles everyday questions. A specialist with stronger checks handles the few consequential actions, such as creating records.
- Different expertise. An orchestrator can pass a focused request to a specialist agent. That's a request to another agent, not a hand-off to a person; use escalation when a person needs to step in.
4. Who is allowed to act?
List every system the solution touches, and separate reading from writing. Give each agent only the tools it needs, with the narrowest credentials that work.
Instructions describe behavior, but they are not a permission boundary. If an agent shouldn't be able to do something, don't give it the tool.
Identity matters too. Details passed into a chat widget can personalize a conversation, but they don't prove who someone is. Verify identity on your own servers before an agent reads private records or changes them.
5. Where does the work start?
Name the moment the work begins. It might be when someone starts a conversation, 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 starting path before adding others.
One request, four different designs
"Create a Salesforce case for our support chats" sounds like one requirement. It can mean four different things.
| What they actually mean | The design that fits |
|---|---|
| Log every conversation as a case | An agent handles live chat. When the conversation ends, a webhook starts a Loop that summarizes it and creates the case. |
| Create a case only when a customer needs a person | Escalation triggers case creation, so the issue is picked up while the customer is still there. |
| Help staff work cases that already exist | Staff stay in their CRM. An internal agent drafts a reply or adds a note to the existing case. |
| Let the agent open a case mid-conversation and give the customer a reference | A specialist agent with one narrowly scoped create-case tool checks the details, creates the record and returns the number. |
Asking which one they mean takes one question. Guessing wrong means rebuilding.
The design formula
- Start from the outcome you want and the event that starts the work.
- Choose where people will interact with the agent.
- Decide what is learned and what is fetched.
- Decide what the solution may do, and who approves it.
- Only then decide whether one agent is enough, or whether you need a Loop and more agents.