jesganaud.devaudio engineering field notes
~ Essays.wav/.flac

Research agents as jobs — an LLM wiki for a Second Brain

Scheduled ingest into a compounding research wiki for audio ML — the job graph, what each piece does, and which second-brain complexity I refuse.

published 2026-07-19tags system-ops · research-ops · openclaw · llm-wiki

Why I built this

Audio ML is a large field to enter. My problem was not “reading the wrong things.” It was too much to hold while discovering the area — papers, datasets, models, newsletters — and a personal stack that leaked: bookmarks lost in browser folders, papers I was sure I had saved, notes with no path back to the source.

Paper reading is expensive. As a newcomer it is hard to decide which papers deserve a full pass now, and how to read them — skim for map-making vs deep for a method you will use. Plenty are worth keeping as later signal and not worth a full read today. Without structure, “save for later” is another forgotten tab.

Chat with an agent helps for one question. It does not fix forgotten PDFs, rank what to open next, or turn highlights into a direction. I needed a compounding picture: which models and datasets keep recurring across sources (CLAP, MERT, and the rest), where to look for data next, which threads are noise. Working memory and ad-hoc bookmarks do not scale to that.

So I built a pipeline that does three jobs:

JobWhat it does
Discover topicsSurface what keeps showing up across mail and papers, not only what I already know to search for.
Understand the fieldForce cross-source synthesis into concept and entity pages instead of one-off summaries; use that over weeks to decide what to deep-read vs park.
Centralize searchOne wiki, plus a selective vector layer over it, as the desk I open first: filterable signal and a path back to the source page.

That last part is why Open WebUI + embeddings sit on the same markdown wiki, synced on a daily timer. Agents write files. The query UI is for finding things again without re-deriving them in chat. I plan to keep expanding sources — intentional signal, not everything on the internet.

Morning jobs triage, promote what earns a page, and ping a brief. FYI stays out of memory. OpenClaw is the runtime. The product is the pipeline and the wiki shape.

Bootstrap (gateway, private Telegram) is in the free OpenClaw Mastery course. I used it. This post starts after the channel answered.

What this is researching

The agenda is CS/AI/ML with a hard audio bias: music information retrieval, audio representation learning, multimodal music models, and the eval/dataset problems that show up on real corpora — ISMIR- and ICASSP-shaped topics, without locking the desk to one project.

Named entities already in the wiki include CLAP, MERT, and MusicFM. Concept pages hold themes that only appear after enough sources accumulate — audio/music generation among them.

A short topic list in MEMORY.md steers triage and paper search. Primary topics get heavier treatment, including GROBID full-text extraction on matching arXiv PDFs. Secondary topics stay abstract-first. This is not a generic AI-news bot. It is filtered to a research program.

The pieces

NameWhat it is
email-triageMorning job. Reads a dedicated Gmail inbox for newsletter subscriptions (via gog, a Gmail CLI — readonly / no-send) — not the personal mailbox. Sorts into Research Signal / Worth Reading / FYI / Skip. Appends useful rows to the shared inbox.
arxiv-ingestMorning job. Queries OpenAlex for new papers on the topic list (not a raw arXiv RSS scrape). Dedups. For Primary-topic arXiv only: PDF download + GROBID full-text extract, then inbox rows. Secondary topics stay abstract-only unless requested later. If GROBID is down, abstracts still flow — the pipeline does not block.
research-inboxShared queue (JSONL + side files). Holding area between “something arrived” and “it has a wiki page.” Nothing becomes durable memory until promotion.
research-kbWiki writer. Hooked when the inbox changes. Writes sources/ pages; updates entities/ / concepts/ when thresholds are met. When a GROBID fulltext file exists, Key Insight / Methodology / Open Questions ground in the paper body. The source page stays short; fulltext is input, not paste.
morning-digestReads yesterday’s wiki activity; sends a short briefing (+ momentum notes) to Telegram.
wiki-lintWeekly health check: broken links, orphans, duplicates, stale concepts, schema drift. Reports to Telegram.

main is still available for ordinary chat. Five agents plus the shared inbox queue — that is the research desk.

The shape

newsletter Gmail (gog) ──► email-triage ──┐
                                          ├──► research-inbox ──► research-kb
OpenAlex ──► arxiv-ingest ────────────────┘         ▲                   │
                 │                                  │                   ▼
                 │ Primary arXiv only               │          wiki: sources /
                 └── PDF ──► GROBID ──► fulltext/ ──┘               entities / concepts

                         ┌────────────────────────────────────────────┼────────────────────────────────────────────┐
                         ▼                                            ▼                                            ▼
                  morning-digest                                wiki-lint                               Open WebUI + Qdrant
                  (Telegram)                                    (weekly / Telegram)                     (daily sync / query)

Ingest fills the inbox. Primary arXiv papers also get a GROBID file that research-kb can ground on. Hooks start research-kb. Digest and lint only read. The same markdown wiki syncs daily into Open WebUI.

Morning digest on Telegram — topic bucket with an arXiv brief
img Morning digest on Telegram — topic bucket with an arXiv brief

Agents as jobs

These agents were built as batch jobs, not chat buddies: a schedule or a hook, a workspace, a skill file, a model, and an explicit tool allowlist. main is for conversation. The research desk is cron and hooks.

They must not share one bloated chat session. When a reflection job ran inside the wrong session, it echoed triage output instead of writing its own pass. Fixed by isolating cron sessions — not by cleverer prompting.

Rules that mattered more than model choice:

RuleWhy it matters
One trigger per downstream actionIf a hook already starts research-kb when ingest finishes, the ingest skill must not also call it — otherwise you double-bill and race the same write.
Hooks that start other agents must be asyncA blocking shell call inside a hook freezes the whole gateway event loop until the child finishes.
Default tool profiles lieA global “coding” profile quietly granted web search to agents that never needed it. Those calls failed loudly (search lived in another Docker network). Scope per job; do not trust the skill’s narrative as the full tool surface.
Wiki writes stay sequentialDuring backfill, spawning several writers looked free. They all touched the same index.md, log.md, and concept pages with no locking — duplicate concept page, lost log append. Luck cleaned it up once. Do not parallelize writers on a shared wiki without locks.
Complex checks belong in real scriptsLink-check as python3 -c "..." inside a skill’s markdown made orphan/broken-link counts jump between runs — nested quoting across shell + Python + markdown. Put the logic in a check_links.py the skill calls.
Lint reports echo what they scannedAgents expand their own scope. Do not assume a lint job only checked what its docs claim.

Model routing is pragmatic: cron agents on a cloud primary that can finish multi-step tool loops; local small models as fallback only. On a ≤8GB GPU, the 7–9B models that fit struggle with real tool-calling here. Lab checks against Ollama: one model emitted structured tool_calls on a toy schema but answered the real arxiv-ingest job with clarifying questions; another printed the tool call as plain text; another was rejected as not supporting tools. A toy demo is not the same as finishing the pipeline. If cron sits on the local fallback for a while, treat the desk as degraded.

The wiki is the product

When research-kb first shipped, output was a flat directory: one markdown summary per source, plus an index. That stopped me losing papers. It did not compound.

After ~125 sources, the flat KB drifted — duplicate slugs, collisions. A cross-source question meant re-deriving connections every time. Closer to RAG over a pile of summaries than a maintained map of the field.

I upgraded that same store into a compounding wiki: LLM-wiki shape (raw sources → derived pages → index) and OKF-style conventions (portable markdown links, per-directory indexes). Existing summaries were cleaned and backfilled. wiki-lint became the weekly health check.

Research wiki directory layout — sources, entities, concepts, fulltext
img Research wiki directory layout — sources, entities, concepts, fulltext
DirectoryJob
sources/One page per ingested item (capped, structured)
entities/Named models/datasets that appear in 2+ sources
concepts/Themes revised in place — synthesis, not a new file per mention
fulltext/GROBID section markdown for Primary-topic arXiv (input to research-kb, not pasted into source pages)
indexes + schemaRouting and rules every agent reads first

Case: one concept page that compounds

concepts/multimodal-machine-listening.md is the clearest proof this is not a flat summary pile. Lab snapshot: 31 sources, 2026-05-03 → 2026-07-09, from arXiv, newsletters, and industry. The Synthesis section does not list them. It names six cross-cutting trends — unified audio-language models, real-time streaming, spatial evaluation maturing, fusion architecture diversification, fine-grained retrieval, cultural gaps — each triangulated from 2–4 independent sources. A Contradictions section keeps an unresolved tension live: native vs. late-fusion architectures, with evidence from opposing camps.

That is what a Zotero library or an RSS folder cannot do on its own: testable claims from distributed evidence, revised in place.

Concept page — Multimodal Machine Listening synthesis and contradictions
img Concept page — Multimodal Machine Listening synthesis and contradictions

Promotion is filtered. Research Signal always promotes. Worth Reading only if it makes a citable technical claim. FYI/Skip stay in the inbox log. The test: would I still want this in a year? If no, it is a temporary connection, not durable context.

Why the 2+ sources rule for entities: an entity page for a model mentioned once is a second copy of that paper’s note. You pay to keep another file in sync, but there is nothing to compare yet — no second paper to contradict, extend, or confirm. Until a name shows up in two or more sources, leave it as a mention on the source page.

Weekly wiki-lint catches structural rot. It does not catch “ingest wrote to a deprecated path.” That needs skill hygiene: delete the old instruction; do not leave two authoritative output locations in one skill file.

How much second-brain complexity I actually run

Nate Herk’s Every Level of a Claude Second Brain Explained is a useful ladder, not a syllabus. His rule: pick the lowest level that kills your pain. Mapped here:

Herk level (plain English)What it meansHere
1 — Files + routerAgent finds notes by path / nameBaseline: workspaces, skills, topic file
2 — Curated wikiIndex → topic pages you can drill intoPrimary homesources / entities / concepts
3 — Semantic / vector searchFind by meaning when keywords missSelective, live — same wiki synced into Open WebUI + Qdrant daily; query layer on top of files
4 — Knowledge graphTyped relationship chainsNot now — backlinks + prose links are enough; GraphRAG / LightRAG can wait
5 — Always-on brain OSAutonomous sync that never sleepsPartial — research crons; ingest still filtered
Open WebUI query over the Research Wiki — Multimodal Machine Listening / June 2026 papers
img Open WebUI query over the Research Wiki — Multimodal Machine Listening / June 2026 papers

Curated wiki plus selective vectors. Typed graph waits.

Why I didn’t just pay for it (yet)

Elicit is the obvious managed option. Free Basic is already strong: unlimited search over 138M+ papers, unlimited summaries, chat with full-text, Zotero import, a couple of automated reports a month. Fine for hand work.

What I would need as a pipeline piece is different — the API and paper/topic alerts. Those sit behind Pro at $49/mo (~35% off annual). Free Basic covers hand work; $49 is the price of automation, not of reading papers.

OpenAlex is free and already covers most of the discovery half — same source arxiv-ingest queries. Over Elicit Pro, the DIY stack’s marginal cost is mostly my time building it.

That time was not only cost — wiring ingest, dedup, fulltext, synthesis is how I learned the field’s shape as a newcomer. Renting would have skipped the map. If my time were scarcer than $49/mo, Pro buys those weeks back; DIY is not free.

So I started DIY on free OpenAlex ingest. Elicit stays on Basic when extraction quality matters. Pro waits — until I catch myself wishing the alerts and API ran unattended.

Even rented, Elicit only replaces ingest and extraction. The compounding wiki — synthesis and contradictions revised in place — is still mine. It shrinks the pile. It does not hand me the memory.

The stack is still young. Corpus counts move. The durable part is the job graph and what runs now — not a claim that ~150 sources make a finished research OS.

Pointers