I Gave My Agents a Newsroom, a Second Opinion, and a Radar

Every few weeks a new model lands and the timeline does the same dance. Benchmarks, hot takes, a stampede to rewrite everything on top of the new thing. Then it happens again, and somehow the people who were “behind” last month are still behind, and the people who were shipping are still shipping.

Here’s what I keep noticing: the people getting real work out of agents are almost never the ones with the newest model. They’re the ones who built something around whatever model they already had.

The model is the easy part now. They’re all good enough. The hard part is everything around it, the part nobody screenshots. How do you keep up with a field that moves this fast without drowning? How do you get a second opinion from another model without every new tool taxing every session? How do you decide what’s worth adopting when something “better” drops every Tuesday?

This week I open-sourced three tools that go after those three questions. Not one of them is a model. They’re all scaffolding, and that’s the point.

Problem one: you can’t keep up, and the newsletters don’t help

The AI news firehose is unreadable. Most “AI newsletters” solve that by reblogging the same five launches everyone already covered, so by the time you read it you’ve seen it twice. And none of them can answer the one question you actually care about: so what, for my stack? A new reranker is noise to a frontend dev and a fire alarm to someone running retrieval in production. A generic feed can’t tell the difference, because it doesn’t know who you are.

So I built oss-ai-intel: a small pipeline you point at your own stack. Cheap deterministic code does the collecting (Hacker News, GitHub releases, arXiv, a pile of RSS feeds) and the filtering. Then it spends exactly one LLM call per run deciding what’s worth your attention, scored against a profile you write: your topics, the things you build. Out comes a short email. A couple of things that might change what you’re doing, a few worth knowing, or nothing at all if nothing happened.

The part I’m proud of is the memory. It works on three levels, and the whole goal is that you never get told the same thing twice. It won’t resurface a link it already sent you. It won’t re-report a running story unless something actually changed. And every few weeks it re-synthesizes the themes you track instead of listing the same headlines again. Most “intelligence” tools are really just feeds with extra steps. This one is built so that a quiet inbox means nothing happened, and repeating itself counts as a bug.

That’s a real run against the shipped defaults. It’s configurable, it’s model-agnostic, and it takes pull requests. Adding a source or a topic is meant to be a ten-minute contribution. Think of it as a newsroom that only covers the beat you assigned it. If you’ve been meaning to build one and never got around to it, start there.

Problem two: the tools you’re not using are still costing you

Here’s something I only really internalized this year. In agent work the scarce resource isn’t the model, it’s the context window. And the popular way to extend an agent carries a cost nobody advertises: when you connect an MCP server, its tool definitions load into every session whether you use them or not. Wire up five of them and your agent starts every conversation already dragging a suitcase of schemas it probably won’t open, burning context and attention before you’ve typed a word.

So when I wanted to pull other models in as helpers, I deliberately didn’t build a server. orsub is a plain command-line tool, and it costs you nothing until the moment you call it.

What it does is let you define named experts in a config file, each pinned to whatever model you like, and consult them on demand. An infosec reviewer on one model, a red-teamer whose entire job is to attack your assumptions on another, whatever the task wants. You can change which model an expert runs on with a single flag, per call or for a whole session. So the same decision that keeps my context clean, packaging this as a CLI instead of a resident server, is exactly what lets me reach a genuinely different model when I want a second opinion that doesn’t inherit my main model’s blind spots.

The lesson outlived the tool for me. Anything you reach for only occasionally belongs in a command you invoke, not an integration that sits resident in context all day. Save the always-on slots for the two or three things you genuinely touch every session, and let everything else wait until you ask for it.

Problem three: something better drops every week

This is the one that quietly wrecks people. Not the models, the churn. A new agent framework, a new protocol, a new “this changes everything” repo, every single week, each one a small tax on your attention and a big temptation to rewrite your stack. Say yes to all of it and you never ship. Say no to all of it and you wake up two years behind.

So I added two things to my awesome-ai-workflow kit.

The first is a discipline for the adopt-or-reject decision. Frame what the new thing would actually replace. Research the claim instead of inheriting it. Try it in isolation behind an adapter, so backing out stays cheap. Score it on your data, not the vendor’s README. Then write the decision down and put it on a radar (watching, trialing, adopted, or held) with the specific trigger that would flip it. The payoff is boring and large: a “no” you wrote down is a “no” you don’t re-argue next month when the same tool trends again.

The second is a real research routine for the times you do need to dig in, built for the coding tools that don’t ship one. It breaks the question down, fans out searches, and then does the thing most agents skip: it fetches the actual sources instead of trusting the search snippet, and it tries to refute each claim before it commits to it. I’ve written before about how deep-research agents get roughly one claim in ten wrong: confident, cited, and quietly made up. The failure was never that you get no answer. You get a beautiful answer that happens to be wrong. So the routine keeps what it confirmed apart from what it couldn’t, and tells you which is which.

The pattern under all three

Look at what these actually are, and none of it is clever AI. It’s scaffolding, and it comes down to four unglamorous things:

• Memory, so the system doesn’t repeat itself.
• Verification, so you don’t take one model’s word for it.
• Routing, so you can reach the right model for the job.
• Discipline, so you decide on purpose instead of on vibes.

All four are file-based and model-agnostic on purpose. Whatever model sits under any of these will change, probably before you finish reading this, and the scaffolding keeps working when it does. That’s the difference between building on a model and building around one.

If you’re trying to embrace agents and it feels like you’re falling behind, the problem probably isn’t your model. Look at what’s around it. All three of these are open source now, so you can start with mine and make them yours.