> ## Documentation Index
> Fetch the complete documentation index at: https://graph.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Finish modes

> Solver report, structured output, or silence

After the steps run, a plan finishes one of three ways. Pick per plan by including `solver`, `output`, or neither (they're mutually exclusive).

## `solver` — an LLM-written report

```yaml theme={null}
solver:
  query_to_answer: |
    Summarize the sprint for {{input.team}}…
  system_prompt: Optional extra guidance for the writer.
  data:
    issues: "{{E1.issues}}"
```

The collected `data` goes to the solver model, which writes prose. In `plan run` the report **streams to stdout as it generates**; as a plan tool, it returns to the agent as `{"answer": …}`. One LLM call.

Use for: human-readable reports, analysis, anything with judgment in the presentation.

## `output` — structured JSON, zero LLM

```yaml theme={null}
output:
  count: "{{E0.issues.length}}"
  issues: "{{E0.issues}}"
```

The template map renders against the results and is emitted as JSON — no inference at all.

```bash theme={null}
graph plan run urgent_issues | jq '.count'
```

As a plan tool, the agent receives the **actual data structure** rather than prose — better grounding for follow-up reasoning. Use for: data extraction, feeding other tools, anything a machine consumes.

## Silent — side effects only

A plan with neither `solver` nor `output` runs its steps and exits `0`, printing only a `✓ plan completed (N steps)` note to stderr. Combined with write-capable tools (`linear__save_comment`, an exec tool that deploys, …), this is a complete zero-inference automation job.

## Empty data behaves differently per mode

When a step's data runs out mid-plan (a `.0.` reference into an empty search result):

| Mode              | Behavior                                                                                                                                 |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `solver`          | degrades gracefully — the solver still answers, honestly reporting what wasn't found                                                     |
| `output` / silent | **hard failure** with a typed `empty_data` error — automation must see that the data ran out rather than receive silently truncated JSON |

Rationale: a narrator can explain emptiness; a JSON contract can't. More in [Errors & replanning](/plans/errors-and-replanning).


## Related topics

- [Execution model](/architecture/execution-model.md)
- [graph as an MCP server](/tools/mcp-server.md)
- [Introduction](/getting-started/introduction.md)
- [Plan file schema](/reference/plan-schema.md)
- [The planner](/plans/the-planner.md)