Architecture

Status: design / direction. This page describes where Glimmer is heading — each study as a tenant with its own agent, able to request compute. The sections marked Today are live; the rest is the target, to be built incrementally. It mirrors the shimmer-saas (opens in a new tab) multi-tenant pattern, adapted for science.

Today: one box, shared services

The live site is a single Hetzner box serving static HTML/CSS/JS behind nginx, with three stdlib-Python services:

• glimmer-chat (explain_proxy.py) — the Ask-Glimmer proxy to OpenRouter. One process serves all chat, routing by request: scope:"site" → the public site agent, project:"<id>" → a study agent, else the notebook tutor. See Agents.
• glimmer-auth (auth_gate.py) — WAAP sign-in + SQLite RBAC; nginx auth_request gates /explore/<study>/(graph.json|papers.json|pdfs/|brains-data/).
• glimmer-ops (ops_hud.py) — host vitals, deploys, and the Hetzner cost/compute panel.

The canonical project manifest (site/explore/projects.json) feeds the site, the public agent, and these docs.

Target: each study is a tenant with its own agent

In the shimmer-saas model, every tenant gets its own agent container, data volume, and identity (SOUL.md), with shared infrastructure (routing, DB, LLM proxy) underneath. Glimmer adopts the same shape, where a study's knowledge graph is its agent's knowledge base:

• Per-study agent. A dedicated agent process per study, grounded in that study's graph (methods, experiments, derivatives, findings) — not just the public summary. Its persona/system prompt is a per-study SOUL.md-style document ("you are the analysis agent for the ADS cohort, N≈140…").
• Capabilities, not a monolith. A capability manifest (à la shimmer-saas capabilities.yaml) declares what each study agent can do — answer, run an analysis, summarize a derivative, propose an experiment.
• Provisioning. A control plane stands up a study agent the way provision-tenant.sh stands up a tenant: seed the KB from the study's repo, inject identity + capabilities, start the process.
• The seam already exists. The public-vs-study agent split (today, in one process) is exactly the boundary along which study agents become separate tenants.

Requesting compute

Science needs burst compute (preprocessing, model fits). The direction:

• A compute-request flow. A study (or its agent, with approval) requests a node; the platform provisions it via the hcloud / provision-node.sh pattern, runs the job, and records cost + provenance.
• Cost & provenance in view. The per-study Compute HUD (/explore/<study>/compute) already renders live nodes, accruing €/hr, historical jobs (wall-time × cost), and devops provenance from compute-state.json, backed by ops_hud.hetzner().
• Tracked, not hidden. Every job links back to the method node and the code that ran it — the same provenance contract as any other derivative.

Why this shape

• Isolation. A study's data and agent are bounded; the public agent only ever holds the public catalog.
• Scale. Many studies share one (or a few) boxes; heavy studies can move to dedicated nodes — the shimmer-saas "sovereign tier" idea.
• Continuity with the science. Provenance, reproducibility, and the knowledge graph are the throughline from a single result up to the whole multi-tenant platform.