This is what it actually looks like.

Kaima

What you are actually asking for

Almost everything written about implementing AI in a business explains why you should. Very little of it shows you a week.

It is the thing we are asked most often, and almost never in those words. It arrives as “what does it actually look like”, then a minute later as “they don't know how this looks”, then as “they still don't know how that can work”. Three runs at the same request inside one conversation.

That is not a request for an explanation. It is a request to be shown. Most content in this category answers it with a well-argued essay, which is why it does not land. You already accept the argument. What you cannot picture is the thing.

What we can show you, and what we cannot

Start with the limit, because it changes how you should read the rest. Asked which client is closest to letting us use their name, the honest answer today is “no clients to name at the moment”. So there is no case study here, no logo strip and no testimonial.

A client is needed to show you a case study. A client is not needed to show you what the work looks like. Those are different things and only one of them is blocked.

So everything on this page and the pages under it is our own: our own builds, our own checks, our own decisions written down at the time instead of reconstructed afterwards. It is first-party, it needs nobody's consent, and it happens to be closer to what you are trying to find out, which is whether the people you are talking to have done this rather than whether they can describe it.

Three things you can look at

Each of these shows a different part of the job, and each one says where it stops.

A business you can see

The felt problem is almost never workload. It is that the systems do not talk to each other and the owner cannot see their own business. The phrase we hear back is “a bunch of existing legacy software… generally not one integrated package”. The dashboard page traces where each number on a screen comes from, and what it takes to keep those numbers true after the systems underneath them change.

The work behind the screen

The build-and-check page walks the sequence in order: what happens at each stage, which gate blocks what, and what we do when a check fails rather than what we do when everything passes. The failure path is the part worth reading.

This website

This site is itself a worked example of the second claim we make everywhere: a system has to be fed the business's own knowledge rather than generated filler. Every section of every page here carries a source pointing at the founder interview answer it came from. Not as a flourish: it is the only reason we can tell you the pages are not machine-written from a topic list.

Five things that broke, and what caught each one

This is the part a capability list cannot show you. Every one of these happened on work we have done, and every one of them is here because of how it was found rather than because of what it was.

1. Sending stopped, and nothing said so. One stored password was wrong, so an outbound engine and its invitation emails both failed on an authentication error nobody saw. Pages rendered. Queues filled. Nothing left the building. It surfaced when a person ran an actual send test.
2. A campaign nearly went out addressed to “Hi there”. A hundred and seventy-three contacts were enrolled, but the merge data sat on the enrolment instead of the contact, so every draft rendered with a blank name. The review queue caught it before a single one sent, which is the entire reason the review queue exists. The list was then cut to twenty-one people who had actually emailed us.
3. A model matched confidently and was mostly wrong. The first automated pass at reconciling eight years of accounting records against company records matched eighty-eight of a hundred. Five were safe. One linked a union branch to a state government department. Every match after that was confirmed by a person before it was written.
4. A finished job was not finished. A bulk image fetch reported itself complete while nine of its thirteen batches had silently failed, leaving 5,101 image locations found and never retrieved. Nothing in the job's own report showed it. Comparing the files on disk against the database did.
5. A review truncated itself and looked complete. A document-checking model hit its output limit and returned a partial list of findings that read exactly like a finished one. Measured against jobs a human reviewer had already marked, it was recalling twenty-two per cent. That layer still runs in shadow mode, where it can be measured and cannot be relied on.

Every one of them failed silently and looked fine. None announced itself, and four of the five were found by a check somebody had built on purpose rather than by anything going visibly wrong. That is what the unglamorous half of this work actually is.

What we refused to build, and why

Restraint is harder to show than capability and it is the better signal, so here is a list of things that were possible, asked for, or half-built, and then deliberately not shipped.

• No writing back into a client's marketing system. The push was built and then rejected. Our database is the record, and a write in that direction could overwrite a do-not-contact flag. The sync reads and never writes.
• No bulk sending and no bought lists. Outbound goes one at a time, capped per day, with a person approving each draft before it leaves.
• No automatic publishing of generated material into a client's folder. One run put the wrong client's artwork in the wrong place. Candidates are now staged for a person, always, with no exception for a confident-looking result.
• No score. On a consumer product in the group, the system describes character across several axes and refuses to publish a rating or a ranking. A check in the build fails any page that tries.
• No quantity a customer typed becomes a purchase order without a member of staff signing off in between.

Each one is a place where the machine was capable and was not allowed. One of the clearest enquiries we have had opened with “I want to implement AI, but I want to do it properly, protect our client data and make sure everything is compliant and safe”. This list is what that answer looks like once it stops being a sentence.

The part that does not photograph well

A page of screenshots implies the opposite, so it needs saying: the interesting-looking part is a small share of the work.

Most of a real integration is reading the shape of data in systems that were never built to be read from: an export that changes column order without warning, a field two people fill in differently, eight years of records where the customer name was typed by hand each time. None of that makes a good screenshot and all of it decides whether the screenshot is true.

The demo is the part that photographs. The plumbing is the part that costs. Anyone showing you only the first one is showing you the easy half.

What a good Monday looks like, and what it does not

A brief for this section asked what it looked like on the Monday afterwards. We cannot answer that in the past tense yet. We have not measured a client's Monday, and describing one from memory would be the kind of claim this whole page argues against.

What we can give you is the shape we are aiming at, so you can decide whether it is worth having. The same people come in and do the same jobs. Nobody is let go and nobody is hired. What changes is what they can see without asking somebody else: the question that used to take a phone call and a spreadsheet is on a screen, and it is the same answer for everyone looking at it.

Savings, where they arrive, arrive as a consequence of people being able to do their existing work better, not as a headcount line. We will not put an hours-saved figure on this page, because we have not measured one on our own operations yet, and republishing somebody else's would tell you nothing about us.

Where to look next, depending on where you are

Three positions, and they need different pages rather than one page pitched at the average of them.

• You know your processes could be better, but not that AI applies to them. Start with why AI projects fail before anything about what could go right.
• You have built software in the business before. The thing your experience does not cover is what changes between something that works and something other people depend on: pilot to production.
• You have done the reading and know it can all connect. You want the architecture, not the argument. Start with visibility across a business, then AI on your own data. Both of those describe the connected version, and both say the same thing about getting there: the way in is one process at the front of the business, not the whole map at once.

If none of those is you, the AI for business library is the front door and says plainly which page serves which question.