Strawbay’s console comes with three agents: Anna who supports, Saga who teaches, and Barry who builds. Behind their easy, helpful surface sits a deliberately narrow design: the right knowledge, a constrained set of tools, strict isolation per customer, and a human in control of anything that touches production. We sat down with Rickard Elmqvist, who works on the agents, to talk about the choices behind them.
It is tempting, when AI is everywhere, to bolt a chatbot onto a product and call it done. Strawbay went the other way. The agents are useful precisely because of what they are not allowed to do.
“We did not want AI for its own sake. We wanted useful, perfected AI that actually helps people in the console, and then we spent most of the effort making sure it stays firmly in its lane. The interesting work is not the model. It is the guardrails around it.”
Rickard Elmqvist, CEO, Strawbay
The three agents map to three jobs. Anna is support: she answers questions and helps users get things done, working from the knowledge base and from read access to what each user is already allowed to see. Saga is the tutor: she guides people through the platform and how integrations work, so teams get productive faster. Barry is the builder: he can create and change integrations, but every write runs through plan mode and explicit human approval before anything happens.
“Barry proposes a documented plan, a person reads it, and only then does it execute, step by step. The agent never reaches around the approval. That single rule is what lets us give a builder agent real capability without giving up control.”
Rickard Elmqvist, CEO, Strawbay
Underneath all three sits a governed knowledge base. The agents answer from a curated, continuously maintained store of product knowledge rather than improvising from the open internet. Just as important is what never enters that store. Knowledge is sanitised with defence in depth before anything is written, so secrets and personal data are scrubbed out. Customer data does not live in the shared store at all.
“The knowledge base is shared and sanitised, never a dumping ground for customer data. When an agent genuinely needs your live data, it reads it through scoped tools, in the moment, for that purpose. The store stays clean by design.”
Rickard Elmqvist, CEO, Strawbay
Keeping that store useful is its own discipline. Indexing services run quietly in the background so the knowledge base reflects the current state of the product, rather than drifting out of date. The aim is an agent that is helpful today and still accurate next week.
This is where retrieval matters. The agents do not lean on whatever a model happened to memorise in training. At answer time they retrieve the relevant, current passages from the governed store and reason over those, so every answer is grounded in what is actually true about the product right now. New guides, release notes and resolved questions are indexed as they appear, which means the pool the agents draw from keeps getting broader and sharper without anyone retraining a model.
“Retrieval is what keeps the agents honest. They answer from the indexed knowledge, not from a memory that froze on the day a model shipped. When the product changes, we index the change, and the next answer already reflects it.”
Rickard Elmqvist, CEO, Strawbay
That turns into a loop that compounds. Where the agents fall short, a question they answer thinly, a gap a customer runs into, that becomes the next thing we capture, sanitise and index. Each pass closes a gap and the knowledge gets a little deeper, so the agents genuinely get better and better over time, grounded in the product rather than guessing at it.
“Every gap we find is just the next thing to index. The agents improve because the knowledge behind them improves, continuously, and that is a far safer way to get better than letting a model freelance.”
Rickard Elmqvist, CEO, Strawbay
The agents reach the platform through a constrained tool layer, Strawbay’s approach to the Model Context Protocol. Rather than open-ended access, capabilities are organised into toolboxes that can be switched on or off per agent and per role. A support agent simply does not see the tools a builder uses, and the model only ever has the capabilities its role is permitted to use.
“Tool access is a dial, not a switch. We can turn toolboxes on and off per agent and per role, so each agent sees exactly the capabilities it needs and nothing more. The model cannot use a tool it was never handed.”
Rickard Elmqvist, CEO, Strawbay
The final layer is isolation. Every conversation is bound to the user and their tenant, and knowledge, data and tools are scoped per customer. One customer’s agent cannot see another customer’s world, and that boundary is built into the platform rather than left to good intentions. Inference itself runs in the EU, on the same region as the rest of the platform, so prompts and data stay on the default European path.
The throughline is consistent: useful AI that speeds people up, kept firmly in its lane, with humans in control of anything that matters. For more on the agents and the governed tool layer, see our Agents and MCP page.