Skip to main content
InterpScout doesn’t have one do-everything assistant. It has three agents, each scoped to one artifact, plus a chat surface that deliberately cannot do agent work itself. Splitting responsibility this way keeps the system legible: each artifact has exactly one agent accountable for it, never a monolithic prompt where responsibility is diffuse.
eve durable runtime
progress heartbeats → Activity live view
Teacher
Cockpit
enqueue-only console
Postgres queue
queued rows
Scheduled dispatcher
claims queued rows
Producer
Adversarial reviewer
skeptical pass
Briefing
research + writing
Mechanical gates
verify, don’t trust
Database
courses · briefings · terms
Web UI
courses / briefings / activity
Terracotta marks the two agents; gold marks the system’s two trust mechanisms — the adversarial reviewer inside course production, and the mechanical gates every artifact must clear before it reaches the database. Cockpit only ever enqueues; it cannot run agent work itself.

Producer — course production

Given a bilingual source URL (or a teacher-uploaded file), the Producer agent turns it into a parallel-reading course. It runs as a durable, long-lived session — not a single request-response call — because the work genuinely takes minutes: fetching the source, cleaning and aligning it paragraph by paragraph, reading through the whole document window by window to curate a glossary, sending that glossary to an adversarial reviewer sub-agent for a second, skeptical pass, and revising until a mechanical acceptance gate lets it through. The full mechanics — the sandbox files it works in, the review sub-agent, the dozen-plus gates a glossary has to clear — are in Document Workshop.

Briefing — pre-meeting preparation

Given a meeting topic (and optionally a speaker, host organization, and focus notes), the Briefing agent researches the open web, cross-checks what it finds, and writes a structured pre-meeting knowledge briefing: domain crash course, institution and speaker profiles, contested issues, a graded bilingual term table, and further reading. It runs on the same durable infrastructure as the Producer, because the same problem applies — real research takes real time, and the agent needs to survive longer than a single HTTP request. The queue, the heartbeat discipline, and the save gate are in Briefing Pipeline.

Cockpit — the teacher’s dispatch console

Cockpit is the chat interface teachers see at /studio. It looks like it could delegate straight to Producer or Briefing, but it structurally can’t: it isn’t a durable agent session at all. It’s a plain streaming chat endpoint with a couple of narrow tools — enqueue a source for production, enqueue a briefing request — and nothing else. When a teacher says “produce this document” or “prepare a briefing on this meeting,” Cockpit writes a queued row to Postgres and replies immediately. A separate dispatcher, running on a schedule, is what actually hands the work to Producer or Briefing. This split is a deliberate piece of failure isolation. A chat interface and a long-running production job have opposite availability needs: the chat must answer in seconds, every time; the job may legitimately spend many minutes on research and gates. Running them in separate runtimes means no slow tool call deep inside a production session can ever hold the teacher’s console hostage — a chat request has a hard time limit, and the heavy work happens somewhere it can take its time.

Why agents, not a chatbot

Cockpit answers questions and takes dispatch requests. It does not produce artifacts. The philosophy behind that separation — and why every artifact is verified mechanically rather than trusted on the agent’s word — is covered in Truth Layer.

What ties them together

Producer and Briefing don’t share a code path, but they share a database: every course the Producer curates deposits its terms — with grading and sourcing — into the same terminology base that the reader UI highlights against and that later briefings draw context from. A teacher who has produced thirty courses on trade policy has, without asking for it, built a glossary that makes the thirty-first briefing on trade policy better sourced. See Terminology base for how that shared store is structured and searched. All three agents currently run on DeepSeek’s deepseek-v4-pro reasoning model for text work. The one place a different model shows up is scoring student audio, which is a genuinely different task — see Architecture for the full model stack.