Navigate with arrow keys or → button
The key insight isn't that you can generate a deck instantly — it's that a 5-minute conversation with an agent is now enough to produce a full presentation. You talk through the idea, riff on structure, and the document just falls out of the conversation.
The artifact is a byproduct. The thinking is the work, and 5 minutes of thinking is often enough. This can happen often — you can have these conversations daily.
Hours of work per deck. Locked into one sequence. Can't reuse pieces.
When a conversation produces a presentation, you stop thinking about making decks and start thinking about the structure above them. Just like when coding got fast, you started thinking about architecture.
The structure above presentations is the dependency graph of the knowledge they contain.
When you can have a 5-minute conversation and get a presentation, you accumulate them fast. The question becomes: how do these relate? Share the graph of related presentations — with explicit dependencies between them.
Each node is a standalone presentation. The graph shows how they compose.
Every node can be taught by itself and reused in other flows. The "CLI Basics" node serves your curriculum but also someone else's completely different one.
When you share, you make this clear by sharing the graph — so people see both the piece and where it fits.
Not prescriptive — this is what emerged in my own graph. Yours will differ.
The primitives. CLI tools, languages, protocols, data formats. Things that exist independent of any workflow.
e.g. "Git fundamentals", "JSON & YAML", "HTTP basics"
How you use the foundational pieces together. Patterns for combining tools, configuring systems, building pipelines.
e.g. "Composing CLI tools", "Agent + extension patterns"
End-to-end processes. The full path from intent to outcome, drawing on foundational + orchestration nodes.
e.g. "Ship a feature with Pi", "Deploy to production"
Meta-knowledge about creating the knowledge artifacts themselves. How to write, present, structure, share.
e.g. "Vibe-coding presentations", "Writing good READMEs"
The "Git" node appears in your coding curriculum, but also in someone else's "Open Source Contribution" curriculum, and in another person's "Technical Writing" flow.
The node doesn't belong to one graph. It lives at the intersection of many. That's the whole point.
People always say I'm a bit scattered — multiple ideas running in parallel, connecting things across domains. That's not a bug, it's a graph. The problem was never the thinking — it was that linear formats (decks, docs, emails) can't represent parallel threads with dependencies.
A knowledge graph makes the structure explicit. Instead of flattening 5 concurrent ideas into a single sequence, you show them as what they are: nodes with edges. People can enter anywhere, follow dependencies, and build their own path.
This site — p10q.com — is itself a live DAG. About is the foundation node at the bottom, Learning Resources sits on top, and everything else branches upward. Click any node on the home page and preview it without leaving the graph. The structure is the interface.
Multi-threaded thinkers can finally share how they actually think. Receivers can explore at their own pace.
Agents can consume a graph's feed.json to understand what you know, what's new, and what depends on what. No ambiguity.
A team's knowledge becomes a shared, browsable graph — not a wiki that nobody reads.
When you pass knowledge to someone, it's a "graph overlay" — your graph laid on top of theirs. The overlap is where you already agree. The new edges are the knowledge transfer.
In the future, knowledge sharing is mostly about browsing overlapping graphs.
Shared nodes: A and C — the overlap is where collaboration happens
Imagine if sharing knowledge meant sending a graph overlay. Not "here's my 40-slide deck" but "here's my knowledge graph — it shares 6 nodes with yours, here are the 3 new ones."
This works for teams (onboarding = "here's the team graph, you already know these nodes"), courses (a syllabus is a DAG, not a list), and any knowledge transfer.
The format is simple: a JSON file with nodes and edges. The rendering is up to the reader. The structure is the protocol. Subscribe to someone's graph and receive only the delta — new nodes, updated nodes, new edges. Respect people's attention.
Every graph publishes a feed.json with a version number and per-node update timestamps. When something changes, the version increments.
A subscriber gets a daily (or weekly) diff showing:
Not "here's my whole blog again" — just the Δ. Respect people's attention.
Each layer becomes trivial, so you think about the layer above it.
It's simple enough to build today:
1. A presentations.json defines nodes + edges
2. A build script generates the graph view + feed.json
3. A Lambda diffs versions daily, emails subscribers the Δ
4. Subscribers see new/updated nodes with context
This site (p10q.com) already does steps 1–2. The subscription layer is next — a Lambda that diffs feed.json versions and sends subscribers just the Δ: what's new, what changed, what got connected.
This presentation is itself a node in the graph you're browsing. On p10q.com, you can tap around the graph and preview any node without leaving. The graph is the interface — not a list of links, but a structure that shows how ideas connect. Maybe this becomes how people share what they know.