After entering a topic, the app searches for relevant items, fetches their pages, and fills the first version of the table. For "ultralight 1-person tents" that might look like:

+----------------------+----------+-------+-------------------+
| Item                 | Weight   | Price | Wall Type         |
+----------------------+----------+-------+-------------------+
| Zpacks Plex Solo     | 405 g    | $599  | Single-wall DCF   |
| Big Agnes Fly Creek  | 879 g    | $350  | Double-wall       |
| Tarptent ProTrail Li | 425 g    | $399  | Single-wall DCF   |
| Nemo Hornet Elite    | 765 g    | $450  | Double-wall OSMO  |
+----------------------+----------+-------+-------------------+

The app currently uses Kagi search to gather items, but the same approach would work well embedded in a shopping site, marketplace, internal product database, recruiting tool, or anywhere else the rows already exist.

The initial columns are also generated from the first search results. The app looks at the retrieved items and picks a few useful dimensions automatically, so there is already something on the table before the user asks anything.

Once the table exists, typing a question adds a new column to it. Each question adds one comparison dimension to the existing structure, and the result has a specific place to land.

The model call is ordinary: given these item summaries, answer this question for each row. What changes is that the result lands in the structure you are already building.

Creating the LLM call as a tool call which specifically returns an answer for each row also fits the current generation of models well.

{
  "name": "fill_column",
  "description": "Answer a comparison question for each item in the table.",
  "input_schema": {
    "type": "object",
    "properties": {
      "answers": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "row_id": { "type": "string" },
            "value":  { "type": "string" }
          },
          "required": ["row_id", "value"]
        }
      }
    },
    "required": ["answers"]
  }
}

The important constraint is simple: return exactly one cell value for each row id. The model fills a specific part of the table.

Because a model is filling the cells, the columns can go beyond structured specs.

Translation is a natural side effect. If an item's page is in Japanese and I want the table in English, the cell gets filled in English without a separate translation mode.

Unit normalization is similar. If I ask Weight (g)? the model can usually get everything into the same unit, assuming the source pages have enough information.

Soft judgement calls also work better than I expected. "Is this good for a beginner?" is a useful comparison question even though it has no single correct answer, and most real buying decisions are similar.

For questions that need fresher context, the app can search again before filling the column. "What does Reddit think about this?" becomes a column backed by live search.

The product comparison case is the obvious one, but the same interaction pattern could apply anywhere you are evaluating a set of things against a shared set of questions.

Each node has an expand button that sends the current heading and some surrounding context to the model, which replies in one of three shapes.

A breakdown is a handful of concrete sub-items, inserted as children.

A question means one missing detail would change the answer, so the model asks for it. For "Choose model hosting for small finetuned model", the model asks about parameter size and expected request volume, with suggested choices or a free-text fallback.

An options response covers mutually exclusive paths. Picking one replaces the current node label while the original goal stays in the parent chain for context.

Breakdowner sends one user message to the model with a single available tool: search. The prompt asks for exactly one JSON object in one of three shapes:

{"type": "breakdown", "items": ["..."]}
{"type": "question", "question": "...", "choices": ["..."]}
{"type": "options", "options": ["..."]}

The distinction is: breakdown for parallel concrete next moves, question when missing info would change the answer, and options for mutually exclusive paths where picking one replaces the node.

The prompt pushes hard against generic planning language. NOT: "Research options", "Set up environment", "Create plan", "Test and iterate", "Evaluate". Positive examples given to the model:

• Pick Stripe vs Paddle
• Find 10 people who complained about X on Reddit
• Compare prices at 3 stores vs delivery

A vague child node creates more work at the next expansion; a concrete one can be acted on, searched, delegated, or broken down further.

The model sees the current heading, the parent chain, and any prior answers collected from question nodes earlier in the branch: only the focused context around the node being expanded.

Context:
- parent
  - child
    → current heading

Prior answers:
...

Handle: current heading

The parent chain keeps a deep node connected to the top-level goal. Prior answers mean the model does not forget that the budget is tight, or that this needs to happen in Tokyo, or that the user has never done the thing before.

Sibling branches don't share context. The tree structure determines what the model sees, which ends up being a cleaner scoping than a linear transcript can provide.