insika 0.3.0 → 0.8.0

data/docs/ARCHITECTURE.md

@@ -1,7 +1,7 @@
 ---
 title: Architecture
-parent: Understand the idea
-nav_order: 2
+parent: Start here
+nav_order: 3
 permalink: /architecture/
 ---
 
@@ -319,6 +319,7 @@ validator as the after-task hook, so both roots enforce content safety identical
 | Tools (data/manifest/MCP) | `lib/insika/tool_definition.rb`, `tool_manifest.rb`, `mcp_tool_ingestor.rb` |
 | Plugin loading (boot) | `lib/insika/plugin.rb`, `lib/insika/plugin/loader.rb` |
 | Refinement (traffic → report) | `lib/insika/refinement/*`, `lib/insika/refinement_store.rb` |
+| Post-turn learning (facts, skills, knowledge — extracted from finished conversations) | `lib/insika/distill.rb`, `lib/insika/harvest.rb`, `lib/insika/knowledge.rb`, `lib/insika/knowledge_store.rb`; the per-turn hook lives in `Executor#persist_turn`, next to `finalize_delegation` |
 | Evals (cases, judges, gate) | `lib/insika/evals/*`, `lib/insika/golden_store.rb`; `evals/run.rb` is the CLI |
 | HTTP/SSE surface | `lib/insika/server/*` |
 

data/docs/ARTIFACTS.md

@@ -0,0 +1,137 @@
+---
+title: Artifacts
+parent: Operate
+nav_order: 3
+permalink: /artifacts/
+---
+
+# Artifacts — a report the agent can hand you a URL to
+
+A channel message is ephemeral, unformatted and capped. A scheduled report turn
+(see [Schedules](SCHEDULING.md)) produces something no message can carry: a page
+— tables, sections, inline charts. An **artifact** is that page as a thing that
+exists afterwards: listable, linkable, and — because it carries customer PII —
+deletable on the same terms as everything else the engine stores.
+
+Deliberately small: a store, a tool, a route. Not a CMS.
+
+## The `save_artifact` tool
+
+A registry tool, allowlisted per agent like every tool — **the allowlist IS the
+switch**:
+
+```ruby
+agent = Insika.agent("reporter") do
+  instructions "…"
+  tools_allow %w[save_artifact]   # without this, the tool is not even offered
+end
+```
+
+The agent hands in `title` + `content` (default mime `text/html`; also
+`text/markdown` and `image/svg+xml`) and gets the URL back, which it can include
+in a channel message ("today's report: <url>"). When a signing key is
+configured (below), the result also carries a `signed_url` that expires.
+
+```jsonc
+{ "id": "…", "url": "https://…/studio/artifacts/<id>/content",
+  "signed_url": "https://…/studio/artifacts/s/<id>?exp=…&sig=…" }   // only with a key
+```
+
+The tenant binding is **inherited, never chosen**: an artifact belongs to the
+tenant of the agent that saved it — a binding of the tool instance, never a
+parameter the model types. Store A's report can never appear in, or be linked
+from, store B.
+
+## Serving
+
+- `GET /studio/artifacts` — the Studio's per-agent list (the listing IS the
+  history; no versioning — one report per run).
+- `GET /studio/artifacts/:id` — the preview page, rendered **inside a sandboxed
+  iframe** (no scripts, no same-origin, no forms).
+- `GET /studio/artifacts/:id/content` — the raw page (authenticated).
+- `GET /studio/artifacts/s/:id?exp=…&sig=…` — the **signed link**: the only
+  artifact route that works without a Studio session. HMAC-SHA256 over
+  `(id, expiry)` with `INSIKA_ARTIFACT_SIGNING_KEY`, verified in constant time.
+  Expired or bad signatures **404 (never 403 — no oracle)**. Rotating the key
+  invalidates every outstanding link — the documented behavior, not a bug.
+  Without `INSIKA_ARTIFACT_SIGNING_KEY` there is no signed surface at all.
+
+**Artifact content is untrusted.** It is LLM output. Both content routes send:
+
+```http
+Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src data:
+X-Content-Type-Options: nosniff
+```
+
+No script, no external fetch, no forms. The model writes HTML with **inline
+SVG** for charts — that is a skill instruction (palette, tables, pure-SVG bars),
+not engine code. A "real" charting need is a plugin.
+
+## Reasoning effort on a report turn
+
+A report turn is not one shape of work — it plans, then it mines, then it
+writes. `thinking` is one value per agent for the whole turn, so an agent set to
+`high` pays deliberation on every one of the 30–50 tool calls a real report
+makes, and that is where the 300 s turn timeout gets spent.
+
+Split the phases across agents instead, which the engine already supports today:
+
+```ruby
+Insika.system do
+  # The miners: one narrow question each, no judgement to make.
+  agent("sales_miner") do
+    model "deepseek-v4-flash"
+    params thinking: "low"
+    tools %w[query_sales]
+    instructions "Answer ONE question about sales from the store data. Numbers, no prose."
+  end
+
+  # The orchestrator: it plans the report and writes it. This is the turn
+  # that deserves the deliberation.
+  agent("reporter") do
+    model "deepseek-v4-flash"
+    params thinking: "high"
+    tools %w[save_artifact]
+    subagents "sales_miner"
+    instructions "Plan the report, call spawn_subagents ONCE for every number you need, then write the page and save_artifact it."
+  end
+end
+```
+
+Two things make this work: a child inherits the *environment* (model, thinking)
+only as a **default**, so its own `params thinking:` wins; and `spawn_subagents`
+runs the children in parallel, so wall-clock is the slowest miner rather than
+the sum. Each child also mines in its own isolated context, which is what keeps
+the orchestrator's context from filling with raw rows.
+
+Measure it before reaching for anything cleverer: the numbers that matter are
+the turn's wall-clock, the timeout rate, and the judge score on the same report.
+Per-phase effort *inside* a single turn is a real idea, but it is only worth
+building once this recipe is shown not to be enough.
+
+## Limits and retention
+
+- **Size cap** — `INSIKA_ARTIFACT_MAX_BYTES` (default 1 MB): an artifact is a
+  page, not an attachment. The mime allowlist is `text/html`, `text/markdown`,
+  `image/svg+xml`; no binaries, no uploads.
+- **Expiry** — the settings key `artifact_ttl_days` (Integer days; absent = OFF)
+  ages artifacts out on the retention sweep's own daily pass, **independent of
+  `retention_days`**: a deployment that keeps its conversations forever must
+  still expire the reports. This is the guarantee that PII inside a report
+  expires — the honest reach, because no reader can see inside the opaque HTML.
+
+## Privacy
+
+- `delete_tenant_data` deletes the tenant's artifacts (the tenant binding is
+  the isolation boundary).
+- `forget_customer` **cannot** know which artifacts mention a customer (content
+  is opaque HTML), so per-customer redaction inside a report is not pretended to
+  exist; the `artifact_ttl_days` knob is the guarantee that a report's PII
+  expires.
+
+## See also
+
+- [Schedules](SCHEDULING.md) — the recurring turns whose output lands here.
+- [Tools](TOOLS.md) — how a tool enters the per-agent allowlist.
+- [`examples/scheduled-report/`](https://github.com/guizaols/insika/tree/main/examples/scheduled-report/)
+  — schedule + skill + data tool + artifact, tenant-bound, end to end.

data/docs/BENCHMARK.md

@@ -1,7 +1,7 @@
 ---
 title: Benchmark
-parent: Operate & prove it
-nav_order: 2
+parent: Operate
+nav_order: 6
 permalink: /benchmark/
 ---
 

data/docs/CHANNELS.md

@@ -1,7 +1,7 @@
 ---
 title: Channels
-parent: Build an agent
-nav_order: 6
+parent: Integrate
+nav_order: 2
 permalink: /channels/
 ---
 
@@ -176,14 +176,14 @@ again.
 ## Relay or the drop-in API?
 
 If you already own your messaging platform, you can reach the engine two ways: the
-drop-in [`POST /v1/responses`](/architecture/) — you hold an SSE connection for the
+drop-in [`POST /v1/responses`](ARCHITECTURE.md) — you hold an SSE connection for the
 whole turn and read the answer off it — or the relay, where the engine acks in
 milliseconds and POSTs the answer to you when it exists.
 
 The instinct is that streaming gets the customer their reply sooner, and that the
 relay trades that away. **For the default relay it does not, and the reason is
 structural:** the engine publishes `:content` as the ANSWER, whole, after the
-turn's hooks ([what crosses the edge](/architecture/#what-crosses-the-edge)).
+turn's hooks ([what crosses the edge](ARCHITECTURE.md#what-crosses-the-edge)).
 During the turn the stream carries tool activity; the text arrives in one piece at
 the end. Measured on a real store agent, the text frames span **0 ms** — there is
 nothing to deliver progressively. That is the `:at_end` fact, true of `/v1/responses`
@@ -204,7 +204,7 @@ That last row is the one that cannot be had the other way. `/v1/responses` answe
 the request it was given, so a message that arrives while a turn is running is a
 second turn — the engine has no way to tell you "this joined the previous one". The
 relay's `merged` / `steered` acks exist precisely to say that, which is why
-[the inbound queue](/agents/#queue_mode--when-a-message-arrives-while-the-agent-is-busy)
+[the inbound queue](AGENTS.md#queue_mode--when-a-message-arrives-while-the-agent-is-busy)
 is only reachable from here.
 
 **Measured, so you can judge it rather than take our word:** same agent, same
@@ -282,7 +282,7 @@ answers, and **they are four different facts**:
 answer two or three times.** That is the one contract mistake that is visible to
 the end user, so it is worth a line of code: only deliver for a `202`.
 
-`merged` and `steered` come from the [inbound queue](/agents/#queue_mode--when-a-message-arrives-while-the-agent-is-busy)
+`merged` and `steered` come from the [inbound queue](AGENTS.md#queue_mode--when-a-message-arrives-while-the-agent-is-busy)
 (`limits[:queue_mode]`). They only ever occur if you turned that on for the agent;
 with the default `followup` you will only see `202` and `duplicate`.
 
@@ -312,7 +312,7 @@ short backoff, and then the delivery is marked `failed` and stops.
 `content` is the turn's **answer** — one message, whole. The model's narration on
 the way to an answer ("vou verificar o cardápio…") does not come through here; it
 stays internal unless the agent opts in. That contract is
-[the edge contract](/architecture/#what-crosses-the-edge), and it is why you can
+[the edge contract](ARCHITECTURE.md#what-crosses-the-edge), and it is why you can
 forward `content` straight to the customer.
 
 ### Delivery policy
@@ -379,7 +379,7 @@ your side: you already have the customer's conversation, and `GET /v1/tasks/:id`
 tells you the turn's terminal state.
 
 A turn that **failed** delivers nothing — an error string is not an answer. Watch
-`GET /v1/tasks/:id` or the [event stream](/observability/) for those.
+`GET /v1/tasks/:id` or the [event stream](OBSERVABILITY.md) for those.
 
 ## Setting up the relay
 
@@ -397,7 +397,7 @@ INSIKA_RELAY_DELIVERY=progressive               # optional; "at_end" (the defaul
 without a credential — a public inbound route with an LLM behind it is a money
 faucet, so it fails closed by construction.
 
-The delivery POST goes through the same [egress guard](/security/#egress-the-ssrf-boundary) as
+The delivery POST goes through the same [egress guard](SECURITY.md#egress-the-ssrf-boundary) as
 data-tools: **https only**, and private/loopback destinations blocked. For local
 development, where your consumer is on `localhost`:
 
@@ -415,7 +415,7 @@ A runnable consumer in ~40 lines lives in
 
 ## Shadow mode
 
-Shadow mode (RFC-0025) lets one channel run every turn **end to end and deliver
+Shadow mode lets one channel run every turn **end to end and deliver
 nothing** — the experiment that answers "can we replace the incumbent?" before
 any customer is handed over. The incumbent keeps answering; the engine records
 what it *would* have answered, and the two replies are judged pairwise against a
@@ -470,7 +470,7 @@ redirect its own conversation.
 ## Writing your own channel
 
 A channel is a plain object — no base class. Register it from a plugin
-(see [Plugins](/plugins/)) with `contracts: { channels: [<id>] }` in the manifest,
+(see [Plugins](PLUGINS.md)) with `contracts: { channels: [<id>] }` in the manifest,
 and it mounts under `/channels/<id>/`.
 
 Two members are always there; the rest of the object decides which shape you get.
@@ -536,8 +536,8 @@ command carries `transport: "channel:<id>"`.
 
 ## See also
 
-- [Security](/security/) — the tokens, the egress guard, and why the rate limit
+- [Security](SECURITY.md) — the tokens, the egress guard, and why the rate limit
   matters for anything public.
-- [Agents](/agents/) — `limits[:queue_mode]`, which is what produces `merged` and
+- [Agents](AGENTS.md) — `limits[:queue_mode]`, which is what produces `merged` and
   `steered`.
-- [Observability](/observability/) — the event stream and OpenTelemetry.
+- [Observability](OBSERVABILITY.md) — the event stream and OpenTelemetry.

data/docs/CONTEXT.md

@@ -1,7 +1,7 @@
 ---
 title: Context
-parent: Build an agent
-nav_order: 4
+parent: Core concepts
+nav_order: 5
 permalink: /context/
 ---
 
@@ -26,10 +26,12 @@ into a deterministic prompt:
 | **Skills** | `<available_skills>` | 80 | identity | Level-1 skill list, minus whatever is already eager — see [Skills](SKILLS.md). |
 | **Tool search** | `<available_tools>` | 70 | identity | Level-1 list of deferred tools — see [Tools](TOOLS.md). |
 | **Skill trigger** | `<active_skill>` | 85 | volatile | Level-2 bodies: the agent's `skills_eager` set, plus the ones whose `triggers:` match the message — see [Skills](SKILLS.md). |
+| **Knowledge** | `<knowledge>` | 77 | volatile | Level-1 top-K learned concepts for the turn's message (+ one-hop `[[links]]`), only if `knowledge.retrieve` is on. Cuttable — see [Knowledge](KNOWLEDGE.md). |
 | **Memory** | `<memory>` | 75 | volatile | Durable facts + recent notes, only if `memory` is on. Cuttable. |
-| **Briefing** | `<briefing>` | 65 | volatile | The session's working state (known fields, still-missing list, next step) — only if the pack declared `briefing_fields`. Cuttable. |
+| **Briefing** | `<briefing>` | 65 | volatile | The session's working state — the *known* fields only. Only if the pack declared `briefing_fields`. Cuttable. |
 | **Session** | history | 60–79 | volatile | The running transcript; priority scales with recency. |
 | **Request** | `<request_context>` | 40 | volatile | Turn variables + tenant. Most cuttable; sits last. |
+| **Briefing (tail)** | `<recitation>` | 95 | volatile | The still-missing list + next step, rendered **after the whole history** as a `user` message — the last thing the model reads before the current message. |
 
 The ordering is deliberate: the render order is **identity layer first, volatile
 layer after** — nothing volatile can sit above the cache boundary, whatever its
@@ -41,7 +43,8 @@ cacheable prefix byte-stable (see the prefix cache below).
 - The cap is `profile.limits[:context_budget]`, **default 8000 tokens**.
 - To fit the budget, the builder cuts **non-pinned** fragments
   lowest-priority-first (ties broken by oldest history first). Under pressure you
-  lose old history, then the memory block, then request context — **the pinned
+  lose request context first, then old history, then briefing, then memory, then
+  learned knowledge, then the skill/tool-search level-1 lists — **the pinned
   identity is never truncated**.
 - A **pinned** fragment (the identity) that *alone* exceeds the budget raises an
   error — the turn fails rather than shipping a truncated identity.
@@ -51,14 +54,37 @@ cacheable prefix byte-stable (see the prefix cache below).
 > returns empty turns, raise `context_budget` (e.g. to `60000`) before looking
 > anywhere else. See [Agents](AGENTS.md#default-limits).
 
-### Compaction is not wired — except the mechanical dedupe
-
-There is a settings stub for LLM-summarization compaction (`enabled: false`,
-`keep_last`, a reserved utility-model slot), but **nothing consumes it today**
-— and the Studio no longer shows a form for it, so the setting cannot be
-switched on by accident. Size is managed purely by hard budget eviction.
-Do not rely on compaction to shrink a bloated agent: tune `context_budget` and
-keep the identity lean.
+### In-session compaction (opt-in, platform Settings)
+
+When enabled (Studio → Settings → General, or the `compaction` settings hash),
+the engine summarizes old turns *inside* the session instead of losing them to
+eviction:
+
+- **Trigger:** after a turn commits, if the session's *uncompacted* message
+  count exceeds `compact_after` (default 40), everything but the last
+  `keep_last` messages (default 20) is summarized by a cheap model
+  (`compaction.model`, falling back to the platform `utility_model`; neither
+  set = the feature is inert and `insika doctor` warns). Runs off the critical
+  path — the customer already has the answer.
+- **Read path:** the Session provider replaces the compacted prefix with ONE
+  history fragment — a `user` message wrapped in `<conversation_summary>` tags,
+  priority 59 (one step below the oldest verbatim message), source
+  `compaction` (its own category in the context trace). The tail stays
+  verbatim and the boundary is **stable** between compactions, so the prompt
+  cache holds after it.
+- **What survives:** the default prompt orders the summary to preserve customer
+  facts (sizes, CEP, order numbers), the assistant's commitments, the still-open
+  questions and the decisions already made; on re-compaction the previous
+  summary is folded in, so a fact from turn 3 survives every later batch.
+  A platform `compaction.prompt` replaces the default wholesale.
+- **Scope:** store-sourced history only — a checkpoint resume replays its own
+  tape and an explicit `history` is the caller's contract; neither is
+  rewritten. Observability: the `:context_compacted` event, the
+  `insika.context.compacted` counter and `{upto, runs}` in the context trace.
+
+Compaction does not replace the budget: eviction stays as the hard backstop
+for a single oversized turn. Tune `context_budget` and keep the identity lean
+regardless.
 
 One cheap half **is** wired, opt-in per agent: `tool_output_compression` (DSL
 `tool_output_compression`, or `"tool_output_compression": true` in the pack).
@@ -88,16 +114,16 @@ conversation; memory is the small set of facts that should outlive any single
 conversation. Facts and notes are editable from the Studio agent page. See
 [`examples/memory/`](https://github.com/guizaols/insika/tree/main/examples/memory/) for a runnable cross-session example.
 
-Facts carry **provenance metadata** (RFC-0031): every fact record stores `origin`
+Facts carry **provenance metadata**: every fact record stores `origin`
 (who wrote it — `"engine"`, `"operator"`, `"legacy"` or `"distilled"`),
 `created_at` / `updated_at` timestamps, and an optional `expires_at` (ISO8601) —
 **an expired fact is never injected**, even before the daily sweep prunes it. The
 Studio Customers drill reads and edits the same cell the next turn reads (injection
 unchanged), and every operator mutation lands in the content-free audit trail
 (digests, never values). The sweep honors the `memory_ttl_days` setting on its own
-knob — see [Security](SECURITY.md#memory-and-the-right-to-be-forgotten-lgpd-rfc-0031).
+knob — see [Security](SECURITY.md#memory-and-the-right-to-be-forgotten-lgpd).
 
-An **approved distilled fact** (RFC-0034 — see [Facts](FACTS.md)) lands in the
+An **approved distilled fact** (see [Facts](FACTS.md)) lands in the
 same cell this provider injects, stamped `distilled:<session_ref>` — approved on
 the Studio Facts page, never applied automatically.
 
@@ -119,19 +145,37 @@ pack:
 briefing_fields "size", "budget", "delivery_day"
 ```
 
-With fields declared, the turn's `:system` context gains a `<briefing>` block
-(priority 65 — below identity/skill/memory so it never breaks the cacheable
+With fields declared, the briefing renders in **two places**, and the split is
+deliberate.
+
+The durable half — what is already known — sits in the `:system` context
+(priority 65: below identity/skill/memory so it never breaks the cacheable
 prefix, above the turn's own `<request_context>`):
 
 ```
 <briefing>
 known:
   size: M
+</briefing>
+```
+
+The half that is a *goal* — what is still missing and the agreed next step — is
+**recited at the tail**, after the whole history, as the last thing the model
+reads before the current user message:
+
+```
+<recitation>
 still missing: budget, delivery_day
 next step: send the payment link tomorrow at 10
-</briefing>
+</recitation>
 ```
 
+Attention is strongest at the end of the context: a goal stated only at the top
+is the first thing a 30-call turn forgets. So the recitation was **moved** there,
+not copied — the head never repeats it, and the turn pays for it once. It rides
+as a `user` message, like every other engine append inside a turn, so the system
+prefix stays byte-stable and the cache breakpoint at its end keeps hitting.
+
 The `still missing` list is the point: the *model* sees which declared fields are
 still unanswered, so it stops re-asking for something already given. Stored keys
 that the pack no longer declares are never rendered. The Studio session screen
@@ -165,7 +209,7 @@ Two distinct caching mechanisms — don't conflate them:
 Cache accounting surfaces as `cached_tokens` (reads) and `cache_creation_tokens`
 (writes), visible in telemetry and the Studio tokens chip.
 
-### The two layers (RFC-0030)
+### The two layers
 
 The system block is partitioned into two cache layers:
 

data/docs/DEMO.md

@@ -0,0 +1,80 @@
+---
+title: Demo data
+parent: Start here
+nav_order: 4
+permalink: /demo/
+---
+
+# Demo data — see every loop working at once
+
+Most of what makes Insika worth looking at only shows up after data has
+accumulated: a [funnel](OUTCOMES.md#the-outcome-funnel) with a frozen
+baseline needs weeks of folded outcomes, a [refinement](REFINEMENT.md)
+proposal needs a run that actually found something, an
+[approval](POLICY.md#layer-2-policies-and-approvals) needs a tool call
+someone is waiting on. A fresh instance shows none of that — every one of
+those pages renders its empty state, which makes it hard to tell "nothing
+happened yet" from "this doesn't work."
+
+`insika demo:seed` closes that gap in one shot: it provisions a single
+fictional agent (`demo-store`, an e-commerce support bot) and writes enough
+realistic-looking data to see every loop at once.
+
+## What it creates
+
+| Page | What you'll see |
+|------|------------------|
+| [Funnel](OUTCOMES.md#the-outcome-funnel) — `/studio/funnel?agent=demo-store` | 40 days of folded outcomes (`greeted → browsing → cart_started → checkout_started → purchased`) and a **frozen baseline** |
+| [Follow-ups](OUTCOMES.md#follow-ups--the-seller-who-comes-back) — `/studio/followups?agent=demo-store` | one record in each state: `pending`, `fired` (one per arm, so the A/B card has something to compare), `cancelled`, `blocked` |
+| [Refinement](REFINEMENT.md) — `/studio/refinement?agent=demo-store` | four runs across the lifecycle: `awaiting_approval`, `applied`, `rejected` (gate failed), `no_findings` |
+| [Approvals](POLICY.md#layer-2-policies-and-approvals) — `/studio/approvals` | two pending tool calls waiting on a human, one already resolved |
+| [Facts](FACTS.md) — `/studio/facts` | three distillation proposals (`pending`, `approved` — with the resulting memory fact, `rejected`) |
+| [Evals](EVALS.md) — `/studio/evals?agent=demo-store` | six golden cases and a baseline run with a mix of passes and one failure |
+
+Every record is written through the same store APIs a real turn would use
+(`OutcomeStore#create` + the funnel fold, `FollowupStore#create` + its
+transitions, and so on) — there is no bulk-insert shortcut, and no bundled
+`.rb` script outside `lib/` (nothing here needs a checkout; it ships in the
+gem).
+
+## Running it
+
+From the CLI, against whichever store the rest of your commands already use
+([Running locally](RUNNING-LOCAL.md#variables-all-optional) — `INSIKA_DB`
+unset means an ephemeral, in-memory store, which is a fine place to try this):
+
+```bash
+insika demo:seed
+```
+
+A second run is a safe no-op once `demo-store` exists; pass `--force` to seed
+another batch on top (the funnel baseline recomputes cleanly, but follow-ups,
+refinement runs, approvals, proposals and goldens accumulate rather than
+reset — none of those stores expose a per-agent bulk-delete that a shared
+"platform" tenant could call without risking another agent's data).
+
+From the Studio, open **Settings → Demo data** and click **Seed demo data**.
+It dispatches the exact same command the CLI runs — the Studio never writes a
+store directly, here or anywhere else.
+
+**This writes into whatever store the running instance already has open.**
+There's no separate demo database and no isolation: point `INSIKA_DB` at a
+scratch file (or leave it unset, for an ephemeral store) before seeding —
+never at a deployment holding real tenant data.
+
+## Then look around
+
+Once seeded, the CLI prints the same six paths listed above. If Studio isn't
+running yet, boot it the way you already do — see [Running
+locally](RUNNING-LOCAL.md#boot) for a checkout, or [Embedding](EMBEDDING.md)
+for `Insika.agent { … }.serve` — pointed at the same `INSIKA_DB`. Studio reads
+every agent's profile from the same config store, so it will show
+`demo-store` next to whatever agent you're actually building, no matter which
+one the running process itself defines.
+
+## See also
+
+- [Refinement](REFINEMENT.md), [Facts](FACTS.md), [Evals](EVALS.md) — what
+  each seeded page actually means.
+- [Running locally](RUNNING-LOCAL.md) — booting Studio against a durable
+  `INSIKA_DB`.