> ## Documentation Index > Fetch the complete documentation index at: https://docs.interpscout.org/llms.txt > Use this file to discover all available pages before exploring further. # The Agent Team > Producer, Briefing, and Cockpit — three agents with three narrow jobs 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](/internals/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](/internals/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. 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](/concepts/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](/internals/architecture) for the full model stack.