AI and automation, products, and company sites for remote clients. Designed and built by one person.

Say hello
Obed Johnson

AI · 18 March 2026

Connect the model to a real system

A small robot connected by cable to a laptop showing a data dashboard

A model earns its place when it is attached to something real. A chatbot over your own knowledge, search across your documents, extraction from a messy export, or an agent on an API the team already trusts. Someone asks, gets an answer grounded in that system, and the work actually moves.

The versions I'd build again are all attached to something real. Search over a team's own documents. Pulling fields out of a messy export. A small agent that calls an internal API the team already trusts, then shows what it changed. In each case the model is one step inside a task people were already doing.

Being connected brings its own rules. If the model can write, someone needs to see what it wrote and when. I spend more time on that trail than on the prompt, and I'd rather ship one narrow action with a visible result than a general assistant nobody can check.

Some briefs don't need a model at all. A missing field, a filter, or a better default can remove the work outright. When that's the case I say so early, because wrapping a model around a form problem is how these projects get expensive and stay vague.

When a model does belong, I make its edges plain in the interface: what it read, what it suggested, and what a person approved.