In April 2026, two different stories broke into the conversation within the same week.
Andrej Karpathy shared how he builds an LLM knowledge base with Obsidian, and the post spread quickly. Around the same time, Stripe Minions kept drawing attention because agents were reportedly writing and merging more than 1,300 PRs per week.
On the surface, those look like different stories. In practice, they point to the same truth.
What determines agent performance is not the model. It is context.
What Karpathy showed: knowledge has to be structured
Karpathy's system is simple. You drop raw material into raw/, then let an LLM compile it into a wiki. No vector database. No elaborate RAG pipeline. Markdown and grep are enough.
The core analogy is sharp: Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.
That works because the LLM is not just retrieving knowledge. It is structuring the knowledge itself. It understands the shape of the house because it helped organize the rooms.
But the limits are also clear.
- It is built for one person. Person A's wiki and person B's wiki do not naturally connect.
- It works at file level. Pulling out a specific insight cleanly is much harder than referencing a smaller unit.
- Sharing is awkward. Merging markdown vaults with Git is file sync, not real knowledge infrastructure.
- Agents cannot natively share the structure. One agent's private wiki is not a protocol that another agent can query.
Karpathy's setup is a powerful tool for an individual thinker. Most real work, however, happens in teams.
What Stripe Minions proved: context is infrastructure
Stripe Minions shows the same principle from a different angle.
The reason Minions can produce more than 1,300 PRs per week is not simply better models. It is the organizational infrastructure Stripe built over years. devbox, more than 500 internal tools, 3 million tests, and blueprint architecture all give agents the context required to code in a way that is recognizably Stripe.
ByteByteGo captured the core issue well: AI coding tools are fast and capable, but fundamentally context-blind.
An agent can be very capable and still fail if it does not know:
- why the team chose this architecture
- what historical meaning a code pattern carries
- what a specific term means inside this organization
Stripe solved that problem through years of engineering investment. Most teams cannot.
What ordinary teams actually need
If you place the two examples side by side, the required ingredients become clear.
| Perspective | Karpathy (Obsidian) | Stripe (Minions) | What teams need |
|---|---|---|---|
| Knowledge structuring | LLM-compiled wiki | Internal tools + blueprints | Automatic structuring |
| Agent access | Local files | Internal infrastructure | Protocol-level access |
| Team sharing | Single-user | Organization-wide | Shared team knowledge space |
| Build cost | Low | Very high | Reasonable cost |
| Unit | Document | Codebase | Atom |
The core point is simple.
Agents need infrastructure that gives them team context, but most teams cannot spend years building what Stripe built.
That is the gap Norfolk and Nexus are meant to close.
Norfolk + Nexus: infrastructure that gives teams memory
Norfolk: where team knowledge accumulates
Norfolk started as a personal knowledge tool, but its real function is broader: it structures knowledge into a form agents can actually use.
It resembles Karpathy's raw/ -> wiki flow, but there are important differences.
1. Atom-level structure
Karpathy's system compiles documents. Norfolk breaks knowledge down into Atoms, the smallest units that can be searched, combined, and linked.
For an agent, the difference is substantial. "Bring me the third insight from that document" is much easier when the system stores precise units instead of whole files.
2. Citation Graph
Norfolk tracks which Atoms support which conclusions. That means provenance is not an afterthought. It is built into the structure.
3. Team space
In the Norfolk team plan, Atoms from multiple teammates accumulate in a shared space. Personal and team knowledge remain distinct, and agents recall team knowledge according to permission.
The Norfolk plan structure is straightforward:
- Free: collect and structure text and URLs
- Paid: add images, audio, and PDFs as Atoms
- Team: operate a shared team knowledge space
Nexus: the protocol layer where agents read and write memory
Nexus is the layer that makes the knowledge stored in Norfolk usable by actual agents.
Through AMCP, the Agent Memory Continuity Protocol, any agent can recall team memory, whether it runs inside Claude Code, a custom agent, or another runtime. If MCP gives agents tools and A2A gives agents collaboration, AMCP gives agents memory.
The Nexus plan structure is:
- Free local: local memory infrastructure without embedding dependence
- Pro cloud: cloud sync and more advanced recall
- Team: shared memory for teams of agents
What a team plan makes possible
Scenario 1: a new engineer on day one
A new engineer opens Claude Code and asks, "What are our API design principles?"
Nexus recalls the relevant Atoms from the Norfolk team space. The agent can immediately bring back context such as:
- why the team prefers gRPC over REST
- the history behind the error-code system
- decisions made in the last architecture review
With Obsidian alone, the answer becomes "clone this vault and read it." With Stripe-level internal systems, the answer becomes "first learn the internal tooling." With Norfolk + Nexus, the agent starts with the context already available.
Scenario 2: knowledge transfer between agents on the same team
An agent working for teammate A discovers an important insight while debugging a production issue and stores it in Nexus. The next day, teammate B's agent faces a similar issue and recalls that insight through AMCP.
That is fundamentally different from leaving a message in Slack. A Slack message is communication for humans. An Atom is a usable unit for agents.
Scenario 3: automatic compilation of organizational knowledge
Five teammates keep working, and the Atoms they generate accumulate in a Norfolk team space. That turns Karpathy's solo wiki-compilation loop into a team-scale process.
File-level systems tend to collide. Atom-level systems can compose.
This is not a fight against Obsidian
Norfolk is not a replacement for Obsidian. Obsidian remains an excellent tool for personal thinking.
The difference is the shape of the output. Obsidian markdown is for humans to read. Norfolk Atoms are for agents to use. And Nexus, through AMCP, is the protocol layer that makes those Atoms accessible across agents.
Karpathy himself described the loop in which agents build a knowledge base and that knowledge base improves later problem solving. What we are doing is bringing that loop to the team level.
Most teams do not need to envy Stripe
Stripe gave agents organizational context through years of investment. Most teams cannot do that.
The Norfolk + Nexus team plan is a faster path to giving agents shared team memory at a reasonable cost.
It makes Stripe's principle practical for smaller teams too: the performance gap between agents is shaped less by which model a team uses and more by what memory that team can give its agents.
In the agent era, that becomes a real competitive advantage.
Get started
- Norfolk: start free and expand into a team plan
- Nexus: start local for free and grow into team memory
- AMCP Spec: an open protocol under Apache 2.0
This post is part of Nunchi AI's indie-hacker promotion experiment series.