Skip to content
Kindo Kindo Docs

Child Agent Output Size Limits

When one Kindo agent invokes another as a child agent, the child’s result is summarized and returned to the parent agent’s conversation. Kindo bounds the size of that returned data so multi-agent setups stay reliable even when the child produces large amounts of evidence — log dumps, Splunk result sets, verbose API responses, or any other bulky output.

What the parent receives

The parent agent does not get the child’s live conversation merged into its own context. It receives a single structured result that contains:

  • A short summary of what the child did and concluded.
  • A list of key findings — the most important facts, data points, or decisions.
  • A confidence signal — high, medium, or low.
  • A bounded raw output field carrying the child’s full conversation transcript, captured verbatim.

The summary, key findings, and confidence are the distilled, high-signal channel and the parent’s primary input. The raw output is the verbatim transcript — for spot-checking or quoting, not the parent’s main reasoning input.

What “bounded” means

The raw output field is capped at 64 KiB (65,536 bytes, measured as UTF-8 byte length). If the child’s transcript exceeds this, Kindo:

  • Keeps the beginning and the end of the transcript and drops the middle, so both the task setup and the child’s final answer survive. Cuts land on safe character boundaries.
  • Adds an explicit “data was truncated” signal — both inline (a marker inserted at the cut, between the kept beginning and end) and as a structured raw_output_overflow field — so the parent agent never silently consumes a partial result.
  • Does not affect the summary, key findings, confidence, or the raw_output_overflow field itself.

The raw_output_overflow field is present only when truncation happened, and is shaped as:

{ "originalBytes": 196608, "keptBytes": 65536 }

Both counts are UTF-8 byte lengths: originalBytes is the full size before truncation, keptBytes is the size of the returned (truncated) raw output. A parent agent can branch on the presence of this field to detect truncation programmatically, rather than parsing the inline marker text.

Designing child agents that surface findings reliably

Make the final step produce a tight, decision-ready summary

The summarizer that builds the parent-visible result works on the child’s whole conversation. The more compact and structured the child’s final messages are, the more useful the parent-visible summary and key findings will be. A child agent whose last step is “produce a short structured conclusion” is far more useful to a parent than one whose last step dumps a thousand lines of evidence.

Treat raw output as evidence, not as context

Design parent prompts to read the summary and key findings first, and reach for raw output only when a specific detail is needed. This keeps the parent’s context window healthy and means the raw-output cap rarely matters in practice.

Externalize bulk evidence

If a child agent’s job is to produce a large artifact — a report, an export, a long log bundle — write it to an external system (Notion, Google Drive, a ticketing system, an S3 bucket via an API Action step) and have the child return a pointer plus a short summary. The parent agent can fetch the full artifact via an integration when needed, rather than carrying it in conversation context.

Reason from confidence when output is truncated

When the raw_output_overflow field is present, raw output was truncated — the summary and key findings are still the high-signal channel. Teach the parent agent to lean on those fields and on the confidence value rather than on a partial raw output. If the child needs to return more detail, narrow the child’s prompt or split the work across more focused child runs.

When child agents are the wrong tool

Child agents are designed for delegating a bounded task and getting a summarized answer back. If an agent’s natural shape is “produce a large dataset and hand it to the next step verbatim,” consider keeping the work inside one agent — using multiple steps in a single run so intermediate data never has to cross the parent/child boundary — or coordinating via an external system so bulk data is passed through storage rather than conversation context.