Child Agent Output Size Limits

When one Kindo agent invokes another as a child agent, the child’s result is summarized for the parent agent and the verbatim transcript is parked alongside the run — fetched on demand rather than pushed back inline. Kindo bounds the size of any transcript the parent reads 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 on completion

When a child agent finishes, the parent’s tool call result contains a single structured object:

• 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.

The summary, key findings, and confidence are the distilled, high-signal channel and the parent’s primary input. The full conversation transcript is not included in this result.

Reading a child’s transcript

When the parent agent needs to inspect what a child actually did — to spot-check a finding, quote evidence, or debug a confusing result — it calls the get_child_agent_transcript tool, passing the child’s workflowRunId. The tool works in two steps:

1. Outline first. The default response is a compact map of the transcript: how many turns it has, its total size, and one line per turn — who spoke and a short preview of what was said. This costs the parent agent very little context, however large the child’s transcript is.
2. Read what matters. The parent agent then requests the full text of just the turns it needs — typically the child’s closing turns, or the span around a finding it wants to verify. The text comes back as role-tagged turns ([USER], [ASSISTANT], etc.) in conversation order.

Children that are still running return their transcript so far. A parent can only read transcripts of children it spawned.

Access control for child-agent tools

list_child_agents and get_child_agent_transcript are scoped to the child agents spawned by the parent. A parent sees and can read transcripts of only the agents it spawned itself; children spawned elsewhere in your workspace are not visible to it.

What “bounded” means

Both steps are bounded, so a parent agent’s context window is protected no matter what the child produced:

• The outline is compact by construction — previews are one short line per turn, and extremely long transcripts list their opening and closing turns with the middle elided (those turns remain readable on request).
• Each read returns at most 48 KiB (49,152 bytes, measured as UTF-8 byte length) of transcript text. Reads are assembled from whole turns: when the requested span doesn’t fit in one response, the read stops at a turn boundary and tells the parent agent where to continue. No content is ever lost to the cap — larger spans just take more than one read. (The per-read text limit sits below the parent’s overall inline tool-result budget so the read, once wrapped in its JSON response envelope, is always delivered in full rather than parked in external storage.)

The one exception is a single turn that is by itself larger than one read — for example a turn into which a child pasted an entire log dump. In that case Kindo keeps the beginning and the end of that turn, drops the middle (cutting on safe character boundaries), and signals the cut explicitly — both inline, with a marker at the cut, and as a structured transcript_overflow field:

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

Both counts are UTF-8 byte lengths: originalBytes is the turn’s full size before truncation, keptBytes is the size of the returned text. The field is present only when a turn was cut, so a parent agent can branch on it to detect truncation programmatically rather than parsing the inline marker.

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 the transcript as evidence, not as context

Design parent prompts to read the summary and key findings first, and reach for get_child_agent_transcript only when a specific detail is needed. The outline-then-read flow supports this naturally: the parent agent can check the outline cheaply, then pull only the turns that matter, instead of reading the whole transcript front to back.

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.

Read further instead of reasoning from partial data

A transcript larger than one read is not lost — the parent agent can keep reading until it has what it needs. The transcript_overflow field appears only when one giant turn had to be cut; in that case the summary, key findings, and confidence value remain the high-signal channel for that turn’s content. If a child routinely produces single turns too large to read whole, 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.

Related

• Multi-Agent Coordination — patterns for splitting work across parent and child agents.
• Working with Large Context — managing context window pressure in any agent.