Twindexers EKA: What Happens When an AI Assistant Has to Understand an Enterprise?

Once Metrolane — the synthetic enterprise behind Twindexers — started becoming a realistic company, I wanted to see what I could actually build on top of it.

Not another chatbot demo with a few PDFs or one database, but LLM-driven solutions and agents working against something that behaves much more like an enterprise — multiple systems, documents, identities, access rules, provenance, and deliberately imperfect cross-system states.

EKA — Enterprise Knowledge Assistant — is one of the first.

The enterprise underneath it is alive

Metrolane is not meant to remain a frozen collection of realistic tables and documents. The larger idea is a living synthetic company whose systems, transactions, documents and operational states continue to move.

That makes the solutions on top much more interesting. The same question can have a different answer as the enterprise changes, systems can temporarily disagree, and something that is absent today may appear tomorrow. The assistant has to work in the enterprise as it evolves, not just search a prepared dataset.

Enterprise truth is not one thing

EKA has to reason across canonical enterprise data, source-system records, documents, identity resolution, operational links, provenance and access rules.

Those authorities are related, but they are not interchangeable. A CRM record should not silently become canonical truth, a policy document is not the same thing as an operational decision, and two source records representing the same customer is different from one business object leading to another.

The assistant is not allowed to flatten every source into one truth.

Evidence before explanation

One of my favourite test cases is a Closed Won CRM opportunity with no authoritative ERP continuation. A weak assistant might confidently say the integration failed.

EKA keeps the claim narrower: the opportunity is Closed Won, the downstream ERP continuation is absent, and the cause is not established. Missing evidence should not become a confident explanation.

That principle runs through the project: distinguish fact, derived result, absence, unsupported inference and unavailable information.

Keep deterministic work deterministic

If someone asks, “What do we owe this supplier, across how many invoices?”, I do not want the language model doing arithmetic from prose.

The runtime resolves the enterprise object, performs the governed query and uses deterministic operations such as COUNT and SUM. The model interprets the request and explains the answer; enterprise truth and arithmetic stay outside the prompt.

Behind the conversation is a governed runtime that interprets the question, resolves references, plans approved reads, retrieves permitted evidence and then synthesizes the response.

From chat to an enterprise workspace

The next layer is the Agent Experience: a full conversational Workspace and a contextual Sidecar inside Twindexers.

The Workspace supports persistent conversations and richer answers. The Sidecar lets someone ask EKA about the organization, opportunity, warranty claim or document they are already viewing without copying identifiers around.

Answers can include enterprise record cards, tables, deterministic calculations, evidence, result states and follow-up questions rather than only prose. The model chooses meaning and content; Twindexers chooses the UI.

Where it is now

The Metrolane enterprise foundation is implemented, and the headless EKA runtime is built and validated against real synthetic-enterprise questions. The conversational Workspace and contextual Sidecar are now being implemented on top of that runtime.

I deliberately built the runtime first so grounding, authority, access and evidence could be tested independently of the interface.

One enterprise, many agents

EKA is only one solution. Now that Metrolane exists, I want to keep building realistic LLM-driven solutions and agents around finance, operations, HR, compliance, investigations, monitoring, enterprise search and other scenarios — all against the same underlying company.

Instead of building a fresh demo world for every agent, the agents have to learn to work in the same enterprise as it changes.

That is one of the reasons I wanted to build the synthetic enterprise first.

EKA is less about giving a chatbot access to enterprise data and more about exploring how an AI agent should behave when enterprise truth is distributed, governed, incomplete, and continuously changing.