Why I'm Rethinking How AI Should Actually Read with Me

I was three weeks into a dense book on distributed systems when I hit the wall. I'd asked my Claude conversation something like, "But how does this relate to the consensus problem we discussed on page 47?" and by the time I got an answer, the model had somehow conflated my question with something I'd asked 40 messages earlier about Byzantine fault tolerance. The response was technically plausible but fundamentally wrong. I had to start a new conversation, which meant losing all context. Sound familiar?

That frustration is exactly what pi-tree addresses, and honestly, reading about how someone solved this made me step back and question my entire mental model of how AI conversations should work. I've been treating linear chat threads as the only way to structure these interactions, but that's not how I actually think through complex material. I branch constantly. I explore tangents. I backtrack. Yet every tool I use forces me into a flat thread that degrades as it grows.

The Real Problem: Architecture Isn't Neutral

Here's what stuck with me: the conversation structure isn't a cosmetic choice—it's a fundamental constraint on how well the AI can actually help you understand something.

When you're reading something genuinely difficult, your mind works recursively. You encounter a concept, branch into prerequisites you're missing, explore those until you understand enough to come back to the original thread. But traditional chat applications—and I'm including the ones I use every day—flatten this entire cognitive process into a chronological pile of messages.

The result? Token waste, context pollution, and increasingly incoherent responses as the conversation grows. I've watched Claude degrade on a long thread when it should have stayed sharp. The model hasn't gotten worse; the context environment has become toxic.

Pi-tree's insight is elegant: use tree structures. Each branch carries only its path from root to current node. When you follow a tangent, you're not polluting the main thread. You're exploring in isolation, then returning to where you were with a clear context boundary.

The Technical Approach: Tools Over Retrieval

What impressed me here is the distinction between RAG and the agentic approach. I've built systems both ways, and I've felt the pain of approximate retrieval in RAG—you feed a vector database a chunk that seems semantically relevant, and it becomes plausible nonsense because it's missing structural context.

Pi-tree flips this. Instead of pre-computing embeddings and hoping retrieval finds the right piece, the AI has tools that let it fetch exactly what it needs: parse a specific chapter, search for a methodology section, query an RSS feed. It's like grep instead of fuzzy semantic search.

// This is the mental model shift—the AI asks for what it needs
pi.registerTool({
  name: "get_chapter",
  description: "Fetch a specific chapter with full context",
  execute: async (args) => {
    // Exact structural access, not approximate search
    const chapter = await services.sources.get(args.sourceId);
    return chapter.getSection(args.chapterId);
  }
});

The difference matters in production. When you're building tools that shape how an AI interacts with your content, precision beats recall. One correct piece of context is worth ten semantically similar guesses.

What I'd Actually Use This For

If I'm honest, I'd build this for research sprints. I'm often reading papers in domains adjacent to my expertise—infrastructure work occasionally requires me to understand cryptography or storage systems at a depth I don't naturally have. The current workflow is brutal: open paper, read abstract, get lost, context-switch to Wikipedia, lose the thread, start over.

With tree conversations, I could branch into definitions and background without losing my position in the argument. That's genuinely valuable.

The self-hosted angle matters to me too. I don't love the idea of my reading sessions living on some cloud platform, especially if they contain proprietary whitepapers or research notes. Local-first with support for any OpenAI-compatible API? That's production-thinking.

My Questions

I'd want to understand how the tree structure actually scales. A 50-branch tree with deep paths might still explode in context size. Does the implementation handle pruning or summarization? And how does the UI actually prevent a tree from becoming a confusing mess of collapsed nodes? I've seen tree UIs fail spectacularly when they get complex.

Also, I'm curious whether this approach works for collaborative reading. What happens when two people are exploring the same tree? Does it branch semantifically or do you get conflicts?

The plugin system looks solid—YAML for configuration, TypeScript for custom tools, MCP bridge for external services. That's the right abstraction stack. But I'd test it myself before betting my workflow on it.

The Bigger Pattern

What this really highlights is that we're still designing AI interaction patterns like they're chats, not like they're thinking tools. A linear thread is how email works, not how cognition works. Seeing someone build this makes me want to push back against the assumption that "conversational interface" must mean "threads." There's room for much better primitives.

Source: This post was inspired by "I Built an AI Reading Companion with Tree-Structured Conversations" by Dev.to. Read the original article