MCP & AI agents
We build the layer that makes AI useful inside a company: internal services exposed as MCP tools, with scoped access, so an agent can read a ticket, look up an order and write back to the right system.
| In production | Since 2025 |
|---|---|
| Projects | 3 |
| Evidence | In production since 2025 |
- MCP servers over stdio and HTTP
- Tool design and schema definition
- Scoped data access through restricted views
- Slack-native agent interfaces
- Retrieval over your own documents
- Evaluation sets for prompt changes
You have systems worth exposing
The value is in the connections. If an agent can reach your tickets, your orders and your documentation, it is useful on the first day.
The input is genuinely open-ended
Triage, drafting, summarising and routing all involve judgement about messy input, which is where a model earns its unpredictability.
You want one interface, not five
A single assistant over your own tools beats every team picking a different chatbot and none of them seeing your data.
You need the boundary enforced
Access scoped in the tool layer holds regardless of what someone types into the prompt.
The process is fully deterministic
If the rule is "when X, do Y", write that. A model is an expensive way to make a reliable process unreliable.
There is nothing to connect to
Without systems worth exposing, you get a chat window with better manners. Fix the integration problem first.
Correctness is non-negotiable
For billing, compliance or anything that reconciles, use plain automation and keep the model out of the path.
An off-the-shelf tool already does it
If the value is not in your own systems, buy the tool. We will tell you when that is the answer.
Built before the tooling existed
Sakurai is an in-house, Slack-native agent platform built on Nest.js: more than fifteen focused agents covering support, product management, code review, release notes, moderation and analytics, with internal services (tickets, support, knowledge, metrics) exposed as MCP tools. It replaced people juggling three to five different models with one named bot, and it was built before the off-the-shelf agent platforms were usable.
Two products since then ship MCP servers as a first-class surface rather than an afterthought. Socialog exposes its whole scheduling and publishing product over MCP and REST, so a post can be scheduled by a human in the calendar or by an agent through a tool call. Bikkel exposes a user's own training data, so an AI coach can reason over it directly.
What the work actually is
Most of it is not prompt engineering. It is deciding which operations are worth exposing, designing tool schemas an agent can use without guessing, and putting the access boundary in the tool layer so an agent physically cannot read fields it has no business reading.
That last part matters more than it sounds. Guarding behaviour with instructions is a request; guarding it with a scoped view is a constraint.
How we scope it
We start from the process, not the model: which internal work costs the most time, how it happens today, and which steps are worth handing over. Some steps come back as agent tools. Others come back as a plain script, and we say so.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.