Every AI Agent is only as Honest as the Box it runs on
Most Agentic AI is a large language model wrapped in a to-do list. The model itself is an autoregressive probability distribution: it predicts which word plausibly follows the last one. Nothing inside it represents your project. There is no variable for "is this milestone actually late," no field for "was this invoice paid," no memory of what it did an hour ago. It is fluent. It is not grounded.
Glass Box
No world model
A transformer computes the likelihood of the next token given the tokens before it. That is a model of language, not a model of your schedule, your budget, or your supply chain. When it answers a question about project state, it is producing plausible text, not consulting a fact.
Hallucination is the default
Because the model is trained to maximize plausibility, not truth, it has no internal mechanism for telling a true claim from a fluent one. An ungrounded answer about cost drift or delivery risk is not a rare failure, it is the expected behavior of a system with no external source of truth.
You cannot see why
A black-box model gives you an output with no visible path back to evidence. If it is wrong, you find out after the fact, from the consequence, not from the reasoning. In a capital project, that consequence can be a missed deadline or a budget already spent.
An LLM is a model of language. Your business runs on facts.
A black-box chatbot is one bad guess. A black-box agent is twenty of them, chained.
A chatbot makes one opaque call and a human reads the answer before acting on it. An agent does not stop there: it plans, calls tools, reads results, and acts again, step after step, often without a human checking each one. When every step is opaque, the failure does not just repeat, it compounds, silently.
On a capital project, that twenty-step chain looks like: read a progress report, extract a completion percentage, cross-reference it against the schedule baseline, recompute float, flag or clear a milestone, roll the change into a cost forecast. One misread number early in that chain does not stay contained. It propagates into every downstream number that depends on it, and because the box is black, nothing flags which step actually lied.
This is not a hypothetical risk. MIT researchers found that 95 percent of enterprise generative AI pilots deliver no measurable business impact, and Gartner projects that over 40 percent of agentic AI projects will be cancelled before they reach production, for the same underlying reason: unverifiable behavior does not survive an audit.
Chain twenty steps at 95 percent reliability each, and only one run in three finishes correct. That's not pessimism, it's multiplication.
The fix is not a smarter model. It is a system you can see through.
A glass-box architecture keeps the language model exactly where it is useful, as the interface, and puts three things underneath it that a black box does not have: grounding, verification, and a visible path from claim to source.
Grounding
Every claim the system makes resolves to a real event in a knowledge graph: a specific field report, a specific timestamped entry, a specific source. Not the model's recollection of something it read, an actual traceable fact.
Verification
Before any step executes, it is checked against ground truth by a rules layer, not asked nicely to be correct. An error is caught at the exact step where it occurred, and the system corrects, retries, or escalates to a person with full context.
Inspectability
Every answer is a path you can walk backwards, layer by layer, from the natural-language summary down to the raw feed that produced it. Nothing about the reasoning is hidden from you.
Below is that glass box, opened up, layer by layer, L0 to L6. It is not a decorative diagram. It is the architecture itself, opened for inspection.
We don't ask the model to be right. We make wrongness detectable.
The ontology, built live
Every shape below comes straight from the frozen ontology the engines run on, three clusters, 14 classes, 17 relations, with real project records loaded onto it and one append-only table holding every fact. The schema builds first, then the data snaps into place, then each story walks the exact same graph.
This is the live data model the whole system runs on: a graph of 14 classes and 17 relations, holding real project records. Every answer it gives is a different walk across this one graph. Here is what each of the five questions asks, what it proves, and how to read the shorthand, everything traces back to a real record.
| prj_… | a project. prj_core = Core Banking Modernization, prj_aml = AML upgrade. |
| m_… | a milestone. m_204 = Payments Integration Go-Live. |
| t_… | a task. t_130 = Sanctions Screening on the AML project. |
| p_… | a person. p_09 = Ahmed, p_14 = Sarah, p_20 / p_21 = contractors. |
| sk_… | a skill. sk_int = Payment Gateway Integration, the scarce one. |
| a_… | an approval gate. a_88 = Vendor Security Gate. |
| r_… | a risk. r_12 = vendor delivery capacity strained. |
| cr_… | a cost rate. cr_int_contractor = QAR 260/hr. |
| valid_time | when a fact became true in the world. |
| tx_time | when the system actually learned it. The two never mix. |
Every instance above resolves down to rows here. Nothing is ever overwritten, only appended. valid_time records when a fact became true in the world, tx_time records when the system learned it, and the proof of an honest history lives in the one row where those two clocks disagree.
Seven layers between a question and a fact
Seven layers, one rule: truth flows up from the feeds, language sits on top, and provenance wraps every layer in between. Toggle between a guided tour of each layer's deliberately minimal v0 tech choice, and a live walk of any of the five stories' actual data, each one a different real path traced through every layer that computes it.
Project Intelligence gives engineering and capital project owners a single, full-stack view of a project's actual state, surfacing schedule risk, cost drift, and delivery signals from raw field data up through natural-language answers, with every claim traceable back to the source event that produced it. Built on an open source, self-hostable stack, so the system runs entirely inside your own infrastructure rather than a vendor's cloud. The interactive reference below is a real architecture walkthrough, not a mockup: every layer, tool, and data path is specified to run exactly as shown, on infrastructure you control.
Story A: live trace
The production stack, end to end
Every tool below is open source and self-hostable: sovereignty by construction, not by promise. This is not the deliberately minimal v0 shortlist from the layer cards above, it is the fuller production stack, including the event sourcing and streaming infrastructure a full deployment would actually run. Click any node for what it does and how you would run it. Choose a story above to watch that story's own path physically traverse the pipeline, each of the five stories lights a different, real route through the same tools.
Currently showing: Story A. When two consecutive lit nodes show no connecting line between them, they are parallel, independent sources converging at the next node, not a broken traversal.
Delivery roadmap
All five stories, A through E, are fully specified: the claim, the entities, the engine path, the cross-feed reconciliation, the distractor, and the fingerprint, all written and internally consistent for every story. The build method is deliberately depth-first: implement one story, delay forensics, end to end until its claim is computable twice with identical output, stress test it, and only then expand to the remaining four in a planned order. No engine code is written for a story until the one before it has run and survived that test — breadth is earned, never assumed.