From Terminal Output to Useful Answers
An agent inspecting a repository can spend considerable context on output that a small local program could interpret more consistently. Progress indicators, repeated warnings and file listings are all text, but they do not have equal value for the question being asked. QuietCli starts by making that question explicit, then asks the agent to write the code that computes its answer.
Suppose the request is to determine whether the working tree needs review. The relevant information includes the current branch, whether tracked entries changed, and whether untracked entries exist. Returning every path can be unnecessary. If the next request is to review the implementation, however, a Boolean is insufficient: the companion must provide targeted content. Information selection follows intent, and intent can change between requests.
Calculate before transmitting
The basic data flow is easy to inspect:
Question -> companion script -> original CLI
<- native streams
local parsing, conditions and calculations
-> domain data -> bounded JSON -> agentQuestion -> companion script -> original CLI
<- native streams
local parsing, conditions and calculations
-> domain data -> bounded JSON -> agentThe original program still runs and produces output. Local code consumes that output and constructs useful data. The model receives the resulting execution envelope instead of every intermediate message. This can reduce the volume transmitted to the agent, while moving repeated interpretation into ordinary code that can be reviewed and reused.
That code can do more than select matching lines. It can parse a documented record format, distinguish entry types, calculate totals, check relationships between events, and combine observations from several commands. A count and its unit are different information from a clipped list. A final event agreeing with an observed count provides different evidence from a process that merely stopped printing.
The common interest with OPumper
The RTK vs Pump-Me series describes an observation contract: what the agent needs to know, what each value means, and what establishes completeness. QuietCli benefits from the same discipline. Both approaches can keep parsing and domain calculations local, provide objects for subsequent computations, expose failures explicitly, and send one bounded result at the end of a task.
Their organization differs. OPumper uses reusable providers, declared routes and a registry. QuietCli supplies a native execution runtime and lets the agent author a companion script around the current need. The inspected QuietCli module has no provider catalogue. A reusable companion remains a script with its own documented assumptions and tests; it does not become a registered OPumper provider by being saved.
The shared value is therefore a workflow and its evidence, rather than identical interfaces. QuietCli's envelope contains Execution and SchemaVersion; the OutputPumps contract has its own fields and conventions. Keeping these differences explicit makes the examples usable and prevents readers from copying an API that belongs to another library.
Define the smallest sufficient answer
A useful contract for repository cleanliness might specify:
| Property | Meaning |
|---|---|
Changed |
Number of changed tracked status entries. |
Untracked |
Number of untracked entries under the selected Git option. |
Clean |
Both counts are zero within that scope. |
AnswerComplete |
The companion obtained the observations needed for this question. |
The unit matters. An untracked directory can be one entry even when it contains several files. Calling the value a file count would change its meaning. Similarly, an unknown count should remain null. Replacing an unavailable count with zero would claim that the search or inspection found nothing, even though it may have failed.
The smallest sufficient answer also needs enough context to be interpreted. Depending on the question, that can include a path scope, a tool version, a time window, or a statement that separate observations are not an atomic snapshot. These qualifiers are useful data. They should be selected deliberately instead of being lost during output reduction.
Reuse has a cost and a payoff to assess
Writing the first companion requires source inspection, parser work and checks. The script consumes local CPU and memory whenever it runs. A familiar command with a short, sufficient answer may need no companion at all. QuietCli's guidance explicitly permits a command already known to be short to run directly.
Reuse becomes attractive when the same interpretation occurs repeatedly or when mistakes in informal interpretation would be expensive. A tested parser can serve another request without making the model reinterpret the complete native output. A later task can consume its named properties and perform additional calculations locally. Whether this justifies the initial effort depends on the actual workload and maintenance burden.
This series demonstrates that capability with supplied examples and a new composition script. It does not convert a smaller JSON document into an asserted reduction in the user's total bill. Prompt authoring, model output, history and repeated calls also contribute to a session. The verification chapter keeps those boundaries visible.
Next, we turn the requirement into the code the agent is responsible for writing, and distinguish that code from the runtime that executes it.