Outro-spection
There's a word I've been looking for. Introspection is one I love — from Python, where it means looking inside an object at runtime, and from myself, where it means roughly the same thing. Whatever happens I tend to turn it inward. There's always something in that internal mirror. But lately I've been expanding the mirror outward — not looking inside myself but inside other systems, other people, other tools. And I needed a word for that direction. The one I landed on is outro-spection.
I run an introspection pass at the end of most weeks. A persona I call memory-steward goes through what happened in recent sessions: what changed, what didn't land, what the agents noticed that nobody followed up on. The output is a file I call GAPS.yaml. A structured list of things I know are missing — gaps in the toolset, patterns that keep arriving without a home, things I wish existed and haven't built yet.
GAPS.yaml is the inward-facing artifact. For a while that's where it stopped. The file grew. Gaps accumulated. I could name what was missing; I couldn't always say what to do about it.
Outro-spection is the second loop. It takes what the introspection found and turns outward — looks at what exists in the open-source world that might already fill a gap, vets one candidate at a time, and either adopts or discards. The shared artifact, the hinge between the two directions, is the same file. The same GAPS.yaml feeds both loops.
What I've found: the recommendation surface for tools is narrow. What comes up in reposts and newsletters is what's well-marketed, not what fits a specific case. The tool that fits your actual situation is often the one nobody is writing about. Outro-spection is a systematic attempt to scan more than the visible layer.
The agent structure that makes this concrete: one persona scans GAPS.yaml and searches for candidates. Another goes deep on one candidate — reads the source, runs the code, writes a verdict. If the verdict is adopt, a third writes the integration spec. The integration lands in textserve as a dark bundle — off by default, enabled per session when needed.
This is the ingest sprint What survives the chat was pointing toward when it mentioned tool discovery. That post was about building the memory engine. This is about what fills it from the outside.
Outro is not a Latin prefix. Introspection has the clean etymology — intro, within, spicere, to look. I borrowed the direction and made up the word. It felt like the right thing to reach for when the concept arrived before the vocabulary did.
The pair: introspection tells you what you're missing. Outro-spection finds what might already exist to fill it. Together they're a cadence — inward, then outward, then inward again. The same rhythm I'd use for any gap between what I have and what I need. The loop doesn't close by itself; you have to run both halves deliberately.
There's a framing from Geoffrey Litt that I keep coming back to: understanding is the new bottleneck. When code generation gets cheap, the constraint shifts to comprehension — not of what to build next, but of what already exists. He calls skipping that step "cognitive debt." The compounding is real: the faster the loop runs, the more you lose the mental model of what the loop produced.
That's what GAPS.yaml is, in one reading. Not a task list — a comprehension artifact. The introspection pass forces you to account for what exists, what's missing, and why. The outward loop forces you to look at what fills those gaps seriously rather than by drift. Both halves are a tax on speed, deliberately. The alternative is running faster into a system you no longer understand.
I don't know yet whether this generalizes beyond my own setup. It might only work cleanly when you're building your own tools and know the gaps precisely enough to state them in a file. But I think the underlying move is transferable: maintain a list of known gaps, and look outward against that list deliberately rather than waiting for something to drift into your feed.
The failure mode I'm watching for: discovery agents that search for tools have an obvious shortcut available to them. They find the well-known things, because that's what training data knows, and call it a search. The only way I know to test against that is to run the loop and compare the results against what I already knew — and see whether anything surfaces that I wouldn't have found on my own. That's the part I haven't measured yet.