Working with an AI agent on a single task is easy. Working with one across many projects, many people, and months of history is a different problem entirely: every new conversation starts from zero, and re-explaining context costs more than the help is worth, unless that context is built once, as architecture, and reused indefinitely.
A Personal Assistant, First
It started with three questions, and none of them had an easy answer.
Cross-Project
How does it work across all my projects, not one thread at a time?
Enjoyable to Use
How does it stay easy, something I actually enjoy opening?
Self-Updating
How does it update itself as I work, with no extra step to remember?
A personal knowledge assistant, PKA, is the answer I built for myself. Markdown files stay the canonical source, one project, one client, one idea at a time, but a dashboard on top turns them into something I can actually navigate: projects, people, organizations, and key topics, each tagged and cross-linked instead of buried in a folder. This website is tracked inside it too, project notes and open to-dos, the same as anything else I'm running.
It's deliberately small: no shared hub, no routing between departments, just one person's context held somewhere other than memory and old folders. It's also the part of this that already runs, day to day, not a design waiting to be built.
The value isn't in the agent. It's in everything it already knows before you ask.
The Same Idea, at Company Scale
Scaled up, the same principle needs a bigger frame: a shared hub instead of one person's notes, and a way to route a question to whoever actually knows the answer, not just to whoever happens to be free.
This is the heavy part, not a light preliminary step. Sources are heterogeneous on purpose: structured project data, persona by persona, scattered conversations across messaging and project management tools synthesized with AI, and raw field notes written by whoever is actually running a project day to day.
Collecting it well means going back through real project history, not how flows are assumed to work, and writing the result to be read by an AI, not skimmed by a person: the same logic behind this website's own /llm/ files. None of it holds together without an audit done first, and a tagging taxonomy defined before collection starts, not fitted around it afterward.
Everything collected synthesizes into one place: project data, feedback and tickets, the persona taxonomy, and clusters of recurring issues. It stays current two ways: AI-assisted retro-tagging on the backlog, checked by a person before it's trusted, and tagging built into flows that already exist, closing a ticket, closing out a project, not a separate step nobody remembers to do.
What used to live in people's heads becomes something a team can query and actually see, through consultation and visualization layers: a cloud dashboard for the organization's own knowledge, like the one PKA already runs on, or tools like Obsidian reading the same files as a navigable graph. Not a chat window that forgets everything at the end of the session.
The same question kept landing on the wrong desk, or nowhere at all, because there was no single place to ask it. The orchestrator is that place, open to everyone in the company, and it doesn't decide anything on its own: it routes each question to the specialist who actually knows the answer, and it's the only part of the system watching both sides at once. A cluster of complaints growing in one area reaches both whoever manages those projects and whoever owns the product roadmap.
Getting this right means routing by role and by request, permissions that differ by function, and a single door in, wherever people already talk, as long as it's one door and not five.
The project side and the product side need almost opposite things from the same knowledge, so underneath the orchestrator two agents split the work. One works the project and sales side: classifying incoming projects against the persona they match, and using history to estimate timeline and expected friction before anyone commits to a date.
The other works the product side: holding the memory of what the platform is good and bad at, turning clusters of recurring issues into concrete product recommendations, and checking whether a fix actually moved the numbers, not just whether it shipped.
This is architecture that's been designed, worked through in enough detail to know where the hard edges sit. How it actually gets built, which tools, which sequence, is a decision that belongs to engineering, not to this page.
One System, Many Voices
What the system says matters as much as what it knows. The assistant is designed as a presence, not a utility: it has a name, and at company scale the name and personality follow the brand, so talking to it feels like talking to someone who already works there.
None of this speaks in a single voice. Tone follows whoever is on the other side, the same empathy applied differently each time: direct and personal when it's just me, more procedural for someone inside the company checking a process, and simpler still, more patient, for a customer who never needs to know any of this sits underneath.
What's Emerging
What changes, at either scale, isn't how much work gets done. It's what finally becomes free to think about, once remembering stops being the job.