We have been reorganising the way we engage with our clients, and this is a description of where we have got to so far. Far from a finished method. Parts of it we are still arguing about internally.
The thing we kept running into is simple, requests arrive specific: one team needs a particular kind of document produced repeatedly, another needs a particular kind of monitoring. Build exactly what was asked for and you get a tool that works for one person and dies with them. Build the generic mechanism underneath it and you have also answered the next request, which is usually the same problem wearing different clothes.
Tier one: the constitution
The bottom layer is a single skill describing how the organisation works. Not a process manual, but principles: what we do, what we never do, what language we use, what good looks like. Models now have enough judgement that describing the shape of the business works better than hardwiring a sequence of steps, because the description covers the exceptions a fixed route would miss. It is an evolution of the backbone skill we wrote about earlier this year: the same idea, taken further.
We have started calling ours the constitution and treating it that way. It contains its own rules for amendment. Some clauses are settled, some are open. Decisions taken in a meeting about how we work from now on go into it, because nearly every piece of work flows through a model connected to that skill. Change the constitution and behaviour changes the same afternoon, which is more than most internal memos manage.
Tier two: the graph
Above that sits the graph: people, organisations, documents, and the connections between them, together with the servers that expose all of it to a model. Deliberately dull and deliberately reusable, built once and connectable in whatever direction the next problem needs.
This is the layer that takes the longest and shows the least. It also requires understanding how many genuinely distinct problems you have, rather than assuming each new request is one.
Tier three: the AI shop
On top, someone brings a specific recurring problem and gets something back in days rather than months, because the two layers below have already done most of the work. We have been calling this the AI shop: we are the shop, and what we build are apps.
An app is thinner than it sounds. The constitution already knows how the work is done and the graph already holds the material, so the app itself is often a single line telling the system to do just this one thing. It is thin because the foundation underneath it is thick.
What makes an app usable is the inversion. A skill that knows how to build a presentation does not tell you how to ask for one, so you open it and stall. An app starts by interviewing you instead: who is this for, how long, which format. Rather than you prompting the system, the system prompts you.
The discipline is that nothing built in the shop stays bespoke. Whatever we build there should leave a generic mechanism behind in the layers below, ready for the next version of the same problem.
What we have not worked out
Where the line between tiers falls is unclear. One large skill covering a whole domain, or several smaller ones that compose? There are good arguments on both sides and we have not settled it (probably different organisation will go different ways).
And the shop is hard to price. Its cost is essentially the cost of the people keeping it running, which is easy to measure, while its value shows up as problems that quietly stopped being expensive.
The method is provisional. The principle underneath it is less so: if you find yourself building the same thing a third time, you built the wrong thing the first two.