Ideas Container

The overflow bucket in my personal auto-routing system for captured ideas — where anything the router isn’t confident about lands for a human to sort out later, instead of getting force-fit or dropped.

OngoingLow priority

The problem

I run a personal system (CogitOS) that captures ideas as I come across them — mostly notes distilled from talks, videos, and articles I go through — and tries to auto-route each one into the right project bucket. Auto-routing works well when an idea clearly belongs somewhere, but it fails in two predictable ways: either nothing existing fits, or the idea looks like the seed of a new project that hasn’t been reviewed and approved yet. Most systems handle that failure badly — they either force the idea into the closest existing bucket (where it gets buried and never seen again) or they silently drop it. Both are worse than admitting “I don’t know where this goes yet.”

The same failure mode shows up in any team that runs on tickets, epics, or project trackers: someone has a genuinely good idea in a meeting or a support call, it doesn’t map cleanly onto an existing initiative, and it either gets crammed into an unrelated backlog item as a footnote or it evaporates because there was no safe place to put it down. The cost isn’t the individual lost idea — it’s that people stop bothering to capture the ones that don’t have an obvious home, which is exactly the set most likely to contain something new.

The approach

ideas-container is that safe place to put things down. It’s a real project record inside CogitOS (proj_ce66893e, type “research”, status “ongoing”) with its own manifest, but its actual job is to be the router’s admission that it isn’t sure — a deliberate catch-all rather than a mistake. Ideas get into it through the same `capture_idea` MCP tool used everywhere else in the system; `list_projects` is what the router (and I, manually) checks against before deciding whether something has a real home. When it doesn’t, the idea lands here instead of being force-classified or discarded.

Concretely, right now it’s holding 43 processed source references — mostly conference-talk and YouTube transcripts on AI agent engineering — each broken down in `cogitos/refs/<id>/summary.md` into a TL;DR, key points, and an assessment, and then further distilled into individual atomic ideas in a single `ideas.md` file, each idea tagged back to its source video and timestamp-anchored ref ID. So the container isn’t just a dumping ground of raw links; it’s pre-processed into reusable, quotable claims (e.g. “replayability, not determinism, is the right observability goal for production agents”) that I can search or skim later. The manifest explicitly marks it for periodic offline review, not automatic triage — meaning nothing in here is meant to sit forever; the point is that a human looks through it on a cadence and either promotes an idea into a new project, manually routes it into an existing one, or leaves it here because it’s reference material with no action attached.

What I learned

The thing I didn’t expect was how much value showed up in the review step itself, not just in capturing the idea. Reading 40+ distilled ideas side by side surfaces patterns a single capture never would — several of these talks independently converge on the same underlying claim (e.g., that agent reliability comes from applying old distributed-systems patterns — circuit breakers, rate limits, retries — to a new substrate, or that replay-based testing beats trying to force LLM determinism). That connective pattern only becomes visible once ideas from unrelated sources sit next to each other in one file, which is exactly what a “confident” auto-router would prevent, since it would have already scattered each idea into a separate project bucket where they’d never be read together.

Where this could go

The next real step is making the review loop itself less manual — right now “periodic offline review” means I open the file and read it, which doesn’t scale past a few dozen entries. A natural extension is a lightweight second pass that clusters the accumulated ideas, flags recurring themes across sources, and proposes candidate new projects when a cluster gets large enough to justify one — turning the container from a passive parking lot into something closer to the STORM-style multi-lens synthesis pattern that shows up in some of the captured ideas themselves.

The pattern generalizes past a personal tool. Any organization running ticket-based or project-based work has the same three-way split: things that clearly belong somewhere, things that clearly need a new initiative, and an uncomfortable middle bucket that most tooling doesn’t represent at all. Jira, Linear, and similar trackers force everything into an existing epic or a backlog with no owner; almost none of them have a first-class “unsorted, needs human triage, review this weekly” state with confidence-based routing feeding into it. Building that as an explicit, reviewed state — rather than an accidental catch-all everyone quietly ignores — is a small structural change that would materially cut down on ideas that die simply because there was nowhere honest to put them.

Takeaway

Not every well-designed system component is where you build the “smart” part — sometimes the useful piece is explicitly admitting uncertainty and creating a durable, reviewable place for it, instead of pretending every input has a confident answer.

Text summarized and optimized using Anthropic’s models and reviewed by a human.