Anti-patterns
These are the design mistakes the raia team sees most often. Each one looks reasonable at first, and each one has a better alternative.
Knowledge and data
Live records in a knowledge store
Why it fails: customer records, open opportunities, transactions and sensor readings change constantly. Knowledge search returns passages, not current or complete data.
Instead: fetch them live through a connector. Use Tables for exact structured datasets.
Raw tickets as training data
Why it fails: ticket histories are full of repetition, partial answers and dead ends. The agent learns the noise.
Instead: distill them into a reviewed troubleshooting guide, and train on that.
The model doing the maths
Why it fails: models predict text. They can get arithmetic subtly wrong, which is worst for financial and operational figures.
Instead: use the code interpreter, or calculate on the server.
Invented business rules
Why it fails: priority, lead scores, routing and field values are business decisions. Guessed rules look plausible and quietly cause damage.
Instead: ask for the rubric, the real CRM schema and labelled examples. Check field values against the system, not assumptions.
Audiences and permissions
A public agent with a route to private knowledge
Why it fails: a shared knowledge store, or broad routing to an internal specialist, can expose internal material to customers.
Instead: give each audience its own agent and knowledge. An internal agent may consult a public one, never the reverse.
One agent for every business
Why it fails: different units have different products, owners and rules. One agent ends up with contradictory instructions and too much access.
Instead: copy a proven agent, then tailor and connect each copy separately.
Every write tool on the front-line agent
Why it fails: a front-line agent handles many conversations. Every write tool it holds is a risk in each of them.
Instead: give write tools only to the agent that needs them, often a specialist that checks before it acts.
Instructions as a security boundary
Why it fails: "only do this when…" in an instruction is guidance, not a lock.
Instead: narrow the actual tools and credentials. If the agent shouldn't do it, don't give it the tool.
Browser context as proof of identity
Why it fails: contact IDs passed from a web page can be changed by anyone.
Instead: verify identity on your own servers before an agent reads private records or makes changes.
Actions and evidence
Outbound messages without checks
Why it fails: messages sent without consent, recipient checks or a way to handle replies create legal and reputational risk.
Instead: confirm consent and suppression rules, review early messages, and define where replies go.
"Sent" reported as "delivered"
Why it fails: an email step completes when the message is accepted for sending, not when it reaches an inbox.
Instead: use delivery events from your mail provider, or ask for acknowledgment, when delivery matters.
Trusting the agent's word
Why it fails: an agent saying it created a record isn't evidence that it did.
Instead: require a tool result: a case number, a record ID, a saved status.
Complexity
More agents than the work needs
Why it fails: each extra agent adds cost, latency and places for things to go wrong.
Instead: split only for a real boundary: audience, business unit, risk or expertise.
A Loop for every question
Why it fails: a Loop adds steps and delay to something an agent could simply answer.
Instead: use a Loop only for triggers, multiple steps, branching, approvals or run records.
AI squeezed into a human workflow
Why it fails: making AI reply through every screen of a process designed for people is usually clumsy.
Instead: consider a direct AI channel, or have the agent assist staff with internal notes and drafts.
A strong model everywhere
Why it fails: paying frontier prices for routine lookups wastes money without improving results.
Instead: use a light model for routine work and a specialist gate for consequential actions. See Cost and model choice.