Designing Work Queues vs Reference Libraries?

Rewired and shipped.

Three-lane Intake Editor classifier live:

Work-item (default) → labeled brief, downstream agent

Reference-entry (new) → sub-routes by signal:

Affiliate candidate → gaps row on registry library

Brand-fact change → approval against BRAND-FACTS

Source-list → source library

Flag-no-owner → comment-back asking for clarification

Knowledge Steward boundary in place. Intake Editor is APPEND-only. Curation lives with one Steward agent (Affiliate Marketing Agent on ALE).

Single-writer at 10-agent scale — optimistic writes not needed yet.

Thanks @aronprins! I’ll rewire this today and let you know how it plays out!

Great framing — you've already done most of the design work yourself. Going through your five questions in order, with the caveat that the "Issue Documents" pattern is still settling, so some of this is current best practice rather than a frozen contract.

1. Has anyone built this pattern? Yes — affiliate pool + brand facts + source list is one of the most common shapes for content-ops companies, and the pattern that's holding up best in practice is roughly: labels for work-item queues, a small set of "library" issues with structured bodies for reference data, and an explicit "Knowledge Steward" agent that owns library writes. That last piece is the one most setups skip and then regret — without a single writer-of-record, every agent feels entitled to edit the library and you get drift.

2. Is the Issue Documents pattern the intended path for reference libraries? Roughly yes, but with a nuance. Documents are designed as per-issue artifacts (plans, designs, decisions tied to a piece of work), but the "single issue, structured body, agents read on every relevant task" shape also works well for reference libraries — it's just an emergent use. The two reasons it lands better than parent+children:

Token cost is bounded. One fetch, structured rows, no fan-out into N child issues. Revisions are first-class. You get a real diff history of the library, not just an audit log of writes.

The downside vs. a child-issue array is querying. If you need "find all affiliates tagged gardening", a markdown table inside a Document is OK at 20–50 rows and starts to feel awkward past 100. At that size you're past the "library" primitive and into "tiny database" territory — at which point an external system (Sheet/Notion) starts to win.

3. Where does the affiliate library live so Writer + Intake Editor + CMO can all touch it? The race condition you're worried about is real but smaller than it looks, because the writes are infrequent (sponsor adds, list curation) compared to the reads (every draft, every triage). Two patterns:

Single library issue + Knowledge Steward as sole writer. Other agents propose additions via comments; Steward integrates. This is the boring-and-reliable path and what I'd start with. Single library issue + optimistic writes. Any agent can append rows; conflicts are rare because most adds are unique entries. Use the issue's updatedAt as the optimistic concurrency token (re-fetch, re-apply, retry on stale-write). Works fine for a 10-agent company.

Don't split the library across projects — that fragments the reference data and is the failure mode the Documents pattern was designed to avoid.

4. Founder-drops-link → multi-lane triage. Yes, this works and it's one of the more rewarding things to set up. Your current "Intake Editor reads a 📥 inbox issue" is the right shape; the trick for adding the third lane is to keep the inbox dumb and let the Intake Editor be the policy layer:

The founder dumps anything into the inbox issue as a comment. On heartbeat (or assignment when you @mention), the Intake Editor reads new comments, classifies each into one of three lanes — work-item, reference-entry, flag-no-owner — and routes: work-item → creates a labeled issue, assigns the right agent reference-entry → appends a row to the library issue (or proposes one for the Steward) flag → comments back on the inbox explaining what's missing