Skip to content

Solution Design Playbook

Pattern library

Pattern library

Twelve reusable shapes cover most agent solutions. Start from the closest pattern, then adjust it to the real trigger, data and permissions. Don't copy a pattern blindly: the right design depends on what the business actually needs.

Knowledge-backed agentP01

Starts when:
someone asks a question.
How it works:
  1. A person asks in a channel such as live chat or Copilot.
  2. An agent trained on approved knowledge answers, citing its source.
  3. Uncertain or out-of-scope questions are escalated.
Use it for:
FAQs, product manuals, event information.
Watch for:
adding a Loop or a CRM write by default. This pattern doesn't need them.
Scenarios:
S05, S21

Document every conversationP02

Starts when:
a conversation ends.
How it works:
  1. The conversation is summarized and scored.
  2. A webhook starts a Loop.
  3. A CRM-connected agent creates the record, with the status and fields mapped correctly.
  4. The run history keeps the evidence.
Use it for:
making the CRM the complete record of support.
Watch for:
duplicate records, matching the conversation to the right contact, the CRM's required fields, and the fact that the record is created after the chat ends.
Scenarios:
S01

Act during the conversationP03

Starts when:
a person asks for help the agent can't give, or the conversation is escalated.
How it works:
  1. The agent escalates, or calls a specialist with a scoped write tool.
  2. The record is created and its reference returned.
  3. The team is notified, or a person takes over.
Use it for:
creating a case only when one is needed.
Watch for:
expecting a Loop's result to appear in the live chat. It won't unless you design a way back.
Scenarios:
S03

Assist staff in existing systemsP04

Starts when:
a staff member asks in Copilot, or a new ticket arrives in an existing system.
How it works:
  1. The agent reads the live record.
  2. It analyzes the issue against approved knowledge.
  3. It adds an internal note, a draft reply or a routing suggestion. Staff send the final response.
Use it for:
a careful first step with an existing ticket queue.
Watch for:
assuming the only option is for AI to reply through the old system. A direct AI channel is often better.
Scenarios:
S02

Separate private and public knowledgeP05

Starts when:
an employee or a customer asks a question.
How it works:
  1. An internal agent with internal knowledge serves staff.
  2. A separate public agent with customer-safe knowledge serves customers.
  3. The internal agent may consult the public one. Never the reverse.
Use it for:
Tier 1 and Tier 2 support, confidential procedures.
Scenarios:
S04

Scheduled digestP06

Starts when:
a schedule fires, daily or weekly.
How it works:
  1. An agent fetches live records.
  2. It prioritizes them against your business rules.
  3. The Loop AI formats the result, if needed.
  4. An email or report step sends it.
Use it for:
a morning focus list, a weekly changelog.
Watch for:
the difference between sent and delivered, exceptions to your priority rules, and who may see which records.
Scenarios:
S08, S19

Approve, then actP07

Starts when:
an event, a schedule, a webhook or a person starts it.
How it works:
  1. An agent drafts a proposal.
  2. A person decides.
  3. A rejection sends it back with feedback for revision.
  4. On approval, the agent takes the permitted action.
  5. The result is checked.
Use it for:
CRM follow-up tasks, outreach, new bug reports, blog posts.
Scenarios:
S10, S18, S22

Answer questions from live dataP08

Starts when:
someone asks about a database, CRM or sensor feed.
How it works:
  1. The agent calls a purpose-built, read-only API or MCP server.
  2. It receives structured records.
  3. It calculates in code.
  4. It explains the result, with its context and time.
Use it for:
business metrics, operational telemetry.
Watch for:
answering exact totals from knowledge passages. Never do this.
Scenarios:
S13, S14

Specialist gateP09

Starts when:
a front-line agent decides an action is needed.
How it works:
  1. The front-line agent collects and confirms the details.
  2. A specialist on a stronger model checks they're complete and the identity is right.
  3. It either asks for what's missing or takes the action with one scoped tool.
  4. The result is returned.
Use it for:
CRM cases and other consequential actions.
Watch for:
a gate that only relays the request. It must actually check.
Scenarios:
S07

Campaign or event-driven outreachP10

Starts when:
there's a list to message, or a single new event such as a lead.
How it works:
  1. Lists and ongoing campaigns go to raia Control.
  2. Individual events start a Loop: enrich, draft, approve, send.
Watch for:
consent and channel rules, which sit outside the AI design but must be settled first.
Scenarios:
S12, S24

Gopher retrievalP11

Starts when:
a stronger model needs to work with many records.
How it works:
  1. The stronger model calls a raia agent exposed as an MCP server.
  2. A light agent retrieves and filters the records.
  3. It returns a compact answer with sources.
  4. The stronger model reasons over that answer.
Watch for:
losing source references, or compressing so hard that key details are dropped.
Scenarios:
S23

Custom front endP12

Starts when:
someone submits a form or uploads a file.
How it works:
  1. A purpose-built screen captures the input.
  2. An agent extracts and checks the details, and the person confirms them.
  3. A webhook starts a Loop for review and approval.
  4. The approved result updates the target system.
Use it for:
receipts and reimbursements, structured requests.
Watch for:
assuming agents and Loops create the screen. The front end is a separate deliverable with its own owner.
Scenarios:
S15