One operating model, every trade
A marketing agency calls it a project, a cabinet shop calls it a job, a consultancy calls it an engagement. Hard-code one of those and you fit a single industry while arguing with every other one, so we made the shape of a business something you describe in data rather than something we ship in code.
Sit in on a Monday morning at a marketing agency, then at a cabinet shop, and you will hear two entirely different meetings about the same thing. The agency talks about projects. The shop talks about jobs. A consultancy across town calls them engagements. Underneath the vocabulary all three are describing one unit of committed work: a client, a scope, a timeline, money attached, and a lifecycle that runs from agreed to done. The words differ. So do the fields, and so do the stages. That gap is where software built for more than one industry usually goes wrong.
Fork it, or flatten it
Pick a schema and hard-code it. Call the unit a project, give it the agency’s fields and the agency’s stages, and you have built something that fits one industry beautifully and argues with every other one. Cabinet installers do not have campaign approvals. A consultancy does not ship deliverables on an agency’s cadence. Sooner or later somebody proposes one of two escapes, and both of them cost more than they look like they will.
- Ship an edition per industry. A cabinet edition, an agency edition, a consulting edition. Now there are N codebases, every fix has to be made N times, and the platform quietly stops being one platform.
- Flatten to a generic schema. Strip out anything that sounds industry-specific until job, project, and engagement collapse into one beige record that technically describes every business and genuinely serves none of them.
One route multiplies the code. The other guts the product. They share an assumption nobody says out loud: that the shape of a business is something you express in code, so changing the shape means changing code and shipping a release.
Where the shape actually lives
Amolfi describes it. The shape of an organization lives in an ontology, a definition of the objects a business has, the relationships between them, and the lifecycles they move through. The platform loads that definition the way it loads any other data.
Every organization boots on a base pack, the vocabulary essentially any company shares: clients, work, money, documents, people. Everything particular arrives as a layer on top of that. Capability packs add a way of working. Overlay packs teach the trade’s language. The cabinet shop’s overlay tells the same engine what a job is, what a cut list is, and how an install travels from measured to fitted. The kernel underneath never learns a thing about cabinets. It reads a different set of packs.
Two things keep that kernel honest. The first is that it is built around what a business does. Take on work, move it through stages, send an invoice at the end: every trade does that, and every trade has its own name for it. The engine works at the level of the doing, and leaves the naming to the pack. The second is that packs get checked on the way in, base then capability then overlay. Write one wrong, or write one that contradicts something already loaded, and it is refused at the door. Your model keeps running while you fix the pack.
One definition, all the way up
The value of writing the model down once is that everything above it reads from the same page. The Company Brain draws its map of your business straight from the ontology, so a cabinet shop sees cabinet-shop objects and an agency sees agency objects out of one engine and two overlays. Amolfi’s agents reason from that same definition. The assistant working a cabinet job already knows what a job is and how one moves, with no shop-specific code sitting behind it. Define the trade once, as data, and the human view and the machine reasoning both inherit it.
The difficulty sits in the kernel, and it is a genuinely hard line to find. It has to be general enough to describe any business and specific enough to be worth using. Too abstract and every pack ends up reinventing what a client is. Too concrete and you have hard-coded one industry with extra ceremony on top. That balance is the real engineering here, and getting it right is what lets a new trade arrive as a pack.
So when a trade nobody has modeled yet walks in, the question is never how much of the platform gets rewritten. It is smaller and far more interesting: what does this trade call its work, and how does that work move? Write the answer down as a pack, let it validate on the way in, and the same engine that runs an agency runs a cabinet shop. The next trade after that one should arrive the same way.