How work flows through the system: the teacher and Cockpit only enqueue; a scheduled dispatcher hands each job to the Producer or Briefing agent on the durable runtime, and every artifact clears mechanical gates before it reaches the database and the UI.
Two agents, two jobs
Producer and Briefing are both durable agents that take minutes and clear mechanical gates before saving — but they solve different problems for the interpreter:Producer — course production
The Producer works like a diligent 译审 (reviser): it reads the whole document, drafts a glossary, hands that draft to a skeptical reviewer colleague whose only job is to tear it apart, fixes whatever the colleague flags, and only then submits the result to an automatic checker that has the final say. Concretely: 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 (a job that keeps its state even if the server restarts; see Architecture) — 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 (a deterministic code check, not a model judgment) 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, for the same reason (see Architecture). 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. Why that separation matters is in Philosophy; why every artifact is verified mechanically rather than trusted on the agent’s word is 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’sdeepseek-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.