Sakurai

What was at stake

AI inside a company tends to sprawl. Different teams reach for different models, internal knowledge is scattered across half a dozen tools, and the useful actions (open a ticket, check a payment, write a release note, ship a fix) sit behind systems the AI cannot touch. The company had people switching between three to five AI chat windows that could talk but could not do anything.

The question was whether AI could take on the small, repetitive, cross-system tasks that quietly eat a team's day, without being given access to data it should never see.

One assistant, where the team already works

Roy designed and built Sakurai as the company's founder and CTO: one assistant with one name, instead of remembering which model is good at what. (The name is a small joke: sakura, cherry blossom, plus AI.)

It lives in Slack, so there was no new app to roll out and adoption came with it. Drop it into an existing thread and it reads what has been said rather than asking for the problem again. Each agent has its own channel. And conversations are shared: several people and the assistant work a problem together in one thread, rather than each person talking to a private bot.

Behind the one name is a roster of 15+ focused agents, each with its own remit, tools and channel: customer support, a pull-request reviewer, a GitHub coordinator, a release-notes writer, a product analyst, a user-spending analyst, a technical project manager, a chat moderator, a browser agent, a coding agent, a mailbox agent and more.

What people ask it to do

A sample of real requests:

• Read a user's Intercom support conversation and check the status of their latest payment.
• Read today's messages in a support channel and open a ticket for every technical issue reported.
• Fetch all open pull requests and nudge the author of any that has been open more than a week.
• Read a ticket's description, implement it, and open a pull request.
• Write a database query that returns all purchases for a given user.
• Schedule a meeting tomorrow from 2–3pm and invite two teammates.
• Clear the CDN cache for a URL pattern, or flip a feature flag in the development environment.

These are the small, repetitive, cross-system tasks that quietly eat a team's day. Handing them to an assistant that lives in Slack and can reach the right systems gives people that time back.

Safe to give it real access

The value comes from letting agents act on real systems, which is also where the risk is. Internal services (tickets, support, knowledge bases, metrics) are exposed as MCP tools, so a plain-English request becomes a real action, and three boundaries keep that safe:

• Answers come from the company's own material. Notion and the Intercom support history are wired in with retrieval, so answers are grounded in what the company knows rather than the model's best guess.
• Sensitive data is out of reach by design. Database access goes through views that exclude sensitive fields, so an agent can answer "what did this user buy?" without ever being able to reach what it should not. The boundary sits in the tool layer, not in the model's good behaviour.
• Each agent only gets the tools for its job. Every agent has a defined remit and a defined set of tools, and the coding agent runs Claude Code inside E2B sandboxes.

Sakurai was built before off-the-shelf agent platforms existed, so the orchestration, tool layer, retrieval and safety boundaries were all designed in-house on Nest.js and TypeScript.

What changed

"AI at the company" went from a scattered set of private chat windows to one assistant that does real work in the place people already collaborate: grounded in the company's own knowledge, scoped to what each agent should see, and extended one capability at a time as each new internal service became a tool.