---
title: "What does an agent have to read back after it posts?"
canonical_url: "https://cognilium.ai/blogs/what-an-agent-must-read-back-after-it-posts"
slug: "what-an-agent-must-read-back-after-it-posts"
section: "blogs"
date_published: "2026-10-21"
date_modified: "2026-10-21"
word_count: 1058
reading_time_minutes: 5
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related: []
---
# What does an agent have to read back after it posts?

The record itself, from the ERP, after the write. A success message describes an intention, and an intention is not evidence of a posted record.

## Key takeaways

- Read back the record from the ERP, not the agent's report of it. A success message describes an intention.
- The platform gives you attribution and ordinary validation, so the posting is traceable and legal — but a posting can be attributable, valid and still wrong.
- A read-back needs identifiers, the values that mattered, the resulting state, and what could not be verified.
- The unverified list is the most useful part of the output, because it is the short list where human time is actually needed.
- The MCP server stores no customer data. Retention depends on the agent client you chose, and Microsoft tells you to audit it.
- If the read-back is control evidence, its storage is your design decision, not the ERP's.

**The record itself, from the ERP, after the write.** Not a summary, not a confirmation message, not the agent's account of what it did. **An agent that says "posted successfully" has told you about its own intention**, and intention is not evidence.

## Why is reading back necessary at all?

**Because a report of success and a successful posting are different objects.**

An agent composes its reply from its own execution context. **If a write partially succeeded, was rejected downstream, or landed on a different record than intended, the agent's summary can still be cheerfully positive** — it is describing what it tried to do.

**The only thing that settles the question is the record.** Read it from the ERP after the write, and compare it to what was supposed to happen.

**This is not an AI-specific principle.** It is why integrations have always confirmed a write by querying it back, and why a goods-in clerk looks at the screen after pressing post. **What is new is that the intermediary is fluent and persuasive**, which makes its self-report easier to accept and no more reliable.

## What does the platform already give you?

**Attribution and ordinary processing. Both matter, and neither is a read-back.**

> *"An action that an agent takes through the MCP server is therefore **attributable to the user who initiated the request**, similar to an action that the same user takes in the finance and operations client."*

**And nothing is skipped:** *"Business logic, validations, and workflows aren't bypassed."*

**So the posting is real and it is traceable.** The ERP knows who did it and applied every rule it would have applied to a person.

> ### What that does not tell you  **Attribution answers "who".** Validation answers "was this legal". **Neither answers "is this the record we meant to create"** — a posting can be attributable, valid, and wrong.  **The read-back is the only step that closes that gap**, and the platform does not do it for you.

## What should the read-back actually contain?

**Four things, and the fourth is the one usually missing.**

**One — the identifiers.** The document number, the line, the date. Enough that a person can find the record independently, without trusting the agent's framing.

**Two — the values that mattered.** The quantity posted against the quantity expected, the item, the order it attached to. **The comparison, not just the result.**

**Three — the state afterwards.** What the line looks like now: fully received, partially received, still open. A read-back that reports the write but not the resulting state leaves the reader to guess the consequence.

**Four — what it could not verify.** If the agent checked three things and could only confirm two, the third belongs in the report. **A read-back that only lists successes is a success report wearing a read-back's name.**

**The test for a good read-back is simple:** could a reviewer who does not trust the agent use it to find and check the record themselves? **If not, it is a reassurance rather than evidence.**

## Why report the gap at all?

**Because the alternative is silent confidence, and silent confidence is what gets discovered at month-end.**

An agent working through old accrual lines will hit cases it cannot settle: evidence that is not in the system, a vendor who has not replied, a receipt whose history is ambiguous. **Those are correct outcomes of a careful process, not failures to hide.**

**And the operational value is real.** A list of "could not determine" lines is exactly the list a controller needs, because it is the short list where human time is genuinely required. **An agent that reports only what it resolved has deleted the most useful half of its output.**

**This is also the practical answer to a reasonable objection.** Asked how you know an agent is not quietly guessing, the strongest reply is not an accuracy claim — **it is that the agent tells you what it could not establish, every time, and you can check that list.**

## Where does the data actually go?

**Out of the ERP and into whatever client you chose, and that is your decision to audit.**

> *"**Any data movement or retention outside the customer's finance and operations environment** would be dependent on the **data storage and retention policies of the agent client** (for example, Microsoft Copilot Studio, Claude, Microsoft Foundry), and/or the client's access to other external systems."*

**Microsoft's instruction is direct:** *"**Ensure you audit the agent client's permissions to move data to other systems and the data retention policies.**"*

**The server itself holds nothing:** *"The MCP server doesn't store customer data."*

**So the read-back lives wherever your client lives**, and the retention question belongs to the platform you picked, not to Dynamics 365. **If the read-back is part of your control evidence, decide deliberately where it is kept and for how long** — because the ERP records the posting and has no opinion about your transcript.

**Organisations do get a say in the model too.** Microsoft notes that *"Organizations also control which AI service and agent client they use with the MCP server."*

**About Cognilium** Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

**Agentic ERP.** We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on **Azure OpenAI, Microsoft Fabric and Copilot Studio**. We build these on request, against your data and your environment.

**More on the boundary between what Copilot does and what you build:** [Agentic ERP on Dynamics 365](/erp-ai).

Ask any agent you are evaluating to show you the record it posted and the list of what it could not verify. If it cannot produce the second list, that is the conversation. Fifteen minutes is enough.

## Sources

- [Security for Dynamics 365 ERP MCP](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/mcp/mcp-security) · **fetched and read in full 2026-10-21**
- [Use MCP for finance and operations apps](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp) · **fetched and read in full 2026-10-21**

## Fact-check

**Tier summary:** 6 × T1 (all verbatim), 7 × T2 — **0 × T4.**

> ### ⚠️ This article is T2-heavy by necessity, and the reason is worth stating  **Microsoft publishes no read-back specification**, because a read-back is a design pattern rather than a product feature. **So §3 and §4 are ours and are labelled as ours** — there is no page to cite for "what a good read-back contains", and inventing one would be the §0 defect in its purest form.  **What is quoted is everything the platform does supply:** attribution, unbypassed validation, no data storage at the server, and the instruction to audit your client's retention. **The argument built on top of those is ours, and the article never dresses it as Microsoft's.**

> ### 🔴 One sentence this article deliberately does NOT contain  The internal source document for this cluster notes that agent output *"can vary from run to run, so outputs should be verified"* and gives read-back as our answer. **That observation is ours, from our own build notes — it is not sourced to a Microsoft page**, and the `description` field of this article was written to say Microsoft states it.  **Corrected before publication.** The description now attributes variability to no one and the body makes the argument on its own terms. **An unsourced claim wearing a vendor's name is the exact defect §0 exists to prevent**, and it nearly shipped in a metadata field nobody re-reads.

**🔴 No pricing.** No rate, cost or currency anywhere.

**No figures of ours.** No accuracy claim, no error rate, no volume, no customer. **§4 argues the unverified list is valuable without quantifying how often it appears** — we have measured no such rate.

## Frequently asked questions

### Why is reading back necessary at all?

Because a report of success and a successful posting are different objects.

### What does the platform already give you?

Attribution and ordinary processing. Both matter, and neither is a read-back.

### What should the read-back actually contain?

One — the identifiers. The document number, the line, the date. Enough that a person can find the record independently, without trusting the agent's framing.

### Why report the gap at all?

Because the alternative is silent confidence, and silent confidence is what gets discovered at month-end.

### Where does the data actually go?

Out of the ERP and into whatever client you chose, and that is your decision to audit.

---

Canonical HTML: https://cognilium.ai/blogs/what-an-agent-must-read-back-after-it-posts