---
title: The Architectures Thalatta Builds (agents × memory, and where they run)
summary: Every product is assembled from blocks — an Agent (embedded or managed, and where it's hosted), a Memory Layer (vector, graph, or OKF wiki), and bolt-on features. The lens behind every choice — how much of your data the model sees, and whose computer the agent runs on. Includes the agent matrix a newcomer can follow.
tags: [architecture, architectures, agents, memory-layer, hosting, governance, broker, blind-agent]
updated: 2026-06-26
source: ai-sandbox/first-ai-agent-sandbox/AGENT-ARCHITECTURES.md, content/services.md, content/glass.md
---

# 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** | **Managed — off-prem** | **Managed — on-prem (your K8s)** |
|---|---|---|---|
| Where the agent runs | inside your app | vendor cloud (Anthropic / Gemini / OpenAI) | a cluster **you** control |
| Who controls the box | you, but tangled with the app | the vendor | you, fully |
| Data leaves your walls? | yes, to the model API | yes | **no** — except the one model call you choose to make |
| Swap models / scale on its own | hard (welded to the app) | easy | easy |
| Audit & privacy ceiling | limited | medium | **highest** |
| Best when | quick workflow, low-sensitivity data | speed, no infra to run | regulated data, strict privacy/audit |

- **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](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.**