An AI agent reads a customer record and decides to issue a refund.
Before it acts, the work is delegated to another agent. That agent eventually calls a payment tool through MCP.
But the customer record changed in the meantime.
The reasoning may have been valid when it was produced. The tool call may also be technically correct. Yet the action is now based on evidence that is no longer current.
That gap exists between reasoning and execution—and it becomes harder to see when work crosses agent boundaries.
A2A and MCP solve different parts of the system
Agent-to-Agent Protocol (A2A) gives agents a standard way to delegate work.
Model Context Protocol (MCP) gives agents a standard way to discover and call tools.
These protocols make increasingly capable agent systems possible, but they do not automatically prove that the evidence behind a delegated decision is still current when a consequential tool executes.
The sequence can look like this:
Agent A reads evidence
↓
Agent A forms a decision
↓
Agent A delegates through A2A
↓
Agent B or Agent C receives the task
↓
An MCP tool is about to execute
The evidence can change anywhere between the first and final steps.
The boundary I wanted
I wanted the final tool boundary to answer one narrow question:
Is the declared evidence behind this specific action still current?
The result should be unambiguous:
CURRENT: the selected evidence has not changed, so the tool may proceed.
STALE_REASONING: required evidence changed, so the tool is blocked.
UNVERIFIABLE: the evidence cannot be checked reliably, so the tool is blocked.
CURRENT does not mean the agent selected the right source, interpreted it correctly, or made a safe decision. It means only that the declared evidence remained unchanged.
That distinction is deliberate.
What I built
FreshCtx 0.14.0 carries a signed, expiring, recipient-bound evidence receipt across A2A delegation.
The receiving agent validates that receipt before delegated execution reaches MCP’s native tools/call boundary.
The receipt preserves:
the observation linked to the decision;
parent and root correlation across delegation;
the intended recipient;
issue and expiry times;
integrity protection against tampering.
It deliberately excludes prompts, credentials, source contents, tool arguments, and business payloads.
If a receipt is missing, expired, modified, or presented to the wrong recipient, execution is rejected before the receiving agent runs the protected action.
A three-agent demonstration
The repository includes an executable path with three agents:
Originating agent
↓ A2A
Delegated agent
↓ A2A
Executing agent
↓ MCP tools/call
Consequential tool
It demonstrates three outcomes:
Evidence unchanged → MCP tool executes once
Evidence changed → tool does not execute
Evidence cannot be read → tool does not execute
It also tests missing, expired, tampered, and wrong-recipient delegation receipts.
The point is not to create another agent framework. It is to keep the same evidence-validity rule intact as execution travels through different frameworks and protocols.
The same invariant across multiple runtimes
FreshCtx now maps this boundary across:
MCP
A2A
Agno
LangGraph
OpenAI Agents SDK
Google ADK
ElevenLabs Python tools
Each platform exposes a different interception mechanism, but the operating rule remains:
Observe → Reason → Revalidate → Act
If required evidence is stale or cannot be verified, the consequential action does not execute.
Where I would value scrutiny
The receiving A2A AgentExecutor is currently the enforcement point before delegated execution continues.
I would particularly value feedback from people operating A2A or MCP systems:
Is the receiving executor the correct universal boundary?
Can delegated execution bypass it in a real architecture?
Which consequential MCP tool should this be tested against next?
What audit evidence would your production review require?
I maintain FreshCtx, and I am looking for concrete implementations and failure cases—not general endorsements.
Install the current release:
python -m pip install "freshctx[a2a-mcp]==0.14.0"
GitHub: https://github.com/Hyperwise-LLC/freshctx
PyPI: https://pypi.org/project/freshctx/0.14.0/
If your agents delegate work before calling tools, I would be interested in seeing where this boundary holds—and where it does not.
Top comments (1)
The staleness check and the execution record are two separate audit concerns. FreshCtx answers whether the evidence was current at decision time, but a production audit also needs to prove what the tool actually received, what it returned, and that neither field was altered after the fact. Those two boundaries are orthogonal: you can have fresh evidence driving a tool call that leaves only mutable internal logs. For the execution record side, routing the
tools/callthrough a certifying proxy (ArkForge does this for MCP) produces a signed, timestamped receipt anchored in a public append-only log - independently verifiable without trusting the agent's own infrastructure. That combination - freshness gate before execution, tamper-evident record after - is probably what a serious production audit trail requires.