Written from systems we operate
A small number of long pieces about putting AI assistants on top of live business systems. Written from production deployments rather than from demos, and kept current rather than dated and abandoned.
Most companies publish what they would like to be true. We would rather publish what we had to find out.
What this is
Not a blog. There is no publishing schedule and there will not be one.
Most company writing exists to be published weekly. It is assembled from things the writer read somewhere else, and it is forgotten by everyone including the company that published it.
We are a small studio and we have no content team, so we cannot beat anyone on volume and are not going to try. What we do have is a set of systems we run in production for other people, and a lot of things we only learned by breaking them first. That is the only thing worth our writing down.
So there will be a handful of pieces here, they will be long, and we will edit them when we learn we were wrong rather than publishing a correction and moving on. If you are looking for weekly commentary on the AI news cycle, we are the wrong studio and this is the wrong page.
One piece so far. We would rather say that than pad the list.
A page listing six items where three are service copy in a different typeface is worse than a page listing one. The second piece is being written; it will appear when it clears the same bar, and not before.
What a governed MCP server looks like in production
Connecting an assistant to a business system is a weekend's work. Connecting one that a finance team still trusts in month six is a different exercise, and almost all of it is spent on refusals rather than capabilities. This is the six controls that do the work: named tools instead of query access, read-only by default, two-step confirmed writes, the user's own permissions rather than the server's, an id-scrub choke point, and a per-call log.
It also carries the one question worth asking at any AI demo, which is not about the model: ask what happens when the assistant is told to do something it should not. A demo answers by explaining that it would refuse. A system answers by showing you the log entry where it did.
What a piece has to clear. All three, not two of three.
We publish this because it is the only way the surface stays useful. A test you keep privately is a test you quietly stop applying around the fourth piece.
What we can write about. Because we had to work it out.
These are not links. Nothing here is published yet, and a card that looks clickable and is not would be its own small dishonesty. Each names the system the lesson came from, so you can judge whether we would have anything to say.
The mapping is the product, not the pipeline
Moving four national ERPs into one database is the easy half. Deciding what a customer, an item and a sale mean when four systems disagree, then holding that decision still while all four keep changing underneath, is the actual work and it never finishes.
From a group reporting platform we have run since 2017.
Build beside the ERP, not instead of it
The standard advice is to replace the old system. We have spent seven years doing the opposite for one distributor: one piece of middleware in front of the ERP, and every system since built against the middleware. Why that decision compounds, and when it is the wrong one.
From five connected systems, first commit January 2019.
What extraction accuracy actually means
A model that is right most of the time and silent about the rest is worse than no model, because the errors are now inside your data. Confidence thresholds, what to do with the doubtful cases, and why the validation is a bigger build than the extraction.
From document pipelines running on Azure.
Why a connector outlives the project that paid for it
We have been developing one ERP connector core since February 2018, across five ERP families and four countries. What survives a decade of other people's schema changes, and what has to be rewritten every time.
From a connector practice in continuous development since 2018.
Corrections
These pages get edited, not retracted.
When something here turns out to be wrong, or a vendor changes terms we have described, we change the page rather than publishing a dated correction underneath it. That means a piece you read six months ago may not say what it said then, and that is deliberate: these are meant to be useful now, not to be a record of what we believed in August. If you find something that no longer holds, tell us and we will fix it.
