Interactive demo
This is the real workspace with one pre-built agent, three finished conversations and a fixed eight-passage corpus. The agent has one tool, web search; document retrieval happens automatically. Run the same local retrieval as the full app, or ask one live question. Answers are capped, cached and never saved, and no account is needed.
Reads the linked corpus, answers with citations, and asks before it searches the web.
ROLE AND GOAL You are a research analyst. Answer questions about the product, its architecture and its operating rules. Prefer evidence over intuition. HOW YOU WORK 1. Restate the question in one line. 2. Use the document excerpts included in this prompt. 3. If they do not cover it, say so and offer a web search. 4. Cite the source and page after each claim. TOOLS AND FORMAT - web_search: search the web only after the user approves each query. Document excerpts are added to this prompt automatically when PDFs are linked. Retrieval is not a tool call. Use short paragraphs, a bullet list for steps, and inline citations. ACCURACY Never invent a page number, a model name or a limit. If two sources disagree, show both and say which one is newer. WHAT NOT TO DO Do not write files, run code, or answer from general knowledge when the corpus covers the topic.
web_search
DuckDuckGo search. Pauses for approval before each query.
When PDFs are linked, a multi-query retriever pulls the closest chunks for several rewrites of your question and adds the unique matches to the system prompt before the model runs. No tool call, no approval.
One question, one answer. The agent reads the fixed corpus, cites the passages it used and keeps no history. This uses a small model and a capped daily budget; retrieval still works when the budget is spent.
How does document retrieval work, end to end?
What guardrails run before a message reaches the model?
Why does the agent ask before searching the web?
Retrieval runs locally: e5-small embeddings in Chroma, with multi-query rewrites when the daily rewrite budget allows and a raw-query fallback when it does not. The eight passages below are the entire index.
Eight handbook passages, shown in full. This is exactly what the retrieval step indexes; nothing else is indexed.
Agent Studio is a multi-user Flask workspace for purpose-built AI assistants. Each agent has its own name, system prompt, model, response style and private conversation memory. One account can keep several agents side by side, and switching agents switches the prompt, history and linked documents without reloading the page.
An agent is three things: a name, a system prompt and a conversation thread. The prompt is edited in a dialog with a template picker and an optional prompt writer powered by Mistral. Model and style are chosen per message in the chat footer: Mistral Small 3.1 or GPT-OSS 120B, with creative, precise or fast generation settings.
Chat memory uses LangGraph's SQLite checkpointer. Every agent id is a thread id, so an agent reloads its own messages after a restart. Clearing a chat deletes that thread only. Agents share the same graph but never share history, and timestamps are stored in message metadata so the interface can replay old conversations.
PDF upload extracts text with pypdf and splits it into 500-character chunks with 20 characters of overlap. Chunks are embedded locally with the ONNX build of intfloat/multilingual-e5-small, a 384-dimensional multilingual model, and stored in Chroma filtered by document id. At query time a multi-query retriever rewrites the question into alternative versions, retrieves up to four chunks per version and appends the de-duplicated set to the system prompt for that turn.
Every agent has one tool: web_search. It uses DuckDuckGo and needs no API key. Human-in-the-loop middleware pauses the run before any search and asks the user to approve or reject each query. Document retrieval is not a tool: when an agent has linked PDFs, a multi-query retriever pulls the closest chunks for several rewrites of the question and adds the unique matches to the system prompt before the model runs. The app does not expose a code execution or calculator tool.
Before a message reaches a model the app rejects empty or oversized input, applies a sliding-window rate limit of 20 requests per minute per account, and redacts email addresses and credit-card numbers from both directions. Model output is rendered with DOMPurify and Mermaid runs with its strict security level. Errors return a generic message and are logged without message content.
Sign-in uses Google OpenID Connect and an environment allowlist of email addresses; no passwords are stored. Every agent and document row carries the owner's email, and every query filters by the logged-in user. The public demo is a separate read-only route with no database writes and its own rate limit.
The app runs under gunicorn as a systemd service behind Caddy, which obtains and renews Let's Encrypt certificates. SQLite stores agents, documents and checkpoints. The service has a read-only filesystem apart from its instance directory, and secrets are injected with systemd credentials. One worker keeps the in-process rate limiter and model cache coherent.
It reads constants, embeds eight passages locally and renders HTML. If you ask a live question, it makes one capped model call, redacts PII and keeps no history. It never touches the database and never accepts a write. The full workspace still uses the same prompts, tools and retrieval pipeline.
Sign in to the full workspace