Technical

Exhaust Every Branch of an Idea

In a chat, you pick one thread and lose the rest. In a tree, you walk down every branch -- follow-ups, challenges, edge cases -- and nothing gets left behind. Keep going until every open question is resolved.

Deep dive into your idea See example ↓

Explore the whole book

A complete, accurate map of Harari's Sapiens, zoomed out to the whole arc so you can zoom into any chapter and branch off with your own questions.

Open the full map

How it works

In a chat, you follow one thread. If you want to explore a tangent, you leave the main path behind. In a tree, every question you ask opens a new branch. You can follow it as deep as it goes, then come back and pick up exactly where you left off.

Start with your idea or plan. State what you’re thinking and why. The AI responds, and now you have a starting point to push on.
Walk down each branch. Every follow-up question opens a new branch. “What could go wrong?” is one branch. “What am I missing?” is another. Each one can go as deep as it needs to without burying the others.
Explore alternatives without choosing. Fork the conversation to test different approaches at the same time. Both branches keep the full context from the root. You don’t have to pick one direction — you explore all of them.
See what survives. After walking every branch, the tree shows the full picture: which arguments held up, which fell apart, where the real risks are. Every open question either got answered or got surfaced.

Why trees exist for this

Linear chat forces a trade-off between depth and breadth. Go deep on one aspect and you lose the others. Switch topics and you lose the thread. A tree removes that trade-off. You go as deep as you need on every branch, and nothing gets lost.

This is how you actually exhaust an idea: walk down each branch of the decision tree, resolve dependencies between decisions one by one, and keep going until there are no open questions left.

Example

A founder pitching “we should build our own analytics pipeline” starts with the rationale. One branch explores build-vs-buy. Another explores what happens if the pipeline fails at scale. A third challenges the timeline estimate. Each branch goes 3-4 levels deep. The build-vs-buy branch surfaces that the team has no data engineering experience. The timeline branch reveals a dependency on a hire that hasn’t been made. These blind spots were always there, but in a linear chat they would have been hand-waved past. The tree made you actually follow each one to its conclusion.

For related workflows, see model comparison for testing ideas across models, or decision making for weighing options.

Now try it yourself

I want to migrate our monolith to microservices. Convince me this is the right call.

It depends on what's actually hurting. Microservices solve scaling and team autonomy problems but add operational complexity. What's the pain point driving this?

Deployments are slow. One team's change blocks everyone else.

That's a real signal. But have you tried deploy pipelines per module within the monolith first? Microservices solve this but so does a well-structured modular monolith, without the distributed systems tax.

Grill me on this -- what will go wrong if we do migrate?

Service discovery, distributed tracing, data consistency across boundaries, network latency replacing function calls, and your team has never operated a service mesh. That's 6 months of infrastructure before you ship a single feature.

What if we only extract the one service that's the bottleneck?

That's the strangler fig pattern, and it's the right first move. Extract the deployment-blocking service, keep everything else monolithic. You get the autonomy win without the full migration risk.