How does an agentic operating system know where a fact came from?

It stamps each fact with its source as it enters the platform, before any agent sees it, and keeps the stamp attached wherever the fact travels. A balance read from the ledger, a figure from a signed report and a claim in a customer's email arrive marked differently. Anything an agent derives inherits the weakest stamp among its inputs.

Why does the source of a fact matter to an agent?

Because the same fact can be safe to act on or dangerous, depending on where it came from. "The supplier's bank account is now X" is routine if it came from your vendor master file after a verified change. It is the opening move of a payment fraud if it came from an email.

People handle this with instinct and procedure. Agents need it made explicit. Without a stamp, a fact is just text in the context window, and the model weighs a forged email and a ledger entry the same way. The argument is set out in full in why provenance must travel with every fact.

How does stamping work?

Facts reach agents through connectors: a ledger query, a document store, an inbound email, a call to another agent. Each connector is registered with what it can vouch for. When it delivers a fact, the platform attaches:

• the source system or party;
• the provenance class, which says how far the fact can be trusted;
• the time it was read or received;
• any signature or reference that lets it be checked later.

One way to think about classes is along a scale of how much the business itself vouches for the fact. Facts read from your own systems of record sit at one end. Facts carried with a verifiable signature from a known issuer come next. Facts a customer or counterparty states about themselves follow. Claims from outside that nobody has vouched for sit at the other end.

Agents summarise, compare and calculate. The output is a new fact built from old ones. The platform records which inputs it came from and gives it the weakest class among them. An affordability figure built from a ledger balance and a customer's declared income is only as strong as the declared income.

This rule stops a common failure: a claim gets laundered into apparent certainty by passing through a summary. It also means the stamp survives handoffs between agents, workflows and memory.

Where does provenance change what an agent may do?

At the moment of action, provenance is one of the bounds. Some actions require facts of a certain class. Releasing a payment to a new account needs more than an external claim; changing a contact detail may accept a declared fact from a logged-in channel but not from an email. When a bound fails on provenance, the verdict says so, and the action is held or refused.

Approvers see the stamps too. A held item shows each fact's source, so a person can tell at a glance what is verified and what is asserted; see how an agentic operating system handles human approvals.

What does this look like in practice?

Take a lender's servicing agent handling a request to change a borrower's repayment account. The request arrives by email with an attached bank letter. The platform stamps the email as external and the attachment as external too, since its letterhead cannot be verified. The borrower's existing details come from the loan system, stamped as your own record.

The agent drafts the change. The platform holds it, naming the source bound: an external claim cannot authorise a change to where money is collected from. A servicing officer calls the borrower on the number already held, confirms, and approves. The new account details now enter the loan system through an approved change, and future reads of them carry that system's stamp.

What are the limits of provenance?

Provenance says where a fact came from. It does not say whether the fact is true. A system of record can hold an error; a signed document can be signed by the wrong person. Provenance tells you how much the business has vouched for a fact, which tells you how much checking is needed before acting on it.

People still verify external claims through independent channels, resolve conflicts between sources, and decide which connectors may vouch for what. Where provenance sits in the wider design is covered in where an agentic operating system sits in your architecture.

Where Pryme fits

Pryme Context Protocol stamps every fact reaching an agent with where it came from, in one of four provenance classes: sealed, signed, declared or external. An external claim cannot authorise a payment. The stamp is part of the minimum chain checked at every action, as described in the governed agentic operating system guide.