Anchored to a real classroom
The feature set exists because a practicing interpreting teacher does these things by hand every week: finding bilingual material worth teaching from, cramming background before a meeting she has to interpret, drilling students on sight interpretation, and figuring out which terms a class collectively hasn’t learned yet. InterpScout automates each of those specific chores — it doesn’t try to reinvent interpreter pedagogy from first principles. When a feature doesn’t map to something the teacher or her students actually do, it doesn’t ship. That discipline is also why this site describes real numbers instead of projected ones: real courses, real briefings, real classroom usage, all produced by the system this site documents, not staged for a demo.Quality over speed
The instinct in most AI products is to optimize for a fast first response. InterpScout optimizes for a correct final artifact, even when that takes longer. A course that comes out with misaligned paragraphs or a padded glossary is worse than useless to a teacher who trusts it enough not to double-check — so production runs as a durable, multi-minute process with an adversarial review step and mechanical acceptance gates, rather than a single fast pass. When something the mechanical gates check comes back wrong, the system is built to catch it and retry inside the same session, backed by gates that verify before anything reaches a teacher’s screen. Slow and right beats fast and shipped-broken; see Truth Layer for exactly how that’s enforced.Why agents that deliver artifacts, not a chatbot
A chatbot’s unit of output is a reply. InterpScout’s unit of output is a finished thing a teacher or student can use without further editing: a parallel-reading course, a pre-meeting briefing, a graded practice attempt. That distinction shapes the architecture more than anything else on this site. Producer and Briefing run as durable sessions precisely because a finished artifact sometimes takes minutes of real research and real verification to produce correctly, and a chat-shaped request/response loop can’t hold that kind of work without either timing out or pretending it’s done before it is. Cockpit, by contrast, stays a plain chat interface on purpose — because dispatching work and holding a conversation about it is a genuinely different job from doing the work, and keeping the two apart is what lets each be reliable on its own terms (see Agent team).A closed loop between teacher, student, and machine
The three practice surfaces aren’t independent: a teacher produces a course, a student practices sentences from it, a model scores the attempt, the missed terms feed the student’s flashcards and the class’s weak-term board, and that board tells the teacher what to teach next. Each step writes data the next step reads — nothing here is a one-off report generated on request. That loop is the actual product; the individual agents are how it gets fed.Scope, by design
This list is intentionally small. These are deliberate boundaries, chosen on purpose — not gaps waiting to be noticed.
- Registration is invite-code-only by design, and stays that way unless there’s a product reason to open it — see Classroom.
- Source cleaning is deliberately scoped to a curated set of domains with dedicated cleaners — official government and ministry sites and specialist bilingual-text sites. Extending that list is a controlled, ongoing process: each new source gets its own cleaner rather than being accepted at lower quality.
- Connecting the terminology base to external authoritative term banks is a direction under consideration, not a committed feature. The base currently grows only from courses the system itself has produced.