Not a demo.
A part of the system.
Language models are most useful where the work already happens — inside the application, connected to the real data, doing the step that used to be done by hand.
Talk it through →Woven in,
not bolted on.
Inside the product
Drafting a reply, classifying an incoming document, summarising a long thread, filling in what is obvious — happening where the work sits, not in a separate chat window somebody has to remember to open.
Connected to the real systems
A model is only as useful as what it can reach. Over MCP we give it controlled access to the systems that hold the data — an ERP, a catalogue, a knowledge base — with clear rules about what it may read and what it may change.
Automating what repeats
Sorting, extracting, transferring, answering. Steps that were never interesting and never went away, done reliably and logged — so that when something goes wrong it is visible rather than quietly wrong.
This website is
the example.
The site you are reading is written, changed and published through a language model that reaches our own publishing system over MCP. Same for a retail platform, a trade ERP and our internal knowledge base — each with an interface a model can use, under the same rules a person would have.
MADLAB // Publishing is an MCP interface we built for ourselves and then opened up: with it you build and maintain a website with Claude or ChatGPT, under the same rules as a person – preview, approval, versions.
Read the case study Build a website with AI ↗ MADLAB // Tools
Four rules we
do not bend.
This field moves faster than any project plan. What keeps a solution useful two years from now is less about the model and more about how it was wired in.
The model stays replaceable
Whatever is best today will not be best next year. The connection to a provider is a component, not a foundation — swapping it should be an afternoon, not a project.
Data leaves on purpose
What a model gets to see is a decision, taken deliberately and written down. For sensitive material the answer can be a model on our own infrastructure — slower, and sometimes exactly right.
A person confirms what counts
Reading is cheap, writing is not. Anything that changes real data — a price, an invoice, a published page — passes a human first, and leaves a trace either way.
No feature without a job
If it does not remove work or open something that was not possible before, it is decoration. We would rather say that early than build it and watch nobody use it.
The hard part is
picking the spot.
Most companies do not need an AI strategy — they need to know which three steps in their week are worth automating and which are better left alone. We start with the process, look at where time actually disappears, and only then talk about technology. Often the honest answer is a small, boring interface rather than a model.
Understand. Plan.
Build. Grow.
Here the first stage carries the most weight. A model applied to a process nobody understood yet produces confident nonsense, quickly.
How we workWhat else
we work on.
Where does the
time actually go?
That is the more useful first question. The answer decides whether this is an AI project at all — and sometimes it happily is not.