Technology
Can it be built, fixed, or made to do something new?
The chatbot that's really a search problem
"We need an AI chatbot" is one of the most common first messages I get. Usually the model is the easy part. It can only answer from the pages a search step hands it, and that step is handing it the wrong ones.
If your own staff can't find the right document, a chatbot will find the wrong one faster. So the work starts with retrieval: what gets found, and why.
Retrieval. The search step that decides which pages the model reads before it answers.
The shop nobody wants to touch
A headless storefront, started by someone who has since moved on. It mostly works, and everyone is scared to change it in case the parts that don't work get worse.
I read it end to end first, then fix it a piece at a time, in accounts you own, so the next developer can pick it up without the fear.
Headless. The shop's engine and its storefront are separate apps, joined by an API. More freedom, and more joins to break.
The whole stack, one layer at a time
Every piece of technology has people at both ends: the ones it serves, and the ones who keep it running. In between sit the layers where things get built, and where they go wrong.
Pick a layer to see what lives there.
Layer 01
People
The people who use it, and the people who run it. Everything below exists for them.
What it looks like“Nobody uses the new system.”
What it usually isIt was built for the process on paper, not the one people actually follow.
Three systems, three Sams
The shop knows Sam by an order number, the CRM by an email address, and the email tool by a subscriber ID. As far as your reports are concerned, that's three people.
An integration that agrees on who a person is turns them back into one, and suddenly the numbers across all three start to make sense.
Identity resolution. Deciding which records across your systems are the same person.
What Technology covers
AI and language models
Harnesses, retrieval, evaluations, fine-tuning. Making a general model do your specific work, and proving it does.
Web and applications
Front end to back end, built in accounts you own so the next developer can pick it up.
Commerce
Online shops, including headless builds someone else started and nobody wants to touch.
- headless storefronts
Content platforms
Sites your team can edit without calling a developer every Tuesday.
Integrations and APIs
Making the CRM, the shop and the marketing tools agree on who a person is.
Under the hood
How your code actually runs: the JavaScript engine, the event loop, the edge. Where the strange bugs live.
Inside the harness
A general model knows a little about everything, which is a polite way of saying it has never met your organisation. The harness is what makes it useful: the context, the tools, the guard rails and the checks around it.
Here's one question, and what each part of the harness does to the answer.
QuestionCan I take carer's leave to look after my dad?
Answer, after evaluationchecked
Yes. You get 10 days' paid carer's leave a year (Leave policy 2024, section 4). Apply through the HR portal.
Writing on technology
All of it
Got something that needs building, or fixing?
Tell me what you can see going wrong, or what you'd like to be possible. You don't need the technical name for it.
Contact
Tell me what the problem is. You don't need the technical name for it: working that out is part of the job. If I am not the right person for it, I will say so. I reply myself, from Hobart, which is ahead of most of the world (by time zone, and in several other ways I am too modest to list).
- or call
- Book a call
- or code
- github.com/neobadger
Sent. Thank you. It goes to James, and nobody else reads it. I reply in person.