A Personal Tech Radar for AI Tooling

There are two failure modes for keeping up with AI tooling.

The first is drowning: you follow every launch thread, skim every paper, join every waitlist, and end each week with forty open tabs and nothing shipped. The second is dismissal: you decide the churn is noise, stop looking, and six months later discover your entire audio pipeline could have been replaced by something faster, cheaper, and local.

I spent time in both failure modes. What got me out was borrowing an idea from Thoughtworks — the Tech Radar — and rebuilding it for an audience of one, with automation doing the scanning and my memory system doing the remembering.

The Problem With Ad-Hoc Evaluation

The Thoughtworks Radar works because it forces two things that ad-hoc evaluation never does: regular cadence and explicit verdicts. Technologies don't just get discussed — they get placed: Adopt, Trial, Assess, Hold. And the placement gets revisited on a schedule, so a "wait and see" from March doesn't silently become a "never looked at it" by September.

Most individual developers do neither. We evaluate tools when a launch tweet happens to catch us at a receptive moment. The result is that adoption decisions are driven by marketing timing rather than fit — and there's no record of what we decided or why, so we re-litigate the same tools every few months.

A personal radar fixes the process problem. Automation fixes the labor problem.

The Architecture

My setup has three layers: a scanner, a radar, and a memory.

Layer 1: The research scanner

A scheduled pipeline scans the research firehose — new papers, releases, and technical posts — and does the one thing that makes the volume tractable: it compresses each item to a single-sentence takeaway focused on the mechanism, not the marketing. Not "Pythia is a revolutionary new serving system" but "Pythia captures workflow semantics through a simple interface, unlocking optimizations that treat agentic workloads differently than generic LLM traffic."

These takeaways don't land in a reading list I'll never open. They're written directly into Engram, my long-term memory system, tagged with their provenance (source: research_scanner). That tagging matters more than it sounds: when I'm later working on, say, agent evaluation, a semantic search over memory surfaces relevant research I scanned weeks ago — automatically, in context, without me remembering that it exists.

The scanner's job is not to make decisions. It's to make sure the radar never starts from a blank page.

Layer 2: The weekly radar

Once a week — Monday, by cron — a radar script runs a batch of automated scans (six focused sweeps via a search-grounded LLM API) across the areas I actually care about: local inference, TTS/voice, agent frameworks, memory systems, evaluation tooling, and orchestration. It cross-references what the scanner has accumulated, then produces the actual radar document: candidates placed into tiers, each with a priority score.

The output format is deliberately opinionated. A candidate isn't "interesting" — it's P9 ADOPT or P4 ASSESS. The priority score answers "how much does this matter to my stack?" and the tier answers "what am I supposed to do about it?" Adopt means integrate this week. Trial means spin up a sandbox. Assess means the scanner keeps watching. Hold means I've looked, and the answer is no — write down why so I don't look again for the wrong reasons.

Two design choices keep this honest:

It's scoped to my stack, not the field. A general "what's new in AI" scan produces noise. A scan scoped to "I run local models on Apple Silicon, I build voice pipelines, I care about agent memory" produces candidates I can actually act on. The radar knows my constraints because they're written into the scan prompts.

It degrades gracefully. When the search API key broke and all six auto-scans started returning 401s, the radar ran manually that week. The cadence is the sacred part, not the automation. A radar that skips weeks when the plumbing breaks stops being a radar.

Layer 3: Memory closes the loop

Every radar verdict — and every adoption outcome — goes back into Engram. This is the piece most evaluation processes miss entirely. The value isn't just deciding; it's remembering what you decided and what happened next. When a tool I passed on in March shows up again in July with a new release, the radar doesn't evaluate it from scratch. It evaluates the delta against a recorded verdict.

A Real Trace: Paper to Production in a Day

Here's what the pipeline looks like when it works, with a real example from March.

The March 30 radar flagged Voxtral TTS — Mistral's 4B text-to-speech model — as a P9 ADOPT candidate for my article-to-podcast pipeline, which turns written content into short branded audio episodes and had been running on Qwen3-TTS.

Same day: Voxtral was integrated into the pipeline behind a generation script, and the dry run passed. Then the evaluation surfaced the thing no launch post mentions prominently: voice cloning — the feature I actually needed — sits behind a paid plan. Verdict recorded: Voxtral integrated and validated, but Qwen3-TTS retained as the reliable default until the cloning economics make sense.

Total elapsed time from "radar surfaces candidate" to "informed, recorded decision with working integration": one day. Without the radar, that evaluation happens weeks later, if ever — probably triggered by a tweet, probably half-finished.

Note what the outcome was: not a migration. A P9 ADOPT that ends in "keep the current tool, with a documented reason" is the system working, not failing. The radar's job is fast, cheap, recorded verdicts — not maximum churn.

Why This Beats Both Failure Modes

Against drowning: the scanner reads so I don't have to. I see one-sentence mechanisms, weekly, scoped to my stack. The forty open tabs are gone because the pipeline's output is a decision queue, not a reading queue.

Against dismissal: the cadence is automatic. I don't have to feel like scanning; Monday happens regardless. And because verdicts are recorded, the cost of assessing something is paid once, not every time it re-enters the discourse.

There's a compounding effect, too. Every scanned paper, every verdict, every integration outcome enriches the same memory that my agents draw on for everything else. The radar isn't just an evaluation process — it's a continuous feed into the personal AI OS that makes every future evaluation faster.

Building Your Own

The minimum viable version needs three things, none of them exotic:

1. A scheduled scan. One cron job, one search-grounded LLM call per area you care about, scoped hard to your actual stack and constraints. Weekly is the right cadence — daily produces noise, monthly loses the thread.
2. Forced verdicts. Every candidate gets a tier and a priority. "Interesting" is banned. If you can't place it, that's an Assess with a date to revisit.
3. Durable memory. Verdicts and outcomes go somewhere your future self (or your agents) will actually re-encounter them. A markdown file works. A semantic memory system works better, because retrieval happens in context instead of by discipline.

The AI tooling firehose isn't going to slow down. The choice is between being swept along by it, ignoring it, or building a small machine that drinks from it on your behalf — and remembers every sip.