Your AI Assistant Should Tell You Which Model Answered

The problem with "the assistant said..."

Ask a colleague where a number came from and "the spreadsheet told me" is not a satisfying answer. The same is true for AI. As AI assistants move from novelty chat windows into tools people rely on for real decisions, "the assistant said..." stops being sufficient. Which assistant? Running on which model? Configured by whom? Answering with what information?

Most consumer chat products hide this by design -- one brand, one model, no visible seams. Enterprise AI tools don't have that luxury. Organisations already run more than one model for good reasons: cost, latency, capability, vendor risk, and simple experimentation. When several models can plausibly answer the same question, "the assistant" is no longer a single, stable thing a person can develop trust in. The identity behind the answer has to become visible.

Provider and model identity, not just "AI"

The first fix is unglamorous: say who is answering. Not "AI," not "the assistant" -- the actual provider and model, surfaced in the interface the same way a byline identifies an author. A response from a fast, inexpensive open model and a response from a larger reasoning model may both be useful, but they are not interchangeable, and a reader evaluating the answer benefits from knowing which one they're looking at.

This sounds obvious until you try to build it. Model identity has to be resolved from a live, editable configuration -- providers get added, models get swapped, defaults change -- rather than hard-coded into the interface. The label a user sees has to reflect the model that actually ran, not the one that happens to be configured as default today.

Recording the model behind every reply

Visible identity for the current response is only half the story. A conversation is a history, and history should stay honest. If an administrator changes the default model next week, every earlier message in every existing conversation should still say, correctly, which model produced it at the time.

That means model identity isn't just something to display -- it's something to record, message by message, as a permanent fact about that specific response. Without that, a conversation becomes retroactively unreliable: scroll back far enough and the interface starts silently misattributing old answers to whatever model happens to be configured now. For anything that gets reviewed later, that's not a cosmetic gap, it's a provenance failure.

Switching models without rewriting history

Once model identity is recorded per message, a useful property falls out for free: a single conversation can legitimately span multiple models. A user might start with a fast default, switch to a stronger model for a hard follow-up, and switch back -- and each message keeps its own accurate record of what answered it. Nothing about the conversation needs to be rewritten or normalized to make that consistent.

This also protects two things that should stay independent: the model doing the talking and the model doing the retrieval underneath it. Changing which model generates responses shouldn't silently change which embedding model is finding the source material -- those are different jobs, and conflating them under one "the AI" abstraction is exactly the kind of hidden coupling that makes systems hard to trust.

Showing your work: sources, tools, and activity

Identity is necessary but not sufficient. A trustworthy assistant should also be willing to show a little of its work: which knowledge it searched, which tools it used, what it actually did between "thinking" and answering. Not a raw log of internal reasoning -- that's neither useful nor appropriate to expose -- but a plain description of meaningful actions: it searched the handbook, it checked available assessments, it retrieved project context.

This is a deliberately narrow kind of transparency. The goal isn't to turn every response into a debugging console; it's to give a reviewer enough of a trail to sanity-check an answer without having to take it entirely on faith.

Why provenance matters for review, audit, and trust

None of this matters much for an assistant answering trivia. It matters a great deal for one that's being used to investigate a legacy system, compare architectural options, or draft something a human will later sign off on. In that setting, "which model said this, using what information, and when" isn't a nice-to-have -- it's the difference between an answer you can defend in a review and one you can't.

Provenance is what turns an AI assistant from a black box you either trust or don't into a tool whose outputs can actually be checked. That's a small feature list -- visible identity, per-message provenance, independent model switching, a light trail of activity -- but it changes what kind of relationship a user can have with the tool. Not "the assistant said," but "the model said, having searched the platform knowledge base, on this date, in this conversation." That's a sentence you can actually stand behind.