How we actually build this.
There is no single model or library that makes a system intelligent. What we build is a stack: data engineering, distributed systems, spatial computing, knowledge systems, and reasoning, with a foundation model doing one job inside it — not standing in for the rest.
The same four layers, one level deeper.
Home covers this in brief. This is what each layer actually has to contend with.
Real operational data rarely arrives clean. Schemas drift between releases, records show up partial, and the same entity lives under different names in different systems of record. This layer resolves those disagreements before anything downstream is asked to reason over them.
A decision needs to know what happened before it — the session, the account, the last five cases like this one. This layer keeps session state and case history, and resolves entities across time so "this customer" and "that account" stay the same thing as records accumulate.
Learned models are good at pattern-matching and bad at guaranteeing a rule. This layer combines both: a model proposes, explicit constraints and rules bound what it is allowed to conclude, so the output is traceable back to a reason rather than a probability alone.
Committing to an action means keeping a record of the version of the system, the evidence, and the logic that produced it — with the ability to roll it back if the world proves it wrong. Without that trail, a decision is a guess with better production values.
AI is one component among several.
Distributed systems architecture
Deciding how state, computation, and failure are distributed across services — before deciding what any single service does.
Spatial computing
Turning position, geometry, and movement into structured facts a system can query and reason over, not just coordinates on a map.
Knowledge systems & graphs
Modeling entities and their relationships as a graph that stays consistent as new information arrives and old information ages out.
Reasoning & inference
Choosing where a learned model helps and where an explicit rule or constraint should bound it, case by case.
Data engineering & integration
Getting the truth out of the systems that already hold it, reliably, without asking the business to change how it operates.
Interface & oversight design
Giving the people accountable for a decision a clear view into what the system saw and concluded, and a way to intervene.
A foundation model is a small part of a working system.
Most of the effort in a system that reasons well goes into the parts that never show up in a model card: getting the data trustworthy, keeping context consistent across sessions, and building an audit trail that holds up when someone asks why a decision was made. The model is the part that generalizes. Everything around it is the part that makes the generalization safe to act on.
That is why we start engagements with architecture and data, not with model selection. Picking a model is usually a week of work. Building the system that makes its output trustworthy in production is the rest of the project.