How it works
What happens between your sentence and an issue.
Pol’s bet is simple: a scout is only useful if it has a computer. Not a model recalling what it read in training — an actual isolated machine that goes and fetches the page this week, and keeps the link. Here’s the whole path, and the guarantees on it.
The pipeline
Your sentence becomes a newsroom
The first decision isn't “what should this agent do” — it's “who is worth hiring at all.” One planning pass reads your sentence and returns a set of scouts whose beats don't overlap, each with a name, a role, and a brief written as an instruction to that scout. Competitors you name survive into the brief verbatim.
One model call. Roughly five seconds.
Each brief becomes a program
Every scout is planned separately from its own brief. That pass produces its persona — which sources to trust, what counts as important, how a filing should be structured — and a self-contained program that does the reading. In domains we know deeply, a playbook of real source feeds and evaluation criteria is appended to that planning pass by keyword match; it feeds the plan, it never replaces it.
One model call per scout, in parallel.
The program runs on its own computer
Each scout's code executes inside its own isolated container with its own filesystem and network egress. Inside, it runs its own model loop with real tools: fetch a URL, parse a feed, read a page. It decides what to look at as it goes and keeps the link to everything it used, which is what makes the citations on the issue real rather than decorative.
One to four minutes per scout.
Filings are checked before anyone sees them
A filing is validated against a contract, repaired if the model wrapped it in prose or fences, and scored by a separate judging pass on specificity, sourcing and structure. A filing that fails the quality bar is re-run rather than published. Every run stores its own trace, its score, and what it cost.
Stored per run, visible per scout.
The editor assembles the issue
Your chief of staff reads every filing and returns three things: a headline, a note, and an order. That is all it returns — the findings and their source links are carried into the issue out of the database by code. There is no path from the editor's response to an item on the page, so it cannot introduce one. The issue is numbered per company and stored with the run ids it was built from.
One model call, on the cheap tier.
It publishes itself, once
A scheduler wakes hourly, claims each scout that's due, and runs it; assembly happens after, and refuses to publish when the newest filings are already covered by the last issue. A retried dispatch, two overlapping ticks and a double-clicked button all produce exactly one issue. The number is unique per company in the database, so two containers can't both publish issue 12.
Anchored to your timezone, not the server's.
The stack
Two pieces, doing what each is best at.
The brain
Claude
Designs the newsroom, writes each scout’s persona and its program, then runs inside that program as the loop that decides what to read next. It also judges the filings afterwards, and edits the issue at the end.
The body
A Modal sandbox
Every scout gets a real isolated container — its own filesystem, its own network egress, its own crash radius. That’s what makes a scout a hosted program that went and read something, rather than a saved prompt, and it’s what lets one scout’s week fail without touching anyone else’s.
Everything else is plumbing that has to survive real conditions: containers that recycle mid-run, two dispatchers waking at the same instant, a source that 404s, a model that returns almost-valid JSON. Those are the failure modes that decide whether an issue lands every week or only most weeks.
What that buys you
An issue is a document, not a view
It has a number, a date, a lead story, an editor's note, and sections credited to the scout that reported each one — stored as a published artifact. It keeps reading the same way after a scout is let go or rewrites its own page, and it downloads as markdown you can paste into Slack or an email.
Corrections that actually change the work
Tell a scout in the thread to stop covering funding rounds under $50M and that is stored against it and injected into every future planning and writing pass. It isn't a note in a log it might scroll past — it is part of who that scout is from then on, and you're shown what was learned at the time, because memory is otherwise invisible until next week.
One reply, never a chorus
Reply to an issue and exactly one scout answers. A direct message goes to its owner with no routing call at all; an @-mention wins outright; only an ambiguous group message costs a routing decision — and every failure path in that decision falls back to a single scout, so the thread can't answer three times or go silent.
Pages the scouts keep current
Alongside the weekly issue, each scout maintains one markdown page for its beat, rewritten from what it found. A week you skip is gone; a page kept current while you were away is worth exactly as much when you open it before a call. The changelog section is append-only, enforced in code — a model returning an empty list cannot erase last Tuesday.
Straight answers
How is this different from an AI newsletter tool?
Those summarise what a model already believes. Each of your scouts is a program that ran this week in its own container, fetched pages, and kept the links — so the issue cites what it actually read rather than what a model absorbed during training. The source links collected by your scouts stay with their findings. A finding without a usable source link is labeled so you know what still needs checking.
Can the editor make something up?
Not onto the page. The editor returns a headline, a note and an ordering of your scouts; the findings and their URLs are carried into the issue out of the database by code, so there is no route from its response to an item. A test feeds it fabricated sections and asserts they disappear while the real sources survive. The note itself is the editor's own prose and is the one place its judgement shows — which is why it is labelled as the editor's, not presented as fact.
What happens when something fails?
It depends what, and the differences are deliberate. A scout that fails is recorded as a failed run with the error and stays on its schedule. If the EDITOR is unreachable we still publish — your scouts' findings are real — but in roster order with an empty note, and the issue says so rather than passing roster order off as editorial judgement. If nobody filed, no issue publishes at all: an empty issue burns a number and teaches people an issue might contain nothing.
Can it be wrong?
Yes. Every issue is assembled from sources your scouts fetched, and it links all of them so you can check before you repeat anything. Where a scout couldn't find enough substance it is told to say so rather than pad — a short, honest issue is the intended behaviour, not a bug. A newsletter that always finds three important things is telling you about its prompt.
Who can see our issues?
Your account. Scouts, their filings, their memory, your threads and every issue are scoped to you, and nothing is shared or published anywhere by default. Issues are private to the account that created them. Download an issue as Markdown to share it with colleagues; a link to your signed-in workspace does not grant them access.
What does it cost to run?
Every run is metered and stored against your account, and the editor's assembly is one call on the cheap tier because it is judgement over text we already have. If you'd rather not be on our account at all, connect an API key from the Anthropic console and every scout — including the ones already hired — bills to you instead, with no ceiling from us.