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

# Testing and Iteration

> Improve Hive Agent runs by reading verifier feedback, pass outcomes, and completion modes

Iterate on a Hive Agent by running it with a focused objective, reading the rejected nodes and trace details, then tuning stage models, tools, repeat settings, and budget limits.

## How do I read verifier feedback? <a href="#verifier-feedback" id="verifier-feedback" />

Open **Hive Agents** > **Logs** and click a run.

In the run detail sheet, review the node overview and trace stages. Rejected nodes include the reason and required fix from verification. The next execute pass receives that rejection feedback so the executor can try again.

Deterministic checks run before semantic verification. They catch invalid JSON, blank required fields, nested JSON strings, and URL fields that do not resolve. Optional schema fields should be returned as `null` when unused; the platform fills omitted nullable keys before schema validation, but blank required fields still fail verification.

## What should I tune first? <a href="#tune-first" id="tune-first" />

Start with the stage that failed:

* Tune **PLAN** when nodes are poorly decomposed or verification criteria are vague
* Tune **EXECUTE** when outputs are incomplete, unsupported by sources, or missing tool work
* Tune **VERIFY** when good outputs are rejected or weak outputs pass
* Tune **REPEAT** when the run stops too early or spends too long retrying similar failures

For source-heavy tasks, attach better sources before changing models.

## Large multi-document or spreadsheet objectives <a href="#large-source-objectives" id="large-source-objectives" />

When the objective spans a long brief plus an example spreadsheet (or similar multi-file work):

1. On each Knowledge Base item, raise **Maximum chunk length** (about 1500–2000) and set chunking to **Advanced** so overlap applies. Default chunking at 500 characters with no overlap shreds long docs into fragments that are easy to mis-attribute across files.
2. After changing chunk settings, re-run item embedding / source preparation so retrieval uses the new chunks.
3. On the Knowledge Base itself, keep **search score threshold** around **0.1** for hybrid search (the platform default) and keep **search chunk limit** at about **8** (or raise toward 10–20 for multi-file sources). A hybrid threshold of **0.5** is retrieval-hostile for agent-task queries and can return zero chunks even when the vector index is populated.
4. Prefer a stronger **EXECUTE** model or higher reasoning effort for cross-document extraction and citation work.
5. Word the run objective so PLAN creates one node per output sheet or section, and so EXECUTE nodes return structured intermediate rows — not a final formatted spreadsheet. **COMPOSE** owns the spreadsheet-ready assembly.
6. Raise **Max Concurrent Nodes** in Budget Settings when you expect more than about five parallel nodes.

Plan / execute / verify / compose never expose system `file_tools` at invoke time. Grounding comes from platform `SOURCE CONTEXT`, not `read_file`. Downloadable files for spreadsheet or document objectives are produced by the platform after compose.

## How do completion modes affect iteration? <a href="#completion-modes" id="completion-modes" />

**Strict** mode fails the run when required nodes remain unverified after the max passes.

**Best effort** mode completes with verified work and flags the unverified nodes. Use it when partial verified output is acceptable. When the pass limit is reached with at least one verified node, the run still attempts **COMPOSE** from those verified outputs, then completes with unverified nodes flagged. If no nodes verified, the run completes without a composed final response.

Best effort does not bypass final composition when compose does run: if Compose cannot pass after **Max compose attempts**, the run fails.

## Do edits affect running tasks? <a href="#running-edits" id="running-edits" />

Blueprint edits affect future runs. Stage agent settings can also affect later activity cycles in an already-running task because the runtime reads the current stage agent when an activity starts.

Avoid changing models, tools, or budget settings mid-run unless you intend to change the next stage cycle. For clean comparisons, wait for the run to finish, edit the blueprint, then start a new run with the same objective.

## How do I compare runs? <a href="#compare-runs" id="compare-runs" />

Use **Hive Agents** > **Logs**.

Compare:

* Objective
* Status
* Pass number
* Node counts
* Source counts
* Total tokens
* Total cost
* Duration
* Final response
* Rejection reasons

Keep test objectives narrow while you tune. Once the loop is reliable, increase scope and budget.

See also: [Running Tasks](./running-tasks) and [Logs](./logs).
