From Orchestration to Ownership: Tenant-Private Models

Everything Matrix does today is orchestration. An agent calls a third-party model — OpenAI, Anthropic, Gemini — through a configured LlmProvider, and that model is, structurally, just another tool: a callable the runtime composes into a turn alongside an HTTP endpoint, a sandboxed bash, and a knowledge search. That's a good architecture, and orchestration is the right default. The frontier labs ship better general models every quarter; renting them through a BYOK provider means a tenant rides that curve for free, with zero training cost and no GPUs to babysit.

But orchestration has a ceiling, and it's worth naming precisely. A vendor model is trained on the public internet and the vendor's own data mix. It has never seen your operational records — your dispositions, your inspection logs, your domain's particular dialect of a sentence, your sensor readings. On the questions where a generic model is already excellent, renting is unbeatable. On the questions where the answer lives in proprietary data no vendor has, a rented model is permanently guessing, and no amount of prompt engineering closes that gap.

This post is about where the platform goes next: from calling models to owning them. It's a design-direction post, in the same register as our CoALA architecture writing — describing the spine, being honest about what's a shipped feature versus a sequenced bet. The thesis is simple. The highest-value model for a tenant is the one trained on the tenant's own data spine, and the platform that already holds that spine is the natural place to train, host, and govern it.

The thesis: the best model is the one only you could train

Start from what a vendor model structurally cannot do. It cannot know that, in your business, a contact who says one particular phrase converts at three times the base rate. It cannot predict the failure of one of your machines from your maintenance history. It cannot read your instrument's raw output, because it has never seen that instrument. These are not gaps you close with a bigger context window or a cleverer system prompt — the information was never in the training set, and it never will be, because it's yours.

That inverts the usual framing. The question isn't "which vendor model is best?" — the honest answer is usually "whichever is current, rented." The question is "which models can only you build?" Those are the ones with a moat, because the moat is the training data, and the training data is a byproduct of running your business on the platform. Orchestration rents intelligence. Ownership compounds it.

The architecture: the data spine becomes labelled training data

Here's the part that makes this a platform feature rather than a vague ambition. Matrix already holds the asset that training needs most and that most teams lack: a clean, structured, multi-tenant data spine.

Every domain object on the platform — every Session, Message, Lead, Memory, Knowledge chunk, Task run — is an EntityNode row in one Neo4j graph, described by an EntityType schema. We've written about why that generic entity model is powerful for application development: a new field is a PropertyDefinition edit, not a fork. The same genericity is exactly what a training pipeline wants. The schema is the feature dictionary. The rows are the examples. A disposition field on a Lead is a label. A Session transcript joined to its outcome is a (prompt, completion, reward) triple waiting to be exported.

So the architecture has four moving parts, and three of the four already exist:

1. The data spine (shipped). The entity/knowledge graph, tenant-partitioned by orgId on every row. This is the raw material — and crucially, it's already labelled by the operational outcomes the platform records.
2. An export/labelling layer (direction). A tenant defines a training view over their own entities — "every closed Lead with its final disposition," "every transcript tagged resolved/unresolved" — as a query over the same EntityManager read path that already enforces tenancy and row/field RBAC. You cannot accidentally pull another tenant's rows into your training set, because the export rides the exact authorization boundary every other read does.
3. A pluggable training backend (direction). Fine-tuning, distillation, and classical model fitting are jobs — they take a dataset and a recipe and emit weights. The platform doesn't need to be a training framework any more than it needs to be an LLM; it needs a clean seam, the way LlmProvider is a seam over chat backends. A vendor fine-tuning API, a managed training service, or a tenant's own GPU cluster all sit behind the same interface.
4. The trained model registered back as a Tool (direction). This is the keystone. A finished model is not a special new primitive. It's registered as another callable — a Tool with an INTERNAL or HTTP transport — and composed into an agent through the same AgentToolSurface path that already unifies HTTP tools, MCP servers, skills, knowledge, and built-ins. From the agent's perspective, "ask our churn model" sits next to "search the knowledge base" with no special-casing. It inherits tenant isolation and RBAC wholesale, because it's just another row behind the same enforcement.

That fourth point is why this fits Matrix rather than bolting onto it. We argued in the four-primitives post that Tool, Skill, Knowledge, and the built-in toolbox all collapse into one tool surface. A tenant-private model is a fifth thing that collapses into the same surface. No new agent-facing concept; a trained model is a Tool whose implementation happens to be weights the tenant owns.

# A registered tenant-private model is just a Tool the agent can call
{
  "entityType": "Tool",
  "key": "predict_churn",
  "transport": "INTERNAL",
  "actionType": "RETRIEVAL",
  "description": "Score a contact's 30-day churn risk from operational history.",
  "modelRef": "tenant-private/churn-v3"   // BYO-weights, tenant-hosted
}

BYO-weights and tenant-hosting matter here too. A tenant who trains elsewhere, or who has a model they already own, should be able to register the weights and host inference under their own boundary — the platform governs access to the model the same way it governs access to a Lead, regardless of where the GPUs live.

Three model classes a tenant actually wants

"Train your own model" is too vague to build against. In practice a platform tenant wants three distinct classes of model, and they have different data shapes, different backends, and different risk profiles.

1. Fine-tuned or distilled LLMs for the domain's language. Your domain has a dialect — its terms of art, its abbreviations, the way your operators phrase a recommendation, the structure your outputs should take. A general model approximates it; a model fine-tuned on your own transcripts and documents speaks it, and a distilled small model can speak it cheaply enough to run on the hot path. The training data here is exactly what the platform logs: Sessions, Messages, Knowledge corpora. This is the most natural first class because the data already exists and the fine-tuning backends are mature.

2. Tabular predictors over operational records. This is the class teams underestimate, and it's often the highest ROI. Most valuable business predictions — will this lead convert, will this account churn, is this transaction anomalous, what's the expected value of this action — are tabular problems, not language problems. They're won by gradient-boosted trees over structured features, not by a transformer. And the platform's entity graph is a feature store: every scalar property on every row, already indexed. A tabular predictor trained on a tenant's own Lead and Session rows, then registered as a predict_* tool, gives agents a calibrated number where today they have a vibe.

3. Perception models over the tenant's own images, audio, or spectra. Some tenants generate proprietary sensor data — photographs, audio, spectra, scans — that no foundation model has ever seen, because the instrument or the subject is specific to them. A perception model trained on that data, exposed as an analyze_* tool, lets an agent reason over a modality the language model has no access to. This class has the deepest moat (the data is genuinely unique) and the highest bar (it needs real labels and real validation), which is the perfect transition to the honest part.

The honest sequencing: what separates this from hype

Design-direction posts earn trust by being candid about the order things have to happen in. There are three hard constraints, and any vendor who skips them is selling you a demo.

You cannot train without data. Cold-start is real. Day one, a new tenant has an empty graph. There is nothing to fine-tune on, nothing to fit a predictor to. So the honest sequence is orchestrate first, train later: rent a vendor model, run the business on the platform, and let the data spine accumulate as a byproduct of normal operation. Training is a capability that switches on once there's enough labelled history to justify it — not a day-one feature. Pretending otherwise produces a model fit to noise. The platform's job early on is to make sure the data being logged is clean, structured, and labelled by outcomes, so that when the volume is there, the training set is a query rather than a six-month data-cleaning project.

Passively-logged operational data is confounded. Correlation is not optimization. This is the subtle one, and it's where most "AI optimizes your business" claims quietly fall apart. A predictor trained on historical operational logs learns correlation under your existing policy. It can tell you the cases that tend to convert; it cannot, from passive data alone, tell you what action would cause more of them to convert — because in the logs, the action and the context that triggered it are tangled together. Breaking that confound requires a Design-of-Experiments program: deliberately randomized interventions (A/B by construction, or contextual bandits) that produce causal signal a passive log never can. So the sequence is: predict from observational data first (genuinely useful), then earn the right to claim optimization by running experiments. A platform that conflates "we logged it" with "we can optimize it" is overselling. We'd rather ship the predictor honestly and build the DoE layer deliberately.

Any model feeding a regulated decision needs validation and a human in the loop. A model that suggests a phrasing is low-stakes. A model that feeds a decision with legal, financial, or safety consequences is not, and it doesn't matter how good the AUC looks. That class needs held-out validation, calibration, drift monitoring, an audit trail, and — for the consequential call — a human who reviews and approves. This is the same posture our access-control and procedural-self-editing work already takes: the agent proposes, a human disposes, and every step is on the record. A tenant-private model that touches a regulated decision is governed the same way — it's a tool whose output is a recommendation until a human with the right grant signs off.

None of these three is a reason not to build this. They're the reason to build it in the right order — orchestrate, accumulate, predict, experiment, validate — instead of leading with a slide that says "your AI, trained on your data" over an empty database.

Why this matters: from thin wrapper to compounding moat

There's a critique of agent platforms that's fair more often than not: they're a thin wrapper around someone else's model. Swap the wrapper, keep the model, lose nothing. If all a platform does is forward prompts to OpenAI, the critique lands.

Tenant-private models are the structural answer. Once a tenant's data spine becomes the training corpus for models only that tenant could build — models registered back into the same governed tool surface their agents already use — the platform stops being a wrapper and becomes the place where two assets compound together. Every interaction adds a labelled row. Every labelled row improves the next model. Every model makes the agents better, which produces more and cleaner interactions. The data and the models reinforce each other, and both are governed by the same multi-tenancy and RBAC that govern everything else on the platform. That loop is not portable. It doesn't swap out with the wrapper, because it isn't the wrapper — it's the tenant's own accumulated data and the models fit to it.

That's the category line we're drawing. Orchestration is the right default and stays the default forever for the long tail of general tasks. But the destination is ownership: the platform as the place where a tenant's proprietary data becomes their proprietary models, exposed to their agents as tools, behind the same boundary as the rest of their data. Renting intelligence gets you to parity. Owning it is the only thing that compounds.

Keep reading

• Everything Is a Node: The Generic Entity Model — the data spine that becomes the training corpus.
• Four Primitives: Tool, Skill, Knowledge, Toolbox — the composition path a trained model plugs into as just another tool.
• Row, Field, Type: Security for Agents — the enforcement boundary the export layer and the registered model both inherit.

---

Where this is today: orchestration ships; the data spine ships; the export-to-training, pluggable training backends, and model-as-tool registration are sequenced work, deliberately gated behind the cold-start, confounding, and validation constraints above. We'd rather name the order than oversell the destination.