Here's what Daniel sent us this time — he's been thinking about what happens when AI agents start generating documentation inside software projects. The agents are already writing readmes, architecture decisions, explaining how things work. But that documentation needs to be readable and editable by humans too. Having an agent say "you keep your wiki, I'll keep mine" is a terrible pattern. It splits the source of truth and the two versions inevitably drift apart. So the real question is, what does an AI-native knowledge platform actually look like? Something built from the ground up for both audiences — machines and humans — sharing the same store. He wants us to explore five dimensions: machine-friendly structure, human-friendly editing, provenance and attribution, conflict resolution, and the single shared store versus the two-wiki problem.
This is one of those questions where the moment you hear it, you realize we've been sleepwalking into the problem. And I've been tracking a few threads on this. The short version is that most of the tools we use today — Obsidian, Notion, Confluence, even plain markdown in a git repo — they fall into one of two camps. Either they're built for humans with APIs bolted on afterward, or they're structured data stores that humans find miserable to read. Nobody has really nailed the in-between.
The uncanny valley of documentation.
And the valley is getting crowded. Let me give you a concrete example of what breaks. An AI agent writes a pull request description that explains why it chose a particular caching strategy. That description lives in GitHub, which is fine for developers. But the product manager who needs to understand why the latency numbers changed doesn't live in GitHub. And the next agent that joins the project six months later has no way to query the reasoning behind that decision unless someone manually cross-referenced it into a wiki. So you end up with three audiences — the human developer, the human non-developer, and the AI agent — all needing the same information in different shapes.
Three audiences, one document. That's a formatting nightmare before you even get to the collaboration layer.
Right, and the formatting part is actually solvable. The harder problem is the collaboration model itself. Let's walk through the five dimensions Daniel laid out. Machine-friendly structure and APIs first — this is the one where most existing tools fail in a very specific way. They expose a REST API that lets you create and update pages, but the underlying data model is a document. A big blob of rich text or markdown. An AI agent trying to answer a question like "what are all the rate limits across our microservices" has to parse natural language documents to extract that. It's doing information extraction, not information retrieval.
You're saying the structure needs to be semantic, not just textual.
Imagine a knowledge store where every fact, every decision, every constraint is a discrete, typed node. Not a paragraph — a node. "The payment service has a rate limit of five hundred requests per second" is one node. "That limit was chosen because the downstream bank API throttles at six hundred" is another node, linked to the first. An agent can query those directly. A human can read them in a rendered view that stitches the nodes into prose. Same data, two presentations.
This sounds like the semantic web again. Every five years someone revives the semantic web and every five years it collapses under its own weight.
I knew you'd go there.
Because I've been napping through the same cycle since the two thousands.
The semantic web failed for a specific reason. It asked humans to annotate everything manually. Triple stores, RDF, ontologies — brilliant ideas that required enormous upfront effort from people who got zero immediate benefit. The person doing the tagging never saw the payoff. That changes when the annotator is an AI agent. The agent can structure the knowledge as it creates it, at effectively zero marginal cost. The human never has to think about the schema.
The machine does the semantic lifting and the human just reads the pretty version. That's the pitch. But it assumes the agent's structuring is correct, which —
Is a massive assumption, yes. Which brings us to provenance and attribution. That's Daniel's third point. Every node, every edit, every link needs to carry metadata about who or what created it, when, and with what level of confidence. If an agent extracted a rate limit from a code comment, that's a different provenance than if it was stated in a formal architecture decision record. The platform needs to track that distinction and surface it. So when I'm reading a claim about the payment service, I can see "this was inferred by an agent from a code comment with medium confidence" versus "this was written by the platform architect and reviewed.
Confidence levels displayed to the reader. That's interesting. It's like putting a credibility watermark on every sentence.
Not just credibility — editability. If I see a fact that was inferred by an agent, I should be able to correct it. And when I correct it, that correction should propagate. The agent that originally wrote it should be able to learn from the correction. And other agents querying the knowledge base should see the updated version, not the stale one. This is where the single shared store becomes non-negotiable. If the agent has its own internal knowledge and the humans have a wiki, my correction only fixes the human side. The agent keeps operating on the bad information.
That's the drift problem Daniel described. Two versions of the truth, slowly becoming strangers to each other.
The drift accelerates in both directions. The human wiki gets out of date because nobody updates it. The agent's internal representation gets corrected in one conversation but not another. Six months in, you have two fictional accounts of your own system.
Like having two historians writing about the same war but they're not allowed to read each other's work.
One of the historians is making things up occasionally.
Let's talk about what's actually being built. You mentioned you've been tracking threads. Who's working on this?
A few different camps. The Obsidian ecosystem is the most interesting to watch because it's closest to the markdown-and-local-files model that Daniel mentioned. There's a plugin ecosystem emerging around agent integration. People are building tools that let AI agents read and write directly to Obsidian vaults. But here's the limitation — Obsidian's data model is still a folder of markdown files. The agent reads them as text, writes them as text. There's no structured query layer. It's an agent using a text editor, not an agent collaborating in a knowledge system.
It's like giving a robot a typewriter and calling it a co-author.
And that's exactly the ceiling. The robot can type, but it can't think in the document's terms.
What about Notion? They've been pushing AI features hard.
Notion is an interesting case because they've been adding AI on top of their existing block-based editor. Their AI can summarize pages, generate content, answer questions about your workspace. But it's fundamentally an assistant bolted onto a human tool. The agent doesn't have first-class authorship. It generates text that a human then accepts or rejects. There's no concept of an agent maintaining its own structured knowledge that the human can also browse and edit. It's a writing aid, not a collaborator.
First-class authorship for agents. That's a phrase that's going to make some people deeply uncomfortable.
But the alternative is exactly the two-wiki problem. Either the agent is a first-class author with tracked contributions, or it's generating content that gets silently absorbed into the human wiki with no provenance. The second option feels more comfortable but it's actually worse — it hides the agent's role entirely.
It's the difference between acknowledging your co-author and plagiarizing from an intern you don't pay.
The intern never gets corrected because nobody knows which parts they wrote.
Let's get concrete. If we're designing this platform from scratch, what's the architecture? You mentioned typed nodes earlier.
I think the core data model is a graph of atomic assertions. Each node has a type — could be a fact, a decision, a constraint, a question, a dependency. Nodes link to each other with typed relationships — "justifies," "contradicts," "implements," "depends on." The rendering layer assembles these into human-readable documents on the fly. You're not editing a document. You're editing nodes that get composed into documents.
The document is a view, not the source of truth.
And you can have multiple views of the same nodes. The developer sees a technical specification. The product manager sees a capability summary. The agent sees a structured query interface. All backed by the same graph.
This sounds expensive to build and maintain. Who's going to define the node types? Who maintains the ontology?
This is where the AI-native part becomes crucial. In the old semantic web model, a committee spent two years defining an ontology for software architecture. In an AI-native platform, the agent proposes node types as it goes, based on what it's documenting. The human can accept, reject, or modify those types. The schema emerges from use, not from upfront design. And the platform learns — if every project dealing with APIs ends up with similar node types, those types become templates.
That's either brilliant or the fastest path to complete chaos I've ever heard.
It's both, which is why conflict resolution — Daniel's fourth point — becomes the hardest technical problem in the stack. You've got humans and agents editing the same graph simultaneously. An agent updates a rate limit node from five hundred to seven hundred based on a code change it just made. Simultaneously, a human architect updates the same node to four hundred because they decided to throttle more aggressively. Now you have a conflict. How do you resolve it?
In git, you'd get a merge conflict and someone has to manually choose.
In a knowledge platform, manual resolution doesn't scale when you have dozens of agents making hundreds of edits per day. You need a conflict resolution strategy that's aware of provenance and confidence. The platform should be able to say: "This node was last edited by a human architect with explicit authority over rate limiting policy. An agent is now proposing a change based on code inference. The agent's confidence is high because the code is unambiguous, but the human's authority is higher. Flag for human review, don't auto-merge.
It's not just version control — it's authority-weighted version control.
With a feedback loop. When the human resolves the conflict, the agent learns. Next time it encounters a similar situation, it might flag the conflict differently or even refrain from making the edit because it knows rate limits are human-governed in this project.
This is starting to sound like a governance system more than a documentation tool.
That's exactly what it is. And that's why none of the existing tools handle it well. Git is a version control system, not a governance system. Wikis are publishing platforms, not governance systems. Notion is a collaboration tool with version history, not a governance system. The AI-native knowledge platform is fundamentally a governance system for shared truth between humans and agents.
Governance system for shared truth. That's a hell of a product category.
I think we're going to see it emerge from a few different directions. The database companies are going to approach it from the structured query side — think of something like a collaborative knowledge graph with a natural language interface. The documentation tools are going to approach it from the authoring side — think of a next-generation Obsidian that treats agents as first-class contributors. And the AI platforms themselves — Anthropic, OpenAI, Google — they're all building their own internal knowledge systems and some of that will leak into their product offerings.
You mentioned Anthropic. The Claude model has a concept of projects and knowledge bases already. That's a primitive version of this, right?
It's a start. You can upload documents and Claude can reference them. But it's still fundamentally a retrieval system. The agent reads your documents, it doesn't co-author them. There's no bidirectional sync. If Claude learns something during a conversation, that knowledge doesn't get written back to the knowledge base unless you manually copy it over.
It's read-only for the agent. Which means it's not a collaboration, it's a briefing.
A briefing is a great way to put it. And briefings go stale. The agent gets briefed on Monday, learns new things during the week, and by Friday it's operating on a mix of Monday's briefing and its own inferences with no way to push those inferences back into the shared store.
Let me push on something. You're describing a fairly elaborate system — typed nodes, emergent ontologies, authority-weighted conflict resolution, bidirectional sync. But Daniel's prompt mentioned that tools like Obsidian can technically do the job with plain markdown. Is there a simpler path here? Something that doesn't require building a whole new category of software?
I think there's a spectrum. At one end, you have the minimal approach — plain markdown files in a git repo, agents and humans both committing changes, using pull requests for review. That works today. It's what a lot of teams are already doing. The limitations are that agents can't query the knowledge base semantically, humans have to manually review every agent PR, and there's no structured metadata layer.
It works at small scale. The question is where it breaks. I think it breaks at three points. First, when the volume of agent-generated content exceeds what humans can review. Second, when the knowledge base needs to serve different audiences with different views. Third, when agents need to query the knowledge base programmatically to make decisions.
The breaking point is when agents become primary consumers of the knowledge, not just producers.
And that's already happening. If you have an agent that's responsible for maintaining a microservice, that agent needs to query the knowledge base to understand constraints, dependencies, and past decisions. If the knowledge base is a folder of markdown files, the agent is doing natural language processing on every query. That's slow, expensive, and error-prone. If the knowledge base is a typed graph, the query is precise and fast.
The markdown approach is the CSV of knowledge management. It'll get you surprisingly far, but eventually you need a database.
The transition from CSV to database is painful if you haven't planned for it. Which is why I think the platform Daniel's imagining needs to exist sooner rather than later. The longer teams operate with agents and humans maintaining separate or semi-separate knowledge stores, the harder the migration becomes.
Let's talk about what human-friendly editing actually means in this context. Because you can have the most elegant graph database in the world, but if humans have to fill out forms with fifty fields to add a single fact, they won't use it.
This is the killer UX problem. The editing interface has to feel like writing, not like data entry. I think the model is something like — you write in natural language, the platform parses your writing into nodes automatically, and it shows you the parsed structure as a subtle sidebar or overlay. You can ignore it entirely, or you can dive in and adjust the structure if the parser got something wrong.
The AI is doing the structuring on the fly, as you type.
You write a paragraph about the payment service rate limit. The platform recognizes "five hundred requests per second" as a constraint, links it to the payment service node, and flags that it contradicts a previous constraint of three hundred that someone else wrote six months ago. It surfaces the contradiction without forcing you to think in nodes.
That's the dream. The reality is probably going to be a lot messier. The parser will get things wrong, the contradictions will be false positives, and people will get frustrated and go back to Google Docs.
The first generation will absolutely be messy. But I think the thing that makes it viable is that the cost of messiness is lower than the cost of drift. A platform that gets structuring right eighty percent of the time and lets you fix the other twenty percent is still dramatically better than a platform where the structuring doesn't exist at all and your knowledge base is an undifferentiated soup of text.
The perfect is the enemy of the good, and the good is the enemy of the two-wiki disaster.
That should be on a t-shirt.
I want to zoom out for a second. We've been talking about software projects because that's Daniel's context. But this problem generalizes way beyond code. Law firms, medical practices, research labs, newsrooms — any domain where knowledge is accumulating and needs to be shared between humans and AI agents.
Medical is the one that keeps me up at night, in a good way. Imagine a hospital knowledge base where clinical guidelines are maintained collaboratively by human doctors and AI diagnostic agents. The agents are reading every new paper, every new trial result, and proposing updates to treatment protocols. The human doctors review and approve. The provenance tracking is literally life and death — you need to know whether a treatment recommendation came from a human specialist or an AI inference, and with what confidence.
The regulatory implications. If a treatment protocol was updated by an agent and approved by a human who spent four seconds glancing at it, is that human approval meaningful? Does the platform need to track not just who approved it but how much attention they paid?
You're describing an audit trail for attention. Which sounds dystopian until you realize it's exactly what we need. If the platform can show that a human spent forty-five seconds reviewing a change before approving it, that's a very different liability picture than a human who bulk-approved fifty changes in two minutes.
The platform as liability management. Another product category.
I'm going to pivot to something more immediate. There's a project called Architecture Decision Records — ADRs — that's been gaining traction in software teams. The idea is that every significant architectural decision gets documented in a standardized format: title, status, context, decision, consequences. It's lightweight and it's structured enough that tools can parse it. I think ADRs are a glimpse of what the node type system looks like for software projects. They're already semi-structured. An AI-native platform would take that further — making ADRs queryable, linkable, and co-authored by agents.
The ADR format already has a concept of status — proposed, accepted, deprecated, superseded. That maps pretty cleanly to what you were saying about confidence and governance.
I think the path from today's tools to the platform Daniel's describing goes through ADRs and similar semi-structured formats. You start by standardizing the structure of specific knowledge types — decisions, constraints, dependencies. You build tooling that agents and humans can both use to create and query those structured records. Then you gradually expand the set of knowledge types until you've covered most of what the team needs to document.
Gradual structuring rather than a big bang ontology. That's more plausible.
It's happening already. There are tools that auto-generate ADRs from pull request discussions. There are tools that check for consistency across ADRs. The pieces are being assembled. What's missing is the unified platform — the single shared store with provenance, conflict resolution, and bidirectional sync.
Let me ask the skeptical question. Is this actually a new platform, or is it a feature that gets added to existing platforms? Could GitHub just add a knowledge graph layer on top of repositories and solve eighty percent of this?
GitHub could absolutely solve a big chunk of it for the software development use case. They already have the collaboration model, the version control, the pull request workflow. Adding structured knowledge nodes with agent-first APIs is a natural extension. But GitHub's model is fundamentally repository-centric. It doesn't work well for the product manager who doesn't use git. It doesn't work for the legal team or the medical practice. So I think you get a GitHub-shaped solution for software, and you get other solutions for other domains.
No one platform to rule them all.
But the primitives — typed nodes, provenance tracking, authority-weighted conflict resolution, bidirectional sync — those are going to be common across all of them. The domain-specific part is the ontology and the rendering.
Let's talk about the open source dimension. Daniel's an open source developer. If this platform is going to be the source of truth for projects, there's a strong argument that it needs to be open source itself. You don't want your knowledge infrastructure owned by a single company.
Especially given what's happening with AI regulation and platform control. I saw the Economic Times piece about Lutnick's Anthropic crackdown. The regulatory landscape around AI is shifting fast. If your knowledge platform is proprietary and the vendor changes their terms or gets acquired or goes out of business, you're in trouble.
Or if the vendor decides certain types of knowledge are problematic and starts moderating your internal documentation.
That's the nightmare scenario. An open source core with a managed hosting option feels like the right model. Something like GitLab's approach. But the challenge is that the AI components — the parsing, the structuring, the conflict resolution — those require models that are expensive to run. An open source platform that depends on proprietary AI APIs isn't truly open.
You need the platform to be model-agnostic. It should work with whatever AI the team is using, including local models.
That's actually a strong argument for keeping the data model simple and standards-based. If the knowledge graph is stored in an open format — something like a typed extension of markdown, or a JSON-based graph format — then any model can work with it. The platform provides the storage, the rendering, and the collaboration primitives. The AI integration is a plugin.
A plugin architecture for AI agents. That's appealing. It means the platform doesn't have opinions about which models you use or how you use them. It just provides the shared store and the governance layer.
It future-proofs the platform. The AI landscape in two years is going to look completely different from today. If your knowledge platform is tightly coupled to a specific model or provider, you're building on sand.
Alright, let's try to synthesize. If someone were going to build this platform today, what's the minimum viable product? What are the three features that actually matter?
Number one, a graph data model with typed nodes and links, stored in an open format. Number two, a bidirectional API that lets both humans and agents read and write with equal privilege and tracked provenance. Number three, a rendering layer that assembles nodes into human-readable documents on the fly. Everything else — the emergent ontology, the authority-weighted conflict resolution, the attention audit trail — those are version two and three.
Number one and number two are the ones that break the two-wiki pattern. Number three is what makes it usable for humans.
And I think number two is the hardest. Building an API that treats agents as first-class authors means designing an authentication and permission model that distinguishes between human identities and agent identities, allows both to hold edit privileges, and tracks every change to its source. That's a nontrivial identity and access management problem.
Especially when agents are acting on behalf of humans. If I ask my agent to update the rate limit documentation, is the edit attributed to me or to the agent?
The edit metadata should say "edited by Agent X, acting on behalf of Corn." And if you later review and approve the edit, that adds another layer of provenance. The platform needs to handle chains of attribution, not just single-source attribution.
This really is a governance system.
It really is. And governance systems are hard to build and harder to adopt. But the alternative is worse. The alternative is every team, every organization, every project slowly bifurcating into two parallel realities — the human reality and the agent reality — with no guarantee that they agree on anything.
That's the closing thought right there. The cost of not building this platform is a world where humans and AI agents operate on increasingly divergent understandings of the same systems. And the divergence compounds.
That's the term. Every day that the two stores drift apart, the cost of reconciling them grows. At some point, reconciliation becomes impossible and you have to start over. That's the argument for building this now, before the drift becomes catastrophic.
Before we're all reading different maps of the same territory.
Acting on them.
Now: Hilbert's daily fun fact.
Hilbert: In the nineteen seventies, researchers studying moss on the Solomon Islands discovered that certain moss colonies produce faint ultrasonic clicks when their spore capsules dehydrate and rupture, creating a soundscape inaudible to human ears but detectable with bat-detection equipment — essentially, moss reproduction has an acoustic signature.
Moss has a soundtrack.
Ultrasonic moss pops. I'll never walk through a forest the same way.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you listen — it genuinely helps. Find full transcripts and more at myweirdprompts dot com. I'm Corn.
I'm Herman Poppleberry. See you next time.
