At Inspo we design and build software products — and the intelligence inside them — shipped end to end by one team.
Most software with “AI” in the pitch was finished first and made intelligent later. A product gets built, a chat box gets bolted to the corner, and a model answers questions about a system it was never part of. That is AI-flavoured software. It is not AI-native software.
The model is architecture, not decoration
When we say we build the software and the intelligence inside it, we mean the model is designed in at the same time as the database schema and the core loop. It has real capabilities: it can read the state of the system, trigger actions, and leave a trail. It is a worker inside the product, not a mascot on top of it.
The model sees the same data the product does — not a stale export.
It acts through the same APIs the interface uses, with the same permissions.
Every action it takes is logged, evaluated and reversible.
What changes when you design this way
Scope gets sharper. Instead of asking “where can we add AI?”, you ask “which decisions in this workflow should not need a human?” — and you build exactly those. The intelligence earns its place the same way any feature does: by doing a job.
Evaluation becomes part of engineering. An agent that answers support tickets is shipped with an evaluation suite, the way an API ships with tests. If you cannot measure it, you have not shipped it.
The practical test
Take the model out. If the product still works exactly the same, the AI was decoration. If a real job stops getting done, it was architecture. We build for the second outcome — it is the difference between software that demos well and software that works.
Let’s keep in touch.
More notes from the studio on X and Instagram — product, design and AI, from the people shipping it.
