The phrase "AI company" has stopped meaning anything. It is worn by a team that wraps a chat box around someone else's model, and by a company that has rebuilt how it operates around agents. Those are not the same thing, and the difference is not the model. It is how many layers of the company the AI actually runs.
We use a narrower term for the second kind: a full stack AI company. It is the subject of a talk on the EVERJUST channel, "FULL STACK AI COMPANIES (FSAC) What does that mean?", and it is the idea the rest of this journal keeps returning to. This piece defines it plainly.
The four layers a company runs on
Strip a business down and it runs on four layers, whatever its industry. There is the substrate it operates inside — the system of record where an order, an invoice, a project and a customer actually live. There is the labour that does the work on top of that record. There is the distribution that makes the business findable and recognisable. And there is the client surface — how a customer is taken on, kept informed, and managed after they pay.
Every company has all four. Most rent three of them and own one. The interesting question for an AI company is not "does it use a model" but "how many of those four layers does the AI operate, and how many are stitched on from outside".
Why "AI on top of your stack" leaks
The common shape is an agent that sits above the tools a company already uses. It reads a mailbox through an API, writes to a CRM through another, triggers a payment through a third. It looks like the agent is running the business. What it is running is a set of integrations.
That arrangement leaks in ways that are structural, not incidental. The agent's actions are API calls that must be reconciled back into the systems of record afterward, and reconciliation is where state drifts. Permissions live in whatever each connected tool happens to offer, so there is no one place that says what the agent may and may not do. The audit trail is scattered across services that were never designed to be read together. And the arrangement is only as durable as the weakest vendor in the chain: when one connected service changes its API or shuts a door, the part of the company that ran through it stops.
None of this is an argument against agents. It is an argument about where they should stand. An agent that acts on top of a business inherits every seam in the business. An agent that acts inside a single system of record does not, because there are no seams to inherit.
What owning each layer looks like
A full stack AI company owns all four layers as one system. In EVERJUST's case each layer is a product, and each one replaces a thing a company would otherwise hire or rent:
- Substrate — EVERJUST.APP. The system of record the business runs inside: its commerce, its projects, its invoicing, its mail, its customers. Not a dashboard that reports on the business, but the place the business is. This is the layer everything else depends on, which is why it is the one to own first.
- Labour — CustomAgents. Agents with their own identity, mailbox and permissions, doing the work against that record. Because the record is the substrate above, an agent's action is a real business object — an order, a task, an invoice — and not a message that something ought to be recorded elsewhere.
- Distribution — Custom Domain. How the business is found and how it looks when it is. A company with no distribution layer is invisible regardless of how well it runs.
- Client surface — CustomPortal.app. Onboarding, intake and the ongoing management of a client relationship after the sale. This product is in development; it is named here because it is the fourth layer, not because it has shipped.
You can read each of the shipped three in more depth on the portfolio: EVERJUST.APP, CustomAgents and Custom Domain.
Why the substrate has to come first
The order of the layers is not arbitrary. Labour, distribution and the client surface all act on something, and that something is the substrate. Put the agents in before there is a system of record for them to act inside, and you are back to the leaky arrangement above: agents calling APIs and hoping the results reconcile.
This is the single choice that separates a full stack AI company from an AI feature. Own the substrate, and the other three layers have somewhere solid to stand. Rent it, and no amount of capability in the other layers changes the fact that the business does not actually run on the AI — it runs on whoever owns the substrate, and the AI is a tenant.
The honest limit of the claim
Owning four layers is harder and slower than wrapping a model, and it is not the right choice for everyone. If what you want is a single task automated — a mailbox triaged, a report drafted — a layer-on-top tool is lighter and will serve you sooner. The full stack argument only starts to pay when you want the business itself, not one of its tasks, to run on agents. That is the line, and it is worth being clear about which side of it you are on before choosing a tool.
We build for the far side of that line. If that is where you are, the rest of this journal — the four products, and the pieces on the harness and on running a company from a phone — is the longer version of this argument.