Architecting the AI Coworker

Author's note

I have spent the past few years watching people work out how to use AI in their daily lives and businesses. The same frustration appears again and again. A fluent interface feels like a coworker, so people expect the system behind it to understand, remember and act like one. When it does not, they blame the model or themselves.

Much of the advice around AI makes this worse. It treats the model as the whole product, repeats generic prompting advice and skips the parts a team can actually design. A deployed AI product is a stack of models, context, routing, memory, tools, permissions, checks and human ownership. Change any part of that stack and you change what the system can see, remember, do and damage.

You do not need to understand transformer mathematics or backpropagation. You do need to understand what the model sees, what context it receives, what it remembers, which tools it can reach and what it is allowed to change. Models generate from statistical patterns. Fluency does not turn one into a human mind.

This matters because people are already delegating substantial work to AI. Leaders need to know what authority they are granting. Engineers need to know which controls belong around the model. People using AI in their own work need to know why the same request can produce different results and when a confident answer deserves to be checked.

I began with three essays. The argument kept expanding until it became 22, organised into five arcs. I am now refining the series, adding what I have learned since writing it and turning it into a book scheduled for release in late 2026.