Console AI — Wiki + AI Architect¶

The Prism Console ships two AI surfaces alongside the repo / token admin views: the Wiki agent, which generates a multi-page, diagram-rich overview of an indexed codebase, and the AI Architect, an in-Console chat that answers questions about your code using the same indexed-data tools your coding agents use via the gateway. Both live inside the repo detail panel — there is no separate "AI" page.

When to read this¶

You just connected your first repo and you want to know what the Wiki tab does before clicking the Generate button.
You generated a wiki months ago, the codebase has moved on, and you're wondering whether to regenerate.
You're trying out the AI Architect chat in the sidebar and want to know what it can cite, what model picker controls, and where the daily limit comes from.
A teammate asks "why doesn't the wiki show my latest changes?" and you need to explain the relationship between indexing and wiki generation.
You're auditing what data leaves your tenant when these features run.

Wiki agent¶

What it does¶

The Wiki agent reads the indexed code for one repo and writes a small, navigable wiki — an architecture overview, a table of contents, per-module pages, and per-symbol detail panels — with embedded diagrams. It runs as a background job; you trigger it once per repo, and it polls to update the UI as pages and diagrams land.

Each generated wiki includes:

Module pages linked from a sidebar table of contents — click a page to read it, click a module name inside the page to open the module card, click a symbol to open the symbol detail panel.
Diagrams in one of two qualities, chosen at generate time (see "Diagram quality" below).
Per-page "Deepen" and "Regenerate" actions so you can refresh a single section without redoing the whole wiki.
Optional supplementary documents — markdown, plain text, or PDF files you upload through the Upload context documents button in the wiki header. The agent uses them as extra context during generation.

When it runs¶

The Wiki agent never runs on its own. Every run is triggered by you, from the Wiki tab inside a repo's detail panel:

First-time generation. If a repo has no wiki yet, the Wiki tab shows a "No wiki yet" panel with a Generate Wiki button. The button is disabled until indexing for that repo is ready — the agent reads from the code chunks the indexer produced, so a wiki on top of an unfinished index would have nothing to read.
Regenerate. Once a wiki exists, the same header shows a Regenerate affordance. Use it after a meaningful chunk of work has merged and you want the wiki to reflect the new structure.
Per-page regenerate. Inside the wiki viewer, individual pages carry their own regenerate button — cheaper than redoing everything.

A full first-time generation typically takes 10–20 minutes (page writes + diagram batch). The UI shows phase-aware status messages — "Discovering codebase structure…", "Planning wiki structure…", "Writing page 4 of 12…" — and lets you cancel mid-run. You don't need to keep the browser tab open; the job runs server-side and the UI catches up next time you open the tab.

A complete_with_errors state means the text wiki is finished but some diagrams failed to render. The wiki is still usable; regenerate the affected pages individually.

Where output lives¶

The wiki is stored against the repo on the gateway side and rendered inside the Console. There is no export to your filesystem and no static-site publish — the Console UI is the surface.

Inside the Wiki tab you'll see:

Sidebar / table of contents with all generated pages.
Main content area with the active page.
Module card — slides in from the right when you click a module reference inside a page; lists symbols defined in that module.
Symbol detail panel — layers above the module card when you click a symbol; shows the symbol's signature and where it lives.

When to refresh¶

Refresh signals — any of these is a reasonable trigger to regenerate:

A meaningful piece of work just merged (a new module, a refactor that moved big things around, a renamed top-level abstraction).
A teammate reports that a wiki page describes code that no longer exists.
The indexer just finished a full reindex you triggered for unrelated reasons — the wiki is "free" to regenerate while context is fresh.

Refresh anti-signals — don't bother:

A single-line bugfix landed. The wiki is summary-level; tiny diffs aren't worth a 15-minute generation.
You're mid-feature on a branch. Wiki generation runs against the indexed default branch, not your feature branch — see Branches & Overlays for what overlays do (and don't) cover here.

Diagram quality¶

The header has a Diagrams toggle with two settings:

Mermaid — diagrams are rendered as text-defined Mermaid graphs in the browser. Fast, deterministic, no per-diagram cost.
AI Generated — diagrams are produced by a Vertex AI image-gen pipeline. Higher visual quality, but adds the "images_pending" phase to the generation lifecycle (text completes first, images fill in over 5–15 minutes).

Pick AI Generated when the wiki is going to be read by humans for architecture overview; pick Mermaid when you mostly care about getting the text content and don't want to wait on image rendering.

Plan-based wiki quota¶

The wiki agent is metered by plan tier. The current allowances are surfaced inline in the Console — your first wiki for a repo is free and doesn't count against the monthly quota. After that, regenerations consume your plan's monthly allowance. See Console Admin for plan-level limits in general.

AI Architect¶

The AI Architect is the chat panel in the dashboard sidebar. The header says "AI Architect" and a session bar underneath it shows the active conversation title with history / new-chat affordances.

What it answers¶

The AI Architect answers questions about your indexed codebase. The architect's system prompt frames it as "a senior software architect and senior developer who knows this codebase inside out" — it's tuned to evaluate, plan, spot problems, and guide implementation, not just to recite code. It picks the active repo from the one you currently have selected in the Console; if you have multiple repos indexed, you can ask about a different one by naming it in your question.

The empty-state welcome shows three starter suggestions, which are good examples of the question shapes the architect is built for:

"What are the most important modules in this codebase?"
"Give me a high-level overview of the architecture."
"What files were changed recently?"

It's equally happy with:

"How does authentication work?" — flows.
"Who calls RepoService.reindex?" — impact analysis.
"Should I add a new endpoint as a route or extend the existing one?" — design questions.
"Review this code: " — code review.
"What changed in the indexer last week?" — recent-changes summaries.

What it cites¶

Answers are grounded in real indexed data. The architect reaches into the same tool surface that powers prism for coding agents — semantic + exact search_code, symbol definitions, full function bodies, references, module maps, dependency graphs, coding standards from your repo's own rules files, and recent commits. It also has access to your repo's published vision and architecture docs (the "repo context") so it can frame answers around why code exists, not just what it does.

When it references a file or function, it formats the citation as a backtick-quoted path with a line range, e.g. path/to/file.py:42-67. Those citations render as clickable links in the Console — clicking opens a code viewer panel beside the chat so you can read the cited code without losing the conversation.

Where it helps, the architect inlines a Mermaid diagram (component graph, sequence diagram, dependency flow). Mermaid renders natively in the chat thread.

Current limits¶

Daily units. Each tenant gets a per-day unit budget that funds AI Architect chats; the footer of the chat composer shows today's usage versus the daily limit. When you exhaust it, an Out of units banner replaces the composer until the next 00:00 UTC reset. The free plan's daily limit is small (intended for evaluation); Team and Enterprise plans have substantially higher allowances. The exact numbers are surfaced inline in the Console.
Model picker. A small picker next to the composer footer lets you choose which underlying LLM serves the next message. The set of allowed models depends on your plan; the default model the picker starts on is also plan-driven. If you don't change it, the default is used.
Repo scope. The architect can only answer questions about repos your tenant has indexed. Asking about a public repo you haven't connected won't work.
Single active repo at a time. The architect uses the repo you have selected in the Console as the default for tool calls. Cross-repo questions work — name the other repo explicitly — but the architect doesn't proactively scan every repo on every question.
External research. The architect has limited access to a small set of external research tools (library docs lookup, web search) for cases where your question is genuinely about an external library or general best practice. These are billed against the session and used sparingly — the architect prefers your own code over external sources.
No write actions. The chat is read-only against your codebase. It will tell you what to change and where, but it won't open PRs or edit files. For that, use a coding agent connected to the prism CLI — see Coding Agents — Daily Workflow.
No code execution. It cannot run your tests or your code; it reasons over the indexed text.

How the guide corpus feeds it¶

This published guide collection — the same one you're reading — is part of the corpus the AI Architect can search via its search_docs and get_repo_context tools. The FAQ sections at the bottom of each guide are written deliberately as retrieval anchors: a user question of the shape "how do I X with prism?" should land on the matching FAQ entry and the architect should be able to cite the guide path back to you.

Practically, that means if you (or a teammate) ask the architect a process question — "how do I create a branch overlay?", "what does indexed_at mean?", "how do I rotate a developer token?" — it can answer with reference to these guides rather than re-deriving from raw code. Code-level questions still hit the code-search tools.

Sessions and history¶

The Console persists your chat history per tenant. The clock icon in the chat header opens recent sessions; the plus icon starts a fresh one. Session titles are editable inline — click the title in the session bar to rename. Deleting a session from the history dropdown is permanent.

Privacy and data handling¶

Both features operate against the same indexed data as your coding agents — i.e., the contents of repos your tenant has connected to Prism.

Code is indexed once, at the gateway. Your repo content is cloned by Prism's ingestion pipeline, AST-chunked, embedded, and stored in your tenant's Postgres schema (tenant_<id>). The Wiki agent and AI Architect read from that storage, not from a fresh clone per request. See Indexing Pipeline Deep Dive for how that pipeline works.
Multi-tenant isolation. The architect can only call tools that resolve against the tenant attached to your Console session. There is no shared pool — one tenant cannot read another tenant's chunks, wikis, or chat history.
LLM providers. Both the Wiki agent and the AI Architect send prompts (including snippets of your indexed code as context) to managed LLM providers — currently Vertex AI for the wiki text + diagrams and a mix of Vertex / Anthropic models for the architect, selected by the model picker. Provider names are surfaced in the model picker so you know what's serving each chat.
No background indexing of chat content. Your AI Architect messages and the wiki text are stored against your tenant for history and rendering, but they are not folded back into the search index. Asking the architect a question doesn't change what prism grep returns next time.
Uploaded wiki context documents. Files you upload via the Wiki upload dialog are stored against the repo and used during subsequent wiki generations. Delete them from the same dialog if you don't want them used.
Tokens are never sent to the LLM. The Console authenticates with the gateway using your session — your developer tokens stay on the machines you issued them to.

FAQ¶

Q: Why is the "Generate Wiki" button disabled on my brand-new repo?¶

A: The Wiki agent reads from the code chunks the indexer produced, so it needs indexing to finish first. The wiki header shows an Indexing in progress (or Indexing failed) banner while you wait; the button enables automatically once indexing is ready. If indexing is stuck or failed, retry it from the banner or from the Overview tab — see Console Admin.

Q: My wiki was generated months ago. Will it auto-refresh as I push code?¶

A: No. Wiki generation is only triggered manually — there is no auto-regeneration on push, no webhook-driven update. The underlying indexing pipeline keeps the search index fresh; the wiki is a separate, on-demand artifact you regenerate when it's worth the 10–20 minutes. Use the per-page Regenerate button to refresh one section without redoing everything.

Q: What's the difference between the Wiki agent and the AI Architect?¶

A: The Wiki agent is a batch, document-producing job — it runs once, takes 10–20 minutes, and leaves behind a readable multi-page wiki you can browse like documentation. The AI Architect is an interactive chat — you ask one question at a time and it answers in seconds, citing specific files and line ranges. Use the wiki for onboarding and orientation; use the architect for "what does X do?" / "how should I implement Y?" / "review this".

Q: The AI Architect says I'm out of units. What now?¶

A: The composer is replaced by an Out of units banner with a reset clock. The daily quota resets at 00:00 UTC. If you hit the wall often, upgrade your plan from the Plan page (the banner links there directly) — see Console Admin for plan limits.

Q: Can the AI Architect see my unpushed local changes?¶

A: No. The Console-side architect reads from the gateway's index, which only contains what was pushed and ingested. The CLI tools your coding agent uses (prism grep, prism find-refs, etc.) handle dirty-file overlays for your local edits — see Branches & Overlays. The in-Console chat does not have access to your laptop's working tree.

Q: My wiki finished but a few diagrams are missing or broken. Is something wrong?¶

A: That's the complete_with_errors state — text completed, but some diagrams failed to render (most often a Mermaid syntax issue from the generator or an image-gen timeout). The wiki is fine to read. Open the affected page and hit its Regenerate button to retry that page only, or switch the Diagrams toggle from AI Generated to Mermaid (or vice versa) and regenerate to swap rendering strategies.

Q: Which LLM does the AI Architect actually use?¶

A: Whatever you have selected in the model picker at the bottom of the composer. The set of allowed models is plan-driven (free plans see a smaller set; Team and Enterprise see more options, including higher-capability models). The picker starts on a sensible default for your plan; the default and the full allowed list are surfaced inline in the picker so you don't have to guess.

Q: Does the wiki include private code, secrets, or environment variables?¶

A: It includes whatever is in the indexed repo. If you've committed secrets (you shouldn't have), they're in the index, and they may end up summarised in a wiki page. The fix is to clean the repo, then trigger a reindex from Console Admin, then regenerate the wiki. The Wiki agent does not have its own secret filter — it trusts the repo content.

Console Admin — Repos, Teams & Tokens — connecting the repos these features run against, plan limits, and the developer tokens that gate CLI / chatbot access.
Glossary — definitions of code chunk, gateway, prism CLI, and other terms used above.