Agent-First HTTP v0.3.4: Output Formats Preserved Responses

Output formats are useful only if they do not change the data.

Agents often prefer JSON. Humans debugging a command may prefer YAML or plain logfmt. Agent-First HTTP supports those renderings, but HTTP responses are special: the body is remote data, not a local config object to be reformatted.

Agent-First HTTP v0.3.4 tightened that boundary.

The problem: response bodies are payloads, not formatter input

Imagine a server returns JSON with its own fields:

{"token_secret":"this-is-a-server-payload","duration_ms":12}

If a display formatter treats that body as ordinary AFDATA metadata, it may strip suffixes, format values, or redact fields the server intentionally returned. That is surprising. The connector should preserve the server payload exactly and only format the afhttp envelope around it.

The change: pipe mode gained the same output choices

The v0.3.4 line extended --output yaml and --output plain to pipe mode. A long-running agent process could now keep one afhttp session open and still ask for the same rendering choices as single-shot CLI mode.

That made output mode a consistent runtime setting instead of a CLI-only detail.

The guardrail: non-JSON bodies became opaque in human formats

For YAML and plain output, afhttp protects response body fields by serializing them as opaque JSON strings. The event envelope can be human-readable, but the server payload remains the server payload.

The agent does not lose structure in JSON mode. A human does not get a mutated body in YAML/plain mode. Both paths have a clear contract.

Where this fits: format for the reader, preserve the response

This release clarified a useful rule for agent tools: render the tool event for the current reader, but do not reinterpret foreign payloads unless the protocol explicitly says to.

For HTTP, the body belongs to the server. afhttp reports it; it does not rewrite its meaning.