An email agent needs provenance, not confidence.

An email agent should be able to answer more than “Why did you do that?” It should show which customer state, consent evidence, policy version, campaign artifact, tool result, approval, and provider event produced the action. Each material fact needs an origin. Each derived fact needs a reproducible transformation. Each action needs authority. Each outcome needs reconciliation.

Confidence is a property of an answer. Provenance is a path through the world.

That path matters because sending is not a writing task. It changes customer state, consumes reputation, spends money, triggers automations, and creates obligations. A fluent explanation after the fact is not evidence. A provenance record must exist because the system preserved the sources and relationships while the work happened.

A model can be highly confident for bad reasons. It may have seen a stale summary, inferred a missing field, confused an attributed order with an incremental one, or accepted a tool description from a server it should not trust. Raising or lowering a confidence number does not reveal which of those conditions occurred.

Provenance changes the question. Instead of asking how sure the system sounds, ask what the answer depends on. If the agent says 84,312 people are eligible, the interface should reveal the audience query, source snapshot, exclusions, consent policy, suppression version, calculation, and observed time. If it recommends a claim, it should point to the source and edition that support it. If it sent, it should point to the exact digest that was approved.

This is why provenance belongs beside the durable state described in an email agent needs memory. Memory makes a fact available later. Provenance explains where that fact came from and how it became relevant here.

The W3C PROV model begins with entities, activities, and agents: things, transformations over time, and the parties responsible for them. An email system can use that compact foundation, then make two operational objects explicit: authority and outcome.

Do not flatten these into one activity message. “Agent sent campaign” hides the distinction between the data it used, the calculation it performed, the person whose authority it exercised, and what the recipient system later reported. Those relationships are the explanation.

Provenance should follow consequence. A font choice may only need the template version. An audience expansion, factual claim, new sender, or live send needs a stronger chain because the cost of an unexplained mistake is larger.

1. 01

   Audience membership

   Cite the segment definition, event and profile snapshots, consent scope, suppression and frequency policies, exclusions, query version, observed time, and resolved counts. Preserve why a person was included and why another was spared without copying the whole profile into the receipt.

2. 02

   Message claims

   Attach each price, deadline, feature, statistic, and legal qualification to an authoritative source, its version or effective window, and the transformation from source value to rendered sentence. An approved tone does not authorize an invented fact.

3. 03

   Sender and schedule

   Cite sender identity, domain and stream configuration, workspace timezone, quiet-hour rule, frequency policy, approval window, and the state observed immediately before execution.

4. 04

   Action and approval

   Record the actor, tool, scoped input, campaign digest, preflight result, material diff, approval identity, approval time, limits, and idempotency key. Approval applies to the thing shown, not to a nearby version.

5. 05

   Outcome evidence

   Join provider request and message identifiers to accepted, rejected, deferred, bounced, complained, unsubscribed, placed, clicked, and converted events while preserving each event source and observation limits.

OpenTelemetry traces model a request as a graph of spans with parent-child relationships. That is valuable plumbing: it reveals the path across services. Business provenance adds the domain objects the trace cannot infer, consent scope, campaign identity, approval authority, and the distinction between a provider event and a customer result.

Marketing systems are factories for derived facts. A segment count joins profiles to events, applies time windows, subtracts suppressions, resolves identity, and evaluates policy. Attributed revenue joins events again, chooses a window and model, handles refunds, and decides whether a click was human. The final number can be precise and still answer the wrong question.

Preserve the query or transformation version, input snapshot identifiers, parameters, code or rule digest, execution time, output identifier, and any quality warnings. For a model-generated classification, also preserve the task, model and configuration identifier, constrained output, evaluated policy, and supporting source references. A later reviewer should be able to reproduce deterministic steps and re-evaluate probabilistic ones against the preserved input.

This discipline keeps analytics honest. “Revenue from email” becomes a view whose lineage exposes the attribution rule, rather than a fact that arrived from nowhere. The same principle keeps audience eligibility from becoming a mysterious count that only the agent understands.

An agent cannot preserve evidence a tool refuses to expose. Tool interfaces should return stable business identifiers and evidence context with the result, rather than a sentence that says “done.” The Model Context Protocol supports structured tool results and output schemas, which makes this pattern practical across compatible clients.

A schema makes the response inspectable; it does not make the server trustworthy. MCP guidance explicitly treats tool descriptions and annotations as untrusted unless the server is trusted. The client still validates the result, binds it to the authenticated workspace and permission, and separates read-only inspection from a tool capable of live effect.

See how this boundary works in the Moosewave MCP layer and how connected sources remain visible across the broader integration system.

Provenance is most useful when the chain is imperfect. A consent record may have no scope. A product price may differ between the commerce system and a campaign brief. A segment snapshot may be six hours old while suppression state is current. A provider may accept a request whose final outcome remains unknown.

These conditions should feed the agent's stopping rule. Uncertainty is not an invitation to improvise past a boundary; it is a typed state that can cause refresh, ask, block, or bounded continuation.

Canonical serialization and content hashes are useful. They let preflight, approval, execution, and outcome records refer to the same campaign artifact. Chained or append-only event storage can reveal that a record was altered or removed. Signatures can bind a statement to a known signer.

None of those mechanisms prove the original price was correct, the consent was sufficient, the person understood the approval, or the provider event means inbox placement. They preserve identity and integrity. Truth still depends on source authority, collection method, scope, freshness, interpretation, and corroboration.

Keep the claim narrow: “this is the artifact that was approved” is different from “every fact inside it is true.” The first can be established with digests and authority records. The second requires the provenance chain and often a human judgment.

A naive provenance system duplicates every input into every receipt. That creates a second warehouse of customer data, broadens access, complicates deletion and retention, and makes the evidence harder to read. The safer design is a graph of bounded references with selectively materialized proof.

Store stable object IDs, versions, counts, digests, policy decisions, reason codes, and redacted excerpts where they are sufficient. Keep raw values in the system that already governs them. Resolve evidence through access-controlled links, record who viewed it, and preserve the fact and scope of a later redaction without retaining the erased value in a copied log.

Retention should follow purpose and consequence. An execution receipt may need a different lifetime from a transient model input or a customer profile. Access should follow role. The person approving a send may need counts and exceptions, not the private attributes of every recipient. Moosewave's current boundaries are described on the security page.

The reviewer should not have to browse a distributed trace, query a warehouse, and compare three policy files to answer one question. Assemble a finite receipt around the action or decision, with the underlying evidence one level deeper.

Measure the system by coverage and repairability: the share of consequential facts with a traceable source, stale-source rate, broken evidence links, untraceable decisions, time to reconstruct an action, and time to correct the source rather than merely edit the explanation. A provenance graph that no one can navigate is storage, not accountability.

Moosewave keeps goals, customer state, campaign versions, tool results, approvals, execution, and outcome evidence in one accountable run. The agent can move quickly across the work, while the product keeps every consequential transition connected to the source and authority that permitted it.

Start with current audience state, preserve the selected content and template version, run the campaign preflight, show the exact diff and evidence for approval, execute through a scoped tool, then reconcile provider and customer events in analytics without collapsing distinct observations into one success badge.

Follow that sequence in the interactive product walkthrough, or see how desktop, web, and mobile keep the same work and evidence connected across the Moosewave ecosystem.

• W3C, PROV-O: The PROV Ontology. The provenance reference model for entities, activities, agents, derivation, generation, responsibility, plans, and delegation.
• Model Context Protocol, Tools. Structured tool results, output schemas, client validation, user control, and the trust boundary around tool annotations.
• OpenTelemetry, Traces. Trace and span relationships for following a request through distributed services.
• NIST AI Resource Center, AI RMF Core. Governance, documentation, transparency, accountability, monitoring, and human review across the AI lifecycle.

Sources checked 24 August 2026. Specifications and guidance can change; the linked primary source takes precedence until this article is reviewed again.