AI assistants and agents for your team
A general chatbot doesn't know your documents, your customers or your procedures. I build assistants and agents that do, with a source for every answer and clear limits on what they're allowed to do.
Tell me about your projectThe problem
Knowledge sits in documents, wikis, tickets and people's heads. Finding the right answer takes time, and new colleagues keep asking the same questions.
Public chat tools are tempting, but they don't know your context, they can't tell what a user is allowed to see, and they send your data elsewhere.
How I approach it
Start with the questions
We collect real questions and tasks first, so we build for what people need.
Connect the right sources
Documents, wikis, tickets or databases, indexed so the assistant finds the relevant passages and cites them.
Respect access rights
Users only get answers from sources they're allowed to see.
Agents with clear limits
When an assistant takes actions, such as creating a ticket or updating a record, it uses a small set of well-defined tools, and anything risky needs a person's approval.
Measure the answers
A test set of questions with known answers, so quality is measured, not assumed.
What to watch out for
- An assistant without sources is hard to trust. Every answer should show where it came from.
- Outdated documents give outdated answers. Someone needs to own the sources.
- An agent that can do everything is a security risk. Give it only the tools it needs.
Projects like this
World Brain Scholar
World Brain Scholar builds AI software for academic publishers.
My work at World Brain Scholar
A private AI workspace with many agents
The team wanted AI assistants that don't send data to a public chat app. Now they have a self-hosted chat environment with specialised agents, plus a separate API layer that logs usage and caches answers.
- A self-hosted chat environment with agents for different tasks.
- An API layer between the agents and the model providers that logs usage and caches answers.
- Everything runs on infrastructure the client already had.
- Questions and documents from the team
- Specialised agents
- Layer for logs and cache
- Answers inside the client's own environment
Local language models, only when the team needs them
The team wanted to use language models without sending data to an outside provider. But a model on a local GPU holds on to a large chunk of GPU memory, even when nobody is using it. Now the team has one API for all local models. An agent on each GPU machine starts a model on the first request and stops it after an hour without requests, which frees the GPU for other work.
- One OpenAI-compatible API for all local models, which team members connect their chat and coding tools to.
- A dashboard shows which models are running, and admins can start or stop any of them.
- The models run on GPU machines the company already owns. No data goes to an outside provider.
- Request from a chat or coding tool
- Shared API
- Start the model if needed
- Answer from the local model
Frequently asked questions
Can it use ChatGPT, Claude or a local model?
Any of them. The choice depends on your data, your privacy requirements and the cost, and one gateway can combine them.
Where does it run?
In your own environment or a private cloud in the EU, connected to your existing logins.
What is MCP?
The Model Context Protocol is an open standard for connecting AI assistants to tools and data. I use it to give assistants a controlled set of actions in your systems.