Stack thesis · Loom-first

Why Meridian is Loom-first now.

The architecture always supported this. Kernel was already runtime-neutral. The mismatch was public hierarchy: apps were being centered ahead of the runtime. This page explains the correction.

The original mistake was product hierarchy, not architecture. Kernel already governed runtimes. Loom could already consume Kernel. The part that drifted was public storytelling: first-party apps became louder than the runtime itself.

Kernel

Stays runtime-neutral and governs execution through explicit primitives.

Loom

Becomes the official first-party runtime product and local agent OS bet.

Apps

Remain first-party proof workloads and commercial lanes on top of Loom.

Boundary

Still only claims what the host and repos can verify.

The field is mostly selling breadth or orchestration

That is exactly why Loom cannot hide behind a generic “governance layer” story forever. If Meridian wants to compete with Claw-family runtimes, the runtime itself has to become the front door.

Breadth systems

OpenClaw and OpenHands pull attention through surface area, assistant feel, and broader user-facing ergonomics.

Runtime systems

OpenFang, CrewAI, and LangGraph pull attention through orchestration density, packaging, and framework gravity.

Local agency systems

IronClaw, TEMM1E, and Goose pull attention through memory-heavy local agency and hands-on operator feel.

Kernel and Loom actually match cleanly

Kernel does not need to become the product front door in order to stay central. It stays central by keeping governance independent of any one runtime.

Kernel: Institution, Agent, Authority, Treasury, Court, warrants, sanctions, and proof contracts.

Loom: the first-party runtime that consumes that contract and exposes install, agents, memory, channels, receipts, and local operator UX.

Result: Kernel stays runtime-neutral by architecture while Loom becomes runtime-specific by product strategy.

Why the apps are still useful

Loom-first does not mean “throw away the apps.” It means stop letting the apps define the category. Their job is to prove the runtime under real workflow pressure.

Intelligence

Competitor intelligence remains a first-party workload that proves governed signal intake, drafting, QA, and delivery on Loom.

Trust Ops

Bounded customer-assurance workflows still matter because they prove review queues, evidence state, and approval logic on the same runtime stack.

But the front door moved

Those workflows are now examples of what the runtime can carry. They are no longer the root category Meridian uses to introduce itself.

What Loom has to win on

The moat is not “more features than everyone.” The moat is governed execution that feels complete enough to choose directly.

Must win

01Install speed and first-run clarity.

02Personal agent loop that feels real, not academic.

03Receipts and proof routes that are easier to trust than Claw-style vibes.

04Memory and channel ergonomics good enough for daily use.

Must not do

01Blur back into a generic hosted SaaS story.

02Reduce Loom to a tiny runtime behind app-layer messaging.

03Copy breadth hype before the core runtime loop feels solid.

04Let product positioning drift away from Kernel contract truth.

What Meridian still refuses to fake

Will not fake

01Universal hosted runtime replacement.

02Every future channel and delivery mode already live.

03Winning every runtime category today.

Will claim

01Loom is the official first-party runtime.

02Kernel remains the runtime-neutral governance core.

03First-party apps prove the stack without redefining the stack.

If the hierarchy makes sense, take the shortest next step.

Open Loom Read the runtime compare See the live demo