How we built Student Mode:
architecture & design decisions

When we set out to build Study Tools for law students, the first and most important decision was whether to build a separate product or extend the existing platform. We chose to extend it — and that choice shaped everything downstream.

This post covers the key technical decisions behind Student Mode: how we structured the mode toggle, the skill injection system, the student profile, and session history. We are sharing this because we think the design is worth explaining, and because the tradeoffs involved are not obvious.

Why a toggle, not a separate app

The fastest path would have been a separate URL — its own layout, its own session, no shared state with the professional product. That approach has real advantages: isolated failure domains, cleaner permission boundaries, simpler routing.

We rejected it for a reason that is central to 8rney's design: the platform should hold the full context of a user's work, not fragment it across products. A student doing a clerkship, or an associate who wants to use study tools on weekends, should not have to choose which app they are in. The AI should know who it is talking to and adapt accordingly — within a single session, without re-briefing.

Student Mode is implemented as a boolean flag on the user session. When it is on, the professional sidebar is replaced with the Study Tools panel, and a studentContextOverride is injected into every model turn. The underlying infrastructure — the research engine, document indexing, Drive integration — is untouched. Professional features are hidden at the UI layer, not removed from the API.

The skill system

8rney's behaviour in any given mode is determined by skill files — Markdown documents that are loaded into the model's context at the start of a turn. Each study tool (Case Brief, Socratic Drill, IRAC Practice, and the rest) has a dedicated skill file that specifies the interaction model: what the tool does, how it should question the user, what constitutes a complete response, and what it should never do.

Skill files are intentionally not code. They are human-readable specifications that can be edited, audited, and improved without a deployment cycle. When we found that a tool was behaving in a way that did not match its intended interaction model, we could fix it by editing a Markdown file rather than refactoring a prompt buried in application logic.

One constraint we enforced strictly: skill files must describe the actual product, not an abstract capability. Earlier versions of the student skills were written for a different interaction model — they referenced file paths, write-to-disk operations, and tool invocations that do not exist in the web application. We audited all eleven files and replaced every reference with the correct web equivalent before shipping. Skills that describe the wrong product are worse than no skills — they produce confidently incorrect behaviour.

Profile injection and personalisation

The Student Profile is a database-backed record storing year of study, school, bar jurisdiction, self-reported weak subjects, and learning style preference. On every student turn, the profile is serialised into a structured context block and prepended to the system prompt — ahead of the skill file, so the skill can refer to it.

This means personalisation is not a feature layered on top of the tools. It is structural. A first-year student working through Torts gets substantively different treatment from a third-year doing bar prep in a specific jurisdiction — not because we branch on those fields in code, but because the model has that context when it decides how to respond.

The profile is also the right place to store weak subjects rather than deriving them from session history. Derived personalisation requires enough data to be reliable; a new user has no session history. A two-minute onboarding that captures self-reported weaknesses gives the tools useful signal from the first interaction.

Session history and mode tagging

Each research chat in 8rney is stored with a set of metadata columns. For student sessions, we added two: studentMode (boolean) and studyModeKey (the name of the active tool when the session was created, e.g. "Socratic Drill" or "Bar Prep").

This allows the sidebar to group and label sessions meaningfully. A student who has run ten Socratic Drills and four Bar Prep sessions sees them organised by tool, not collapsed into a flat chronological list. Sessions accumulate context the way a good notebook does — indexed by what you were working on, not just when.

Follow-up question design

8rney surfaces suggested follow-up questions at the end of most responses. In the initial student mode build, the model was generating questions from its own perspective — requests for clarification, requests for more context. That is the wrong orientation for a study tool. The questions a student wants to see are the ones they would naturally ask next: "What are the exceptions?", "How does this interact with Section 12?", "Can you walk through a fact pattern?"

We rewrote the follow-up prompt to make this explicit, changed the label from "Suggested Follow-up Questions" to "Ask next", and updated the fallback questions to match the same user-first frame. The change is small in code; the difference in usefulness is significant.

Casual query handling

The research engine routes every query through a retrieval floor — a minimum relevance threshold for RAG context before generating a response. This is correct behaviour for legal research queries. It is incorrect behaviour for a greeting.

Student sessions include a casual query detector that short-circuits the retrieval floor for non-legal inputs. "Hi", "thanks", "can you explain that again" — these get direct responses without incurring retrieval latency or polluting the RAG context with irrelevant chunks. The detector is intentionally narrow; anything that looks like a substantive query goes through the full pipeline.

What we are building next

The current Flashcards tool is conversational — you request cards, the model generates them inline. We want to add a spaced repetition layer that surfaces cards at the right interval without requiring a separate session. We also want to close the loop between Bar Prep performance and the weak subjects stored in the profile — so the profile updates automatically as a student works, rather than relying solely on the initial self-report.

We are also thinking carefully about institutional use. Group features, course integration, and shared session notes are on the roadmap. If you are building curriculum around 8rney or have specific requirements for how it should work in a law school context, reach out — we want to understand those needs before we design the features.