Skip to content

Why a holding company, not a startup.

The structure you choose decides what gets reused. We chose the one where infrastructure belongs to the group.

The default advice for anyone building in AI right now is to pick one problem, go deep, and defend the position. It is good advice, and for a single product it is probably correct. We chose a different shape, and the reason is narrow enough to state plainly: we did not want the second company to start from zero.

Structure decides what gets reused

Inside a startup, everything that is not the product is overhead. Evaluation harnesses, telemetry, orchestration, the machinery for keeping long-running tasks alive, all of it exists to serve one roadmap and is shaped tightly around it. When the same team later starts something else, that work rarely transfers, because it was never designed to.

A holding company inverts the ownership. The infrastructure belongs to the group, and each venture is a tenant on it. That single change is what makes the fourth company cheaper than the first, because by then the substrate has already survived production traffic from three others.

Every venture returns its infrastructure to the group. That is the whole thesis, and everything else follows from it.

What it costs

This is not free, and it would be a poor argument if we pretended otherwise. Building shared infrastructure before you have a second consumer for it is speculative work, and speculative work is exactly what a focused startup is right to avoid. We accept that cost deliberately, but it is a real cost paid up front against a return that only arrives later.

There is also a discipline problem. A structure that makes starting things cheap makes starting the wrong things cheap too. Our answer is that no venture begins from an idea. It begins from a constraint we have observed inside a live operation and can name precisely: the call nobody answered, the lead that went cold, the team drowning in follow-up. If we cannot point at the constraint, we do not incorporate anything.

Operating, not advising

The other half of the structure is that we run what we build. We are not an agency, and we do not hand over a prototype and invoice for the engagement. Each venture is staffed and operated, and its performance is measured against the human process it replaced.

That constraint keeps us honest in a way advisory work does not. When you operate the system, the failures arrive at your desk rather than someone else's, and the difference between a demo and an operation stops being a matter of opinion.

Hala AI was the first test of the structure. It came out of a research programme into where operations break, it shipped narrow, and it is now in private pilot against live customer traffic. Outbound Engine and Operations Copilot are being built on what it left behind.

FAQ

Related questions.

What is an AI holding company?

A holding company that incorporates, funds, and operates multiple AI companies under one structure, with research, infrastructure, and operators shared across the portfolio rather than owned by any single venture.

How is that different from a venture studio?

A studio typically builds companies and spins them out. Meta Empires holds and operates its ventures, so the infrastructure each one produces returns to the group and is inherited by the next.

What are the downsides of the holding company model?

Shared infrastructure is speculative work before a second venture exists to use it, and a structure that makes starting things cheap also makes starting the wrong things cheap. The discipline that offsets it is refusing to start a venture without a named constraint observed in a live operation.

Building against the same constraint?

We would rather compare notes with operators than publish at them.