The architectures Thalatta builds

A "product" here is assembled from blocks, not picked off a menu: an agent, a memory layer, and a few bolt-on features. Almost every choice comes back to one anxiety — a company handing its data to an LLM — which splits into two plain questions:

How much of your data does the model see? And whose computer does the agent run on?

Everything below is a way of answering those two.

Block 1 — the Agent (where it lives)

The agent sits on a spectrum from inside your app to a box you fully control:

• Embedded is the simplest thing that works: direct API calls inside a workflow — hand the agent something, get something back. The agent lives in the app.
• Managed means the agent lives outside the app — that's the one trait every managed form shares. Decoupling it is what lets you swap models, scale it, observe it, gate it, and put it where compliance requires without surgery on your application. A managed agent can be off-prem (vendor cloud) or on-prem (your own Kubernetes cluster) — and on-prem is the far end, where the box is yours, so the data, privacy, and audit bar can meet the most stringent governance.
• Two rooms (broker + blind agent) is a separation you add inside a managed agent for the strictest cases: a trusted broker holds the keys, the database, and the business logic; the blind agent runs in a sandbox — an isolated box with no keys, no database, and no path out — and only ever receives an approved packet and returns a result. The sandbox is the untrusted room; it can't leak what it was never given.

What this flow is called, and how it differs from RAG

When a user asks how the glass agent and the OKF fit together, this is the answer. The pattern has a name: Broker + Blind Agent — context, not access. Formal names for a technical buyer: control-plane / data-plane separation, or a trusted-broker / untrusted-agent clean room.

The broker doesn't only gate — it assembles. At the start of a session it pulls two things into one compact packet: the user object (the caller's own record, live from your systems) and the right slice of the memory layer (the OKF briefing the job needs). So the two rooms are also what give the agent its memory — handed in, not reached for.

That assembly is the difference from RAG. A bolt-on retrieval agent goes fishing — it queries a store mid-answer and works from whatever comes back. A glass agent is given, not searching: the relevant memory is selected and assembled before it answers, every session built fresh for this user and this question. Same result a RAG pipeline reaches for, but decided in the trusted room — auditable, scoped, and impossible for the agent to over-reach.

Block 2 — the Memory Layer (how it knows things)

The durable knowledge the agent works from. Pick by how the knowledge is shaped:

• Vector DB — similarity search over chunks; good for large, fuzzy document piles.
• Knowledge graph — entities and their relationships; good when the connections matter as much as the text.
• LLM wiki / OKF — a curated brief in plain markdown + YAML, the flavor we use (after Google's Open Knowledge Format). Good for vetted, human-authored, governable knowledge. (This bundle is one — see about-okf.md.)

Block 3 — Features (bolt-ons)

Concrete capabilities you add to any of the above:

• PII scrubbing — mask sensitive fields before they reach the model.
• Per-session metering — tokens and cost logged per interaction.
• Source trail — every answer ties back to where it came from.
• Action gating — the agent can take only specific, permitted actions; a human owns the line.

What you're actually buying

Governance, compliance, and observability are not blocks — they're the outcomes the blocks produce. PII scrubbing is a mechanism; compliance is the goal it serves. Metering plus a source trail are mechanisms; observability is what you get. The architecture is just how you reach the bar the client's data demands — always appropriate access, not maximum access.