← Work
Case study · AI

Sakurai

Sakurai is an internal AI agent platform I designed and built — a single, Slack-native assistant that automates a company's day-to-day work, from customer support and engineering to analytics and ops, by turning internal services into tools its agents can actually use.

Sakurai
15+ agents
Focused Slack agents — support, PM, code review, release notes, moderation, analytics…
One assistant
Replaced juggling 3–5 different AI models with a single, named bot
MCP-native
Internal services — tickets, support, knowledge, metrics — exposed as tools

Overview

AI inside a company tends to be a mess. Different teams reach for different models, internal knowledge is scattered across half a dozen tools, and the actually-useful actions — open a ticket, check a payment, write a release note, ship a fix — live behind systems the AI can't touch. So everyone ends up with a handful of disconnected chat windows that can talk but can't do anything.

Sakurai was my answer to that. It's an internal AI agent platform I designed and built to collapse all of it into one assistant the whole company talks to — a single, catchy name to mention instead of remembering which of three to five models is good at what, wired into the company's real services so it can get things done rather than just chat. (The name is a small joke: sakura, cherry blossom, plus AI.)

It lives in Slack

I built it where the team already works. Slack is the interface — there's no new app to learn, and adoption is basically free because everyone is already there all day.

That choice paid off in three ways. Threads are context: you can drop the bot into an existing conversation and it understands what's been said, so it picks up the problem instead of asking you to re-explain it. Every agent gets its own channel — a dedicated space per role, so the support agent, the PM agent, and the code agent each have a home and a focus. And because it's Slack, the conversations are multiplayer: several people and the AI in one thread, working a problem together, rather than each person talking to a private bot in isolation.

Turning the company into tools

The real leverage came from exposing internal services as MCP servers. Tickets, support, knowledge bases, metrics — each became a set of tools the agents could call, so a request in plain English turns into a real action against a real system.

Two things made that safe and genuinely useful. Knowledge bases — Notion, the Intercom support history — are wired in with retrieval (RAG), so answers are grounded in the company's own material instead of the model's best guess. And database access goes through views that deliberately exclude sensitive data, so an agent can answer "what did this user buy?" without ever being able to reach what it shouldn't. The boundaries are built into the tool layer, not left to the model's good behaviour.

Sakurai architecture — one assistant at the centre, connected outward to Slack, Claude, a mailbox, Figma, Puppeteer, GitHub, Intercom, Notion, E2B and Claude Code, with a dedicated Slack channel for each agent
One assistant at the centre, with internal services and external tools wired in as MCP servers — and a dedicated Slack channel per agent.

A roster of agents, not one do-everything bot

Rather than a single bot trying to be everything, Sakurai is a roster of focused agents, each with its own remit, tools, and Slack channel: customer support, a PR 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 (driving a real browser through Puppeteer), a coding agent (running Claude Code in E2B sandboxes), a mailbox agent, and more. Each one knows its job and the tools it's allowed to use — which keeps the agents sharp and their access scoped.

What it can actually do

Because the agents share a common, well-defined tool layer, a one-line request becomes real work. A sample of things people genuinely ask it:

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

None of these is a demo trick. They're the kind of small, repetitive, cross-system tasks that quietly eat a team's day — and handing them to an assistant that lives in Slack and can reach the right systems gives people that time back.

Built before the tooling existed

I built Sakurai as a homegrown agent platform before the off-the-shelf ones existed — a precursor to the agent frameworks now being productised. That meant designing the orchestration, the tool layer, the retrieval, and the safety boundaries myself, on Nest.js and TypeScript.

That under-the-hood work is exactly what separates a flashy demo from something a company actually runs on every day: scoped tool access, data views that protect what matters, agents with clear remits, and an interface people already trust. It's also the work I find most interesting — building at the layer beneath the chatbot, which is precisely the layer that breaks when you try to put agents into production.

Outcome

Sakurai turned "AI at the company" from a scattered set of private chat windows into a single 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 a new capability at a time as new services were turned into tools.