Is Your Digital Brain the Light Saber of the AI Era?
Jedi Knight Tools for the Knowledge Worker
My Duetto colleague Jake Becker is sharp. He’s been ahead of AI adoption on our team — experimenting early, pushing for new tools, staying current. Last week he messaged me on Slack: “I wish I had my own CTO Assistant. Like what you have.”
I paused.
I have one. I’ve had several, in different forms, going back months. But I hadn’t said anything about it publicly.
That gap — between an AI-forward person who knows the tools and a practitioner who actually has the thing — is what this piece is about.
TL;DR
Off-the-shelf AI tools are capable but contextually blind. You still have to leave your domain to get help.
Serious knowledge workers — writers, researchers, historians — have always built their own knowledge systems. Never trusted a vendor to hold their material.
Coding is shifting toward what writing has always been: directing, curating, maintaining a living body of knowledge.
Building your own AI memory and search layer is the new rite of passage. The tool you build IS the skill being developed.
The latest versions of my own stack: trusty-memory and trusty-search — both open source, both installable today.
Everyone Wants One. Few Have One.
Jake’s comment revealed something I’d been taking for granted.
The major vendors are actively working on this — memory features, RAG pipelines, personalization layers. But those solutions are optimized for breadth, not for one person’s actual work across functions.
ChatGPT, Claude, Copilot — these are all capable. They’re also still contextually blind to you. You have to leave your environment, paste in context, explain your situation from scratch, then interpret the output back into your actual work. Vendors are working on it. But the solutions remain generic, and every session still starts from zero.
I wrote about this in March — Everyone Blamed Clawd Bot’s Execution. The Concept Was the Problem. The structural flaw of universal assistants isn’t fixable. They require you to leave your context to get help. What actually works is the opposite: your tools get assistant capabilities, and assistance comes to where your context lives.
Off-the-shelf tools haven’t solved this. They’ve gotten more powerful — better reasoning, longer context, faster inference — but they still don’t know your codebase, your decisions, your institutional history, your current sprint. They know a lot about the world, and very little about you.
Jake wanted my assistant. But what he actually wants is his assistant. The one that knows what he knows.
That’s a different problem entirely.
The job changed first.
Coding Is Becoming Writing
Practitioners feel it before analysts name it.
A few years ago, being a strong engineer meant writing a lot of code quickly and correctly. Today, with agentic AI coders at their disposal, the best engineers I watch spend their time directing, reviewing, specifying, and curating. The unit of work has moved up a level. Implementation is increasingly delegated. Judgment — about architecture, trade-offs, what to build and why — is the differentiator.
This is not what happens when automation replaces a skill. It’s what happens when a new discipline appears.
Writers have always worked this way. A novelist doesn’t produce words per minute as a primary metric. They produce decisions — what to say, in what order, with what emphasis. The words are the output of the decisions, not the work itself. What makes a writer productive over a career isn’t typing speed. It’s having a system: notes, research, accumulated material, patterns of thought that compound over years.
Some (typically senior) engineers are arriving at the same realization. Your value isn’t the code. It’s the judgment, the accumulated context, the knowledge of what was tried and why it failed. The question is whether that accumulates in your head alone — which doesn’t scale, and doesn’t survive a context switch — or whether it lives in a system.
Good engineers who learn to use their AI tools effectively generate better code — the stack amplifies judgment and accumulated knowledge. The gap isn’t between skilled and unskilled engineers in isolation; it’s between engineers who’ve wired their knowledge into their tools and those who haven’t. The knowledge is real in both cases. Only in one case does it compound.
The writers I’ve observed who sustain serious output over decades all have the same property: they know where things are. Their research is retrievable. Their earlier thinking is available to their current thinking. The system makes the person bigger than their working memory.
That’s the gap.
Writers Don’t Trust Vendors With Their Material
Niklas Luhmann, a German sociologist working in the 1950s, produced 70 books and nearly 400 articles over his career. I haven’t written a book yet — but I have published over 200 articles at HyperDev. Worth naming the parallel. He credits his output to his Zettelkasten — a slip-box system of 90,000 interconnected index cards, each with a unique identifier linking it to related thoughts. Not a filing cabinet. A network of ideas that got richer with every addition.
And it’s worth asking: is that so different from what an AI knowledge system does today? The Zettelkasten was an analog precursor to what trusty-memory and trusty-search do programmatically — indexing ideas, linking related thoughts, surfacing connections that wouldn’t otherwise be visible. Luhmann was doing manually what these tools do automatically. Same architecture. New substrate.
He didn’t use a vendor product. He built a system that reflected how he thought. The architecture of his Zettelkasten was itself an expression of his intellectual method.
This isn’t a historical quirk. It’s a pattern. Serious knowledge workers have always built their own systems — commonplace books, research archives, private wikis. The reason is structural: the schema you design reflects how you think. That’s not something a product gives you. A product gives everyone the same schema.
Andrej Karpathy pointed at something similar last month with his LLM Wiki gist. His framing: use LLMs not just to write code, but to build and maintain a personal knowledge base. “Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase.” Three folders, structured Markdown, a large context window. He concluded: “I think there is room here for an incredible new product.”
He’s right there’s room. I wrote about his framing in What’s In Your Second Brain? The product comment is where I’d push back. You can build tooling around the pattern. You can’t productize the schema. The schema is the moat — because it reflects how you think, not how a product manager thinks you think. The ones who get it aren’t waiting for a product.
The Lightsaber Rite of Passage
In Star Wars canon, a Padawan doesn’t receive a lightsaber. They build one.
The ritual is called the Gathering. Initiates travel alone to the Crystal Caves of Ilum. They have to find their kyber crystal — the crystal that’s attuned to them through the Force. The caves are shaped by the initiate’s own fears and insecurities. The crystal doesn’t go to the strongest or the fastest. It bonds with the person who confronts what’s in the way.
Then they build it themselves, guided by Professor Huyang.
You can’t buy this. You can’t inherit it. The construction is the training. The tool reflects the builder.
I’m not the first to reach for this metaphor in tech. But I think it lands differently now. Building your own AI memory and search layer isn’t just useful. It’s diagnostic. You can’t do it without confronting what you actually know, how you actually think, what deserves to persist and what doesn’t. The schema you design for your knowledge base is a statement about your mind.
The engineers I know who are operating at the highest level right now — CTOs, senior architects, tech leads at places moving fast — they all quietly roll their own. They don’t announce it. They just have it.
My Own Lineage
I’ve been building versions of this for months.
trusty-izzie was the first — a simple wrapper. Then ai-commander, a more structured approach to context management. Then open-mpm and claude-mpm, which was where I started thinking seriously about multi-agent orchestration. Then kuzu-memory, a graph-backed memory layer. Then mcp-vector-search, semantic search over my entire codebase.
Each iteration taught me something about what I actually needed. Not what I thought I needed. What the practice revealed.
This piece was drafted with a configured writing assistant — claude-mpm loaded with my publication style guide, my voice patterns, my article archive. That’s a saber too. Not a generic chat interface. A tool shaped around how I think and write, producing work I can actually publish rather than work I have to fix. The saber list keeps growing.
The latest two are the most capable tools I’ve built.
The Latest Sabers
trusty-memory is a machine-wide AI memory daemon written in Rust. It uses what I call the Memory Palace architecture — multiple named palaces, each for a different domain. Sub-5ms baseline retrieval on Apple Silicon. It runs as an MCP server for Claude Code, which means my assistant stores and retrieves memories automatically, across sessions, without me managing any of it explicitly.
cargo install trusty-memoryAvailable at crates.io/crates/trusty-memory.
trusty-search is a machine-wide hybrid code search daemon, also in Rust. Always-on, one install per machine. It combines BM25 lexical search with HNSW vector search (all-MiniLM-L6-v2 INT8) and a Knowledge Graph with 1-2 hop expansion, fused via Reciprocal Rank Fusion. It exposes an MCP server with 11 tools. Stdio and HTTP/SSE transports drop straight into Claude Code.
cargo install trusty-searchAvailable at crates.io/crates/trusty-search.
These tools, along a set of custom reporting pythons apps along with a custom Slack Bot I use to access the data remotely, comprise my digital brain.
These aren’t products I bought. These are tools I built, iterated, and use daily. They know my codebase the way a Zettelkasten knows a scholar’s intellectual territory — not because a vendor configured them, but because I did.
To be precise: trusty-memory and trusty-search are infrastructure utilities — the memory layer and the search layer. Building the actual assistant that uses them is a separate act of customization. That’s where the lightsaber metaphor completes: the kyber crystal is only part of it. The construction — what you build with the crystal — is the saber.
When Jake said he wished he had a CTO Assistant, this is what he was gesturing at. Not a prompt template. Not a workflow. A living knowledge layer that compounds.
The Right Question
Jake asked: “Can I get a CTO Assistant?”
That’s the wrong question. It assumes the thing is available off the shelf, and the task is finding and configuring it.
The right question is: “What would it take to build one that knows what I know?”
That question is harder. It requires confronting the shape of your knowledge, what’s worth persisting, how to structure retrieval. It’s uncomfortable in the same way the Crystal Caves are uncomfortable — not because the work is technically difficult, but because you have to be honest about what you actually have.
Not everyone needs to write Rust. The specific technology isn’t the point. The point is that the engineers asking the right question are already operating differently. They’re working like writers — maintaining a living body of knowledge, building systems that compound, treating their accumulated context as an asset rather than a liability.
Writers’ discipline has been creeping into engineering for a while. AI made it urgent.
If you’re waiting for a product to hand you the thing, you’re waiting for someone to build your lightsaber. It won’t be yours.
Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.
Related reading:
What’s In Your Second Brain? — Karpathy’s LLM Wiki and the case for a compounding knowledge layer
Everyone Blamed Clawd Bot’s Execution. The Concept Was the Problem. — Why universal assistants are architecturally broken
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners
LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders