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. This is a small detail, but it matters. The app does not need to start from a blank table. It can look at the retrieved items and choose a few useful dimensions to kick things off.

Once the table exists, type a question and a new column appears. The table stays put. The question adds one comparison dimension to the same object rather than producing another answer below the last one.

The model call itself is ordinary: given these item summaries, answer this question for each row. What changes is that the result has somewhere specific to land. The structure it lands in is already the thing you are trying to build.

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 is not being asked to write a new answer. It is being asked to fill a specific part of the table.

Because a model is filling the cells, the columns are not limited to structured specs.

Translation comes almost for free. If an item's page is in Japanese, and I want the table in English, the cell can just be filled in English. I do not need a separate translation mode in the UI.

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 not a product spec, but it is still a useful comparison question. It is not perfectly objective, but most real buying decisions are not perfectly objective either.

For questions that need fresher context, the app can search again before filling the column. "What does Reddit think about this?" becomes a column like any other, backed by live search rather than the cached product page.

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. Clicking it sends the current heading and some surrounding context to the model. The model replies with 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 instead of guessing. For "Choose model hosting for small finetuned model", rather than generating a generic breakdown, the model asks about parameter size and expected request volume, with suggested choices to pick from 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 just creates more work for the next expansion. A concrete child node can be acted on, searched, delegated, or broken down again.

The model sees the current heading, the parent chain, and any prior answers collected from question nodes earlier in the branch. No full global tree, just 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 stay out. That is the bit I like most about this pattern. Context is selected by the tree structure instead of being whatever happened to appear earlier in the transcript.