I never thought I would be saying this, but an LP's inception-to-date PCAP should always reconcile exactly to its current NAV allocation.
If you don't know what that means, neither did I. But after three months at Hanover Park, I can say it with my chest.
We do not sell a SaaS tool. We build the platform our internal accounting team uses to deliver results for clients.
Being an engineer here means to solve problems for fund accountants who have spent their careers in a domain you know nothing about. And the domain is unforgiving: these are the numbers behind some of the best investment firms in the world. They have to be correct.
Meanwhile, the firm is growing, and features ship at a pace that AI has only accelerated. How can one person keep track of it all?
The answer is to fight fire with fire.
An infinite barrage of context from Slack messages, meetings, and code changes demands an equally fast way to ingest, synthesize, and act on it. So I built one: a knowledge base that helped me onboard at Hanover Park and become productive in about half the time it had taken me elsewhere.
Nobody asked me to build it. Hanover Park gives engineers an agent stipend for experimentation, and the connections I needed already existed: Slack, Linear, GitHub, Granola transcripts, and read access to our production and development databases.
I just started building.
TL;DR: a git repo of Markdown files that agents keep up-to-date by syncing Slack, Linear, GitHub, and recorded meetings into it every day. The agents file the information, and I get a coding agent that already knows what my team decided and why.
The Structure
At its core, this is a Markdown repository. Its power comes from the layout, which combines Tiago Forte’s PARA method with the Johnny.Decimal numbering system.
00-meta/
01-projects/
02-areas/
03-resources/
04-archive/
05-writing/
06-people/
07-decisions/
08-attachments/
09-meetings/
inbox/
outbox/
AGENTS.md / CLAUDE.md / CODEX.md
Because everything is plain Markdown, any agent can operate on it. I use Claude Code and Codex interchangeably, but you could just as easily point Cowork or an OpenClaw-style agent at it.
The Central Nervous System: 00-meta/
Every agent session starts here: my top-level AGENTS.md points into this folder, which tells agents how to read and write everything else.
Most of it is plumbing: a map of where everything lives, frontmatter contracts and templates for each note type, git workflows, and pointers to the recurring routines like triage and weekly review.
It also carries the hard rules:
Never edit an accepted decision. Supersede it with a new note.
Never rewrite git history.
Never delete files.
Never send messages automatically.
No emojis or em dashes.
But, as the great United States Constitution has taught us, any living document must be able to change. Amendments land as new entries in an append-only log in 07-decisions/.
The Rest of the Body
01-projects/ contains bounded work with a deadline and a defined end state.
02-areas/ contains ongoing responsibilities with no end date, such as the part of the platform I own indefinitely.
03-resources/ contains fund accounting concepts, engineering conventions, and other knowledge that remains true regardless of what I am working on this week.
04-archive/YYYY/ is where projects go after they ship. Archived does not mean dead. When an incident touches something I built months ago, the reasoning is still retrievable instead of scattered across old Slack threads.
05-writing/ contains drafts, plans, communications, and posts, including the one you are reading. Much of the actual thinking happens here before any code gets written.
06-people/ contains one note per person. What I learn about someone during our meetings and 1:1s.
07-decisions/ is the append-only, numbered log of decisions about the system itself. Old decisions are marked as superseded, never rewritten.
08-attachments/YYYY/MM/ contains binaries such as PDFs, screenshots, and slide decks. Keeping them separate leaves the knowledge itself as plain text that is easy to search.
09-meetings/ contains verbatim meeting captures, mostly from Granola. Synthesized takeaways are filed into whichever project or area the meeting was actually about.
inbox/ holds raw material that has not yet been routed confidently. It is cleared every morning by /daily.
outbox/ holds drafted messages that a human can review and send. This is the system’s hardest boundary: it can write anything, but it cannot hit send.
The Central Nervous System: 00-meta/
Every agent session starts here: my top-level AGENTS.md points into this folder, which tells agents how to read and write everything else.
Most of it is plumbing: a map of where everything lives, frontmatter contracts and templates for each note type, git workflows, and pointers to the recurring routines like triage and weekly review.
It also carries the hard rules:
Never edit an accepted decision. Supersede it with a new note.
Never rewrite git history.
Never delete files.
Never send messages automatically.
No emojis or em dashes.
But, as the great United States Constitution has taught us, any living document must be able to change. Amendments land as new entries in an append-only log in 07-decisions/.
The Rest of the Body
01-projects/ contains bounded work with a deadline and a defined end state.
02-areas/ contains ongoing responsibilities with no end date, such as the part of the platform I own indefinitely.
03-resources/ contains fund accounting concepts, engineering conventions, and other knowledge that remains true regardless of what I am working on this week.
04-archive/YYYY/ is where projects go after they ship. Archived does not mean dead. When an incident touches something I built months ago, the reasoning is still retrievable instead of scattered across old Slack threads.
05-writing/ contains drafts, plans, communications, and posts, including the one you are reading. Much of the actual thinking happens here before any code gets written.
06-people/ contains one note per person. What I learn about someone during our meetings and 1:1s.
07-decisions/ is the append-only, numbered log of decisions about the system itself. Old decisions are marked as superseded, never rewritten.
08-attachments/YYYY/MM/ contains binaries such as PDFs, screenshots, and slide decks. Keeping them separate leaves the knowledge itself as plain text that is easy to search.
09-meetings/ contains verbatim meeting captures, mostly from Granola. Synthesized takeaways are filed into whichever project or area the meeting was actually about.
inbox/ holds raw material that has not yet been routed confidently. It is cleared every morning by /daily.
outbox/ holds drafted messages that a human can review and send. This is the system’s hardest boundary: it can write anything, but it cannot hit send.
The Workflows
Structure is only half the system. The other half is what keeps it current without requiring me to maintain it manually.
/daily: produces my morning briefing. It reads whatever landed in inbox/ overnight, briefs me on it, and triages each item into its permanent home.
/slack-sync: pulls every Slack message I have access to, filters for relevance, and routes the signal into the right project or area note.
/linear-sync: reconciles Linear issues and projects against the plan docs and updates stale statuses.
/pr-sync: reconciles GitHub PRs against the eng plan docs, updating statuses and associating PRs with milestones.
/granola-sync: pulls recent meetings and files a synthesized note for each meeting my MCP can see, including ones I didn't attend.
The four sync routines run unsupervised on a schedule. Each checks the primary source, applies the relevant documentation changes, and commits them directly to the repository without waiting for my approval.
How I Use It
I use the knowledge base to pair-program with my agent.
It sits beside the codebase as a second working directory in every agent session. When I plan an implementation in the knowledge base, the agent is also reading the code. When I write code, the agent is also reading the knowledge base: the plan, the meeting where the scope was cut, and the Slack thread where the stakeholder explained what they actually needed.
The design documents stay synchronized with the code, and the agent writes code with direct access to its business context.
Foundational Principles
Write for the agent
This knowledge base is for the agent to read, not for you.
The notes will be verbose. Some will look like AI slop. Making every intermediate document concise and pleasant for a human to read is a waste of time. The notes are inputs. Spend your energy improving the outputs.
Let the agent cook
Do not review everything the agent adds. Some details will be wrong or misinterpreted. Instead, have notes link back to their primary sources, whether that is a Slack thread, pull request, ticket, or transcript.
When a claim is about to matter, check the original rather than blindly trusting the summary.
Enforce boundaries with permissions
Instructions are not security boundaries.
If an agent has permission to send messages, assume it eventually will. You could be iterating on your performance review, and it could send the draft straight to your manager. Trust me, not fun.
Ingest broadly
Meetings and conversations that seem tangential to your work can still contain useful context. They may expose a problem you can solve proactively or give you the information you need to help someone at exactly the right moment.
Much of the material will be noise, but filtering noise is the agent’s problem, not yours.
The Outcome
Yesterday, someone asked me about an intricacy in how one of our libraries parses Excel files. I had noticed the behavior a month and a half earlier. In less than a minute, I pulled up the exact steps required to reproduce it.
The line from the beginning, how an LP’s inception-to-date PCAP reconciles exactly to its current NAV allocation, describes the system I now own.
I learned what it meant one edge case at a time: a statement pointing to a superseded report and a backfill quietly skipping funds that had no statement to drive it. Every issue became a note on the day it happened. Every note was waiting when the same shape of bug appeared again. That is how you go from not knowing what a PCAP is to owning the reconciliation three months later.
Come to Hanover Park. You can just do things here.
Evan Segaul | Member of the Technical Staff
