RTK as a Reversible Context Boundary

RTK should be judged by more than the percentage printed beside a command. The project is a Rust CLI proxy that changes how development-tool output reaches an AI coding agent, and its central question is whether that change preserves enough authority, evidence, and recoverability to remain useful. This final synthesis brings those relationships together into an adoption test: trace the boundary, check the permissions and fidelity, inspect what can be recovered and measured, and then weigh privacy and maintenance. The result is a conditional judgment, not a universal promise that every command should be made shorter.

The complete path is a chain of guarded decisions

RTK's behavior becomes clear when the system is followed from the request rather than viewed as a collection of commands. An agent asks to run a familiar tool. An integration may intercept that request and ask RTK for an equivalent invocation. The host's permission rules still determine whether the command may be changed or automatically approved. The shell-aware registry checks whether the command's structure can be transformed without changing its meaning. Only then does the underlying tool run through an RTK route, where a command-specific filter chooses a representation for the LLM context.

flowchart LR A["Agent command"] --> P["Host authorization"] P --> W["Shell-aware rewrite"] W --> T["Underlying tool"] T --> F["Representation-specific filter"] F --> G["Never-worse guard"] G --> C["LLM context"] G --> R["Recall omitted evidence"] R --> C F --> M["Local measurement"] M --> D["Coverage and filter feedback"] U["Exclude, bypass, or passthrough"] --> W X["Trust custom filter"] --> F N["Opt-in aggregate telemetry"] --> M K["External-tool and agent changes"] --> W

Each transition has a different owner. The agent and its host own the request protocol. The host owns permission. RTK owns the decision about whether a supported route exists and how output should be represented. Git, Cargo, pytest, a linter, or another underlying tool owns the operation and its exit status. The user owns the escape routes: they can exclude a command, bypass RTK for one invocation, select passthrough, or decline to trust a custom filter. The LLM receives the final representation, but it does not receive a guarantee that the representation is complete merely because it is compact.

That ownership model explains why the agent integration and the filter should not be fused. Hooks and plugins are thin adapters that understand a host's event and response format. The Rust registry centralizes command matching, while specialized filters centralize the interpretation of tool output. A rules-only integration sits at a different point on the spectrum because it asks the agent to type the RTK form itself. These paths can share a purpose without offering the same certainty that a command was rewritten.

The first decision is therefore not “how much can RTK save?” It is “did RTK reach the command boundary in a way the host permits?” A full hook can replace an input before execution. A plugin can mutate a terminal command through its host API. An instruction file can only influence the agent's choice. If an agent runs raw git status, the result might reflect an absent hook, a rules-only integration, an unsupported command form, an exclusion, or an explicit bypass. The raw output alone cannot tell which explanation is correct.

The second decision is semantic. RTK's registry handles shell structure conservatively because a command is not just its first word. Compound chains can be split into segments, but the shell retains the sequencing. A wrapper can be peeled for matching and restored for execution. Pipelines require position-specific safety because one stage consumes another's output. Heredocs, substitutions, grouped expressions, certain redirects, and incompatible flags can prevent safe decomposition. When the registry cannot establish the equivalence, leaving the command raw is more trustworthy than inserting a filter by pattern alone.

The third decision is representational. After the underlying tool has run, RTK must preserve the evidence needed for the agent's next action. The appropriate representation depends on the output.