Stack
How the stack works together
They are not three parallel projects. They are one thesis expressed across the product, runtime, and data layer.
If you read LinX, xpod, and drizzle-solid as three flat projects, you miss what the company is actually trying to make real.
We are not saying, “here are three things we happen to make.”
We are saying: if AI is supposed to collaborate over time, the product, the runtime, and the data layer all have to line up.
Why LinX cannot be missing
LinX is the product layer users see first.
It brings conversation, memory, files, and follow-up into one product surface so people can actually feel what it means for the thread of work not to break.
Without LinX, the whole thing easily collapses into a bundle of technical capabilities. People do not see why those foundations matter, and they do not know where to start.
Why xpod cannot be missing
xpod is the layer that makes the system real inside a boundary.
It carries identity, storage, permissions, APIs, and agent runtime so the system does not have to depend forever on somebody else’s default platform assumptions.
Without xpod, LinX may still work as a product, but it drifts back toward a normal platform shape. You can use it, but you have much less say over where it runs, how permissions work, and how close it stays to your own data.
Why drizzle-solid cannot be missing
drizzle-solid is the layer that keeps bringing more data and workflows in.
The system cannot stay forever at the level of chat history. It eventually needs to understand more objects, states, relationships, and business actions.
Without drizzle-solid, every new source and workflow is more likely to be added through ad hoc stitching. The system becomes much harder to extend over time.
The layers are not parallel. They are progressive.
The relationship is closer to a progression:
LinXlets you start using itxpodlets you decide where and how it runsdrizzle-solidlets you keep connecting more data and workflows
Each layer answers a different question, but they all serve the same goal: letting AI collaborate over a durable line of work.
Why they must be understood together
If you only look at the product layer, it seems like a fuller AI client.
If you only look at the runtime, it seems like a deployment project.
If you only look at the data layer, it seems like a pod-oriented developer library.
Only when you line them up do you see the full thesis:
- make the line of work real in the product
- let it run inside boundaries users can shape
- keep letting more data and workflows join that same system
That is the system Weiming Intelligence is actually building.