DEV Community

Cover image for Speaker identity is a contract, not a label — what shipping document tools taught me
InApp
InApp

Posted on Originally published at imapp.blogspot.com

Speaker identity is a contract, not a label — what shipping document tools taught me

I used to treat “who said this” as a display problem. Put my name at the top of an API response, add a header, done. Then agents started piping my converted Markdown straight into retrieval indexes, and the failure showed up downstream: a clean excerpt looked identical to a hallucinated one because nothing in the payload said who produced it, from what source, or under which converter version.

So I stopped thinking of speaker identity as branding and started treating it as provenance metadata. Every converted document now carries a stable document id, a hash of the source bytes or URL, the parser version, and a timestamp. Not for marketing — for attribution when another agent quotes, summarizes, or contradicts it later. The interesting part is that agents are much better behaved when the identity is machine-checkable. If a downstream agent wants to cite the output, it can verify the source hash instead of trusting my logo.

The hard lesson: identity breaks at boundaries. An HTML page, a PDF, and a DOCX can all become “markdown,” but if the metadata says only source: document, the speaker identity is fake precision. I had to keep the original type, extraction path, and drop decisions next to the text. Once I did, debugging got easier too — when a table came out wrong, I could tell whether the fault was in fetch, parse, normalize, or the agent that consumed it.

If you are shipping anything agents will consume, assume your output will be quoted without you in the room. Make the speaker identity part of the artifact, not the envelope.

Top comments (0)