DEV Community: Indu Das

Your AI agent says the tool failed. What if the action actually happened?

Indu Das — Sat, 12 Sep 2026 15:26:44 +0000

A tool call returning an error does not necessarily mean the action failed.

That sounds obvious if you have spent time around distributed systems.

It gets much more dangerous when an AI agent is the thing deciding what to do next.

Imagine this:

An agent decides to make a payment.
The payment request reaches the provider.
The provider creates the payment.
The response times out.
The agent receives an error.

From the agent's point of view:

PAYMENT FAILED

From the provider's point of view:

PAYMENT HAPPENED

Now the agent has to decide what to do next.

Retry?

If it retries blindly, you may now have two payments.

That is the problem I have been thinking about.

A tool response is not always evidence of the effect

We tend to collapse several things into one event:

agent calls tool
      ↓
tool returns result
      ↓
agent decides what happened

But consequential systems do not always work like that.

The real sequence can be:

agent calls tool
      ↓
provider accepts request
      ↓
real-world state changes
      ↓
response is lost
      ↓
tool reports an error

The tool may be completely honest.

The transport really did fail.

But the external effect also really happened.

Both facts can be true at the same time.

That makes the response useful evidence about the call, but not necessarily authoritative evidence about the final effect.

Idempotency helps, but it does not answer the whole question

The obvious answer is idempotency.

And yes, consequential tools should use idempotency wherever the underlying system supports it.

If the same payment request is repeated with the same idempotency key, the provider should not create a second payment.

That prevents one very important class of failure.

But the agent still has a question:

Did the first action actually happen?

Before deciding whether to retry, escalate, compensate, or stop, something has to establish the downstream state.

That may mean:

reading the provider state;
checking a transaction receipt;
querying the resource independently;
observing the physical side effect;
reconciling against another authoritative system.

This is where I think agent testing needs to go further than checking the model output or tool response.

There are at least three different questions

1. Was the action allowed?

This is an authorization problem.

Can this agent perform this action against this resource under this policy?

2. Was the evidence behind the action still current?

This is the problem FreshCtx addresses.

An agent may make a correct decision at 10:01.

Reality changes at 10:03.

The action executes at 10:04.

The original reasoning was not necessarily bad. It was simply no longer valid when execution happened.

FreshCtx revalidates the declared evidence immediately before the consequential action.

Conceptually:

CURRENT
→ proceed

STALE_REASONING
→ block

UNVERIFIABLE
→ block under the default policy

That is intentionally a narrow job.

FreshCtx does not claim that an authorized action will execute correctly.

And it does not claim that a tool response proves what happened afterward.

3. What actually happened?

This is a different assurance problem.

Once the action crosses the execution boundary:

Did the effect occur?
Did it occur once?
Did the agent report the same thing reality shows?
Can we establish the result independently?
If we repair the problem, does the same execution path now behave correctly?

I did not want to keep expanding FreshCtx until it became an authorization system, observability platform, execution tester and audit system at the same time.

So I separated the problem.

That became Revera

Revera is the system I built for the execution side of this problem.

The question it tries to answer is simple:

What did the AI agent actually execute?

The workflow is roughly:

discover consequential action
        ↓
reproduce execution
        ↓
observe actual effect
        ↓
diagnose
        ↓
remediate where supported
        ↓
rerun the exact path
        ↓
produce evidence

One design principle became especially important:

The system under test should not be the only authority on whether its own action succeeded.

If the agent reports:

PAYMENT FAILED

while an independent observation establishes:

PAYMENT EXECUTED

I want both facts preserved.

Not one silently replacing the other.

The uncomfortable state is sometimes "we don't know"

There is another case that matters just as much.

Suppose:

the tool returned an error;
the provider cannot currently be queried;
no authoritative receipt is available;
the effect may have happened.

Calling that FAILED is dangerous.

Calling it SUCCESS is equally dishonest.

The safest answer may simply be:

UNVERIFIABLE

or, depending on the system:

MAY_HAVE_EXECUTED

That state changes what the agent is allowed to do next.

Blind automatic retry may be exactly the wrong response.

Why exact retesting matters

There is one more place where I think agent security work often stops too early.

A failure is reproduced.

Someone generates a patch.

The code looks correct.

And the issue is marked fixed.

But:

patch generated != fix proven

For a consequential execution problem, I want the repaired path to actually run again under the relevant execution conditions.

Then observe what happened.

And also verify that legitimate behavior still works.

That is why Revera includes an exact retest step rather than treating remediation generation as the end of the workflow.

FreshCtx and Revera solve different problems

The distinction I use now is:

FreshCtx
Is the evidence still current before the action?

Revera
What actually executed, what effect occurred, and can the repair be proven?

FreshCtx remains open source.

Revera is the separate verification product.

I think keeping that boundary explicit makes both systems more useful.

I want to test Revera on real external systems, not just examples we built ourselves.

Revera is live now:

https://reveralab.com

At this stage, I am not trying to maximize signups.

I want a small number of external developers building agents that actually change something:

payments;
infrastructure;
customer records;
access;
deployments;
bookings;
approvals;
workflows.

If you have one public repository, MCP tool, or consequential action where a wrong execution would matter, send it to me.

Especially if you think Revera will get the answer wrong.

That is much more useful right now than another test against a system we built ourselves.

And I am curious about one thing from other builders:

What is one action in your agent that you would absolutely not trust it to retry blindly?

MCP Connects AI Agents to Tools. Who Checks the Evidence Before the Tool Acts?

Indu Das — Sun, 06 Sep 2026 04:29:08 +0000

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.

When an AI agent takes a consequential action, blocking stale reasoning is only part of the control problem.

Indu Das — Sat, 05 Sep 2026 15:32:21 +0000

When an AI agent takes a consequential action, blocking stale reasoning is only part of the control problem.

Organizations also need to answer:

What evidence supported the decision?
Was it revalidated immediately before execution?
Which action was allowed or blocked?
Can the resulting record be verified later?

FreshCtx 0.11.0 introduces a consistent evidence-to-action trail across MCP, Agno, LangGraph, the OpenAI Agents SDK, Google ADK and ElevenLabs.

Every protected action can now produce the same versioned correlation record, connecting the action to its declared evidence, validation result and policy decision—without copying tool arguments, credentials or business payloads.

The release also introduces bounded evidence attestation. Applications can create a time-limited integrity receipt for an exact correlation record and detect tampering, mismatched records, invalid signatures and expired receipts.

FreshCtx keeps the claim deliberately precise: verification establishes record integrity, key possession and the configured time bound. It does not pretend to prove source truth, reasoning correctness, authorization or compliance.

FreshCtx 0.11.0 is open source, Apache-2.0, local-first and available now.

Install: python -m pip install freshctx==0.11.0

https://github.com/Hyperwise-LLC/freshctx

https://pypi.org/project/freshctx/0.11.0/

AIAgents #AgenticAI #AIInfrastructure #EnterpriseAI #MCP #OpenSource #Python #AIEngineering #ResponsibleAI #AIGovernance

FreshCtx 0.8.0 is live with Google ADK support.

Indu Das — Tue, 01 Sep 2026 23:13:01 +0000

FreshCtx 0.8.0 is live with Google ADK support.
FreshCtx now maps the same pre-action freshness boundary across Agno, LangGraph, OpenAI Agents SDK and Google ADK.
We also recorded a new independent four-source research-brief rerun. An unsupported claim remained excluded until a defensible source was supplied, then re-entered the dependency map.
https://github.com/Hyperwise-LLC/freshctx

FreshCtx 0.7.0: One freshness boundary across Agno, LangGraph, and OpenAI Agents

Indu Das — Tue, 01 Sep 2026 17:05:17 +0000

AI agents can make a sound decision from information that was accurate when read, then execute after that information has changed.

That is not primarily a model-quality problem. It is an action-boundary problem.

FreshCtx 0.7.0 is now available on PyPI. This release adds a native integration for custom function tools in the OpenAI Agents SDK, alongside the existing Agno and LangGraph integrations.

What the OpenAI Agents SDK integration does

FreshCtx runs as an input guardrail immediately before a custom function tool executes.

The application declares the evidence that influenced the agent's decision. At the action boundary, FreshCtx checks that evidence again.

If the evidence is still current, the tool can run.
If it has changed, the action is stopped.
If the evidence cannot be verified under a blocking policy, the action is also stopped.
The SDK receives its native input-tool tripwire instead of a FreshCtx-specific exception.
Tool name and call ID can be recorded for audit evidence, while raw tool arguments are not persisted by FreshCtx.

This keeps the decision boundary explicit: FreshCtx does not decide whether the reasoning is correct. It checks whether the declared evidence is still valid when the application is about to act.

Why this release matters

FreshCtx now demonstrates the same invariant across three different agent runtimes:

Agno
LangGraph
OpenAI Agents SDK

The framework changes. The model changes. The tool system changes.

The freshness boundary does not.

That is the architectural point of the project. FreshCtx is not trying to become another workflow engine. It provides a small, framework-neutral control that applications can place immediately before consequential actions.

Install

python -m pip install 'freshctx[openai-agents]==0.7.0'

The package and integration were verified through protected CI across Python 3.10 through 3.13, package validation, and a clean installation from public PyPI.

A bounded example

Consider an agent that reads a subscription record, decides to grant access, and then calls a function tool.

Between reasoning and execution, the subscription status changes.

Without an action-boundary check, the tool may still grant access based on the old state. With FreshCtx, the declared subscription dependency is revalidated immediately before the tool body runs. If it changed, the tripwire fires and the action does not execute.

The same pattern applies to:

inventory and pricing changes
approvals that have been revoked or replaced
files and database records that changed mid-workflow
tool outputs that are no longer current
research sources that moved after a claim was prepared

Deliberate scope

The 0.7.0 integration covers custom function tools in the OpenAI Agents SDK. Hosted tools, built-in execution tools, handoffs, and Agent.as_tool() are not presented as covered by this release.

That boundary is intentional. A reliability control should state exactly where it runs and what it protects.

Try one concrete test

If you use the OpenAI Agents SDK, change one declared dependency after the agent reasons but before a consequential function tool executes. Then check whether the stop happens at the point your workflow expects.

FreshCtx is open source and Apache-2.0 licensed.

FreshCtx 0.6.0: Stop AI agents from acting on stale data

Indu Das — Tue, 01 Sep 2026 03:44:42 +0000

AI agents do not need to hallucinate to make the wrong decision.

They can read accurate information, reason correctly, and still take the wrong action because the information changed before execution.

That is the problem FreshCtx is built to address.

The same failure keeps appearing in different systems

Developer feedback around FreshCtx surfaced several versions of the same underlying problem:

A subscription status changed in Stripe, but an application acted on its old snapshot.
A deployment worker continued after another worker had already claimed the job.
An agent relied on remembered database action items instead of checking their current status.
A research source changed after a claim had been prepared.
A voice workflow reached an outdated business record after correctly understanding the request.

Different industries and different tools, but the same gap:

The reasoning was valid when produced, but stale when executed.

What changed in FreshCtx 0.6.0

FreshCtx now provides the same pre-action freshness boundary across several practical environments:

Stripe Subscription validation
An Agno pre-tool integration
Synchronous LangGraph action-node wrappers
Asynchronous LangGraph action-node wrappers
Selective revalidation of only the evidence an action declared
Audit evidence explaining why an action was allowed or blocked

The LangGraph integration checks the evidence an action depends on immediately before the node runs. If a required dependency changed or cannot be verified, FreshCtx blocks before the node body starts.

FreshCtx does not replace LangGraph routing, retries, checkpointing, transactions, or idempotency. It adds the missing freshness check at the point where reasoning becomes action.

Why framework neutrality matters

Agno and LangGraph have different execution models. Stripe is not an agent framework at all.

The integration changes, but the control remains consistent:

An action declares the evidence it depends on.
FreshCtx checks that evidence again at the action boundary.
Changed or unverifiable evidence prevents the action from silently continuing.
The application retains control over what happens next.

The framework can change. The model can change. The tool system can change.

The freshness boundary does not.

Try FreshCtx 0.6.0

Install the core package:

python -m pip install freshctx==0.6.0

Install it with LangGraph support:

python -m pip install 'freshctx[langgraph]==0.6.0'

GitHub: https://github.com/Hyperwise-LLC/freshctx
PyPI: https://pypi.org/project/freshctx/0.6.0/
Release notes: https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.6.0

If you are building an agent that changes records, triggers workflows, approves transactions, or operates tools, what evidence would you want checked one last time before the action runs?

FreshCtx 0.5.0: protecting Agno tools from stale external evidence

Indu Das — Mon, 31 Aug 2026 17:55:05 +0000

FreshCtx 0.5.0 is now public.

This release adds an optional integration for Agno 2.9. The integration places FreshCtx at Agno's actual tool boundary, where it can re-check the external evidence that an application declared when it made a decision.

The problem is simple:

An agent reads a deployment state, account status, API response, approval, or other mutable source.
It reasons from that source.
The source changes before the tool executes.
The old decision still looks locally reasonable, but it is no longer based on current evidence.

What the Agno hook does

FreshCtx now provides synchronous and asynchronous Agno hooks.

The hook runs immediately before the tool body. If a declared dependency changed, or cannot be verified under the configured blocking policy, FreshCtx stops execution before the side effect occurs.

Install it with:

python -m pip install 'freshctx[agno]==0.5.0'

A tool can attach the boundary directly:

from freshctx.integrations.agno import agno_tool_hook

freshness_hook = agno_tool_hook(
    depends_on=[decision],
    store=store,
    audit_path="freshctx-agno-audit.jsonl",
)

@tool(tool_hooks=[freshness_hook])
def deploy(target: str) -> str:
    return f"deployed:{target}"

This is deliberately narrow. FreshCtx does not repair Agno's internal run state and does not replace transactions, idempotency, concurrency control, or approval logic. It protects the application-declared external evidence behind a tool call.

Verification

Before publishing, the release passed:

87 regression tests
protected CI across Python 3.10 through 3.13
Windows onboarding and package checks
wheel and source-distribution validation
a clean installation from the public PyPI index
an installed Agno example using Agno's real tool chain

In the bounded example, the dependency changes after the decision is created. FreshCtx returns STALE_REASONING, the Agno run is stopped, and the tool body is not executed.

Release: https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.5.0

Repository: https://github.com/Hyperwise-LLC/freshctx

If you are already using Agno for a consequential tool call, I would value an honest run against one bounded scenario - including anything the integration does not model correctly.

FreshCtx 0.3.0: What changed after developers tested the stale-context boundary

Indu Das — Mon, 31 Aug 2026 00:37:49 +0000

FreshCtx 0.3.0 is now public.

The first release started with a narrow problem:

An AI agent can make a reasonable decision from accurate information, then act incorrectly because that information changed before execution.

The early implementation proved that FreshCtx could declare the evidence used during reasoning, revalidate it at the action boundary and block an action when the evidence was no longer current.

The questions developers asked after launch were more practical:

What happens when several dependencies must be checked?
Does revalidation add too much latency?
What if a source is slow or rate-limited?
Can it work inside an async agent?
What happens when the local database is upgraded or damaged?
How can an independent developer record what a test actually proved?

Version 0.3.0 turns those questions into working features and tests.

What FreshCtx does

A FreshCtx workflow has three important moments:

The application observes the evidence used by the agent.
It declares which evidence the reasoning depends on.
FreshCtx revalidates that evidence immediately before the protected action.

from freshctx import FreshnessBlocked, guard, observe, reasoning

try:
    with guard() as ctx:
        approval = observe("approval.json")

        with reasoning("release_payment", [approval]) as decision:
            payment = prepare_payment()

        ctx.run(
            send_payment,
            payment,
            depends_on=[decision],
        )

except FreshnessBlocked as blocked:
    print(blocked.result.state.value)

If approval.json changes before send_payment runs, the action is blocked.

FreshCtx does not decide whether the payment is sensible. It checks whether the declared evidence behind that decision is still current.

Native async support

Agent services increasingly run inside asynchronous applications. FreshCtx 0.3.0 adds an async context manager, async validation and protected async actions.

async with guard() as ctx:
    approval = observe("approval.json")

    with reasoning("confirm_booking", [approval]) as decision:
        booking = prepare_booking()

    await ctx.run_async(
        confirm_booking,
        booking,
        depends_on=[decision],
    )

Synchronous adapter validation is moved away from the event-loop thread. The same blocking, audit and fail-closed behavior still applies.

The original synchronous API remains unchanged.

Concurrent dependency validation

Checking dependencies one at a time can become expensive when an action depends on several independent sources.

FreshCtx now supports bounded concurrent validation:

with guard(
    validation_workers=8,
    validation_budget_ms=500,
) as ctx:
    result = ctx.check(decision)

Concurrency is opt-in. The default remains one worker for compatibility.

An adapter must explicitly declare that it is thread-safe before FreshCtx runs it concurrently. Adapters that do not make that declaration remain sequential.

This matters because an application-supplied client, MCP session or transport may not be safe to call from multiple threads.

Validation budgets

A source may be slow, unavailable or rate-limited.

FreshCtx now supports a total decision-validity budget. If validation does not finish within that budget, unfinished evidence becomes UNVERIFIABLE.

It is not silently treated as current.

FreshCtx also records:

Per-dependency validation duration
Total validation duration
Worker count
Configured validation budget
Whether validation ran sequentially or concurrently

The budget is not unsafe thread cancellation. A validator that has already started is allowed to reach its adapter-specific timeout, but its late result is discarded. No validator is left running after the check returns.

A bounded performance result

We tested both wide and deep synthetic graphs containing 128 dependencies.

With eight validation workers, the observed p95 results were:

Graph	Sequential p95	Concurrent p95
Wide	181 ms	29 ms
Deep	179 ms	29 ms

Both paths evaluated all 128 dependencies and returned CURRENT.

These numbers are an engineering baseline, not a production latency claim. Real performance will depend on source behavior, network latency, timeouts, adapter implementation and the structure of the protected workflow.

The benchmark is included so anyone can reproduce it or change the graph size:

python scripts/benchmark_validation.py \
  --width 128 \
  --workers 8 \
  --delay-ms 1 \
  --iterations 5

Store migration and integrity checks

FreshCtx uses a local SQLite store by default.

Version 0.3.0 adds:

Transactional schema versioning
Forward migration of existing stores
Integrity checking
Rejection of unsupported future schemas
Clear corruption and migration errors

A store created by the original v0.1 API can be opened without rewriting its existing observation and reasoning objects.

If a store is damaged, FreshCtx does not guess or treat its contents as current.

New command-line tools

FreshCtx now installs a command-line interface.

Check the installation and local store:

freshctx doctor --store .freshctx/freshctx.db

Check a stored subject:

freshctx check SUBJECT_ID \
  --store .freshctx/freshctx.db

Summarize an audit trail:

freshctx audit \
  --audit .freshctx/audit.jsonl

The commands operate locally. They do not require an account or upload evidence to a hosted service.

Adapter conformance now fails closed

FreshCtx adapters must return one of three results:

equivalent
changed
indeterminate

Version 0.3.0 adds a shared conformance layer.

If an adapter returns an invalid type or unsupported outcome, FreshCtx converts it to UNVERIFIABLE instead of accepting an ambiguous result.

This protects the enforcement boundary from an incorrectly implemented extension.

Recording independent results

The release also includes a portable validation-report schema.

An external test can now record:

The exact FreshCtx version
Whether installation came from PyPI, a wheel or source
The tested environment
Expected and observed behavior
Pass, fail or inconclusive verdict
Evidence locations
Limitations
Validator identity, when provided

This is deliberately a bounded result format.

A successful test of one scenario is evidence for that scenario. It is not automatically a security certification, production validation or proof that every agent integration is safe.

Release verification

FreshCtx 0.3.0 passed all of its defined release gates:

68 automated tests
Python 3.10, 3.11, 3.12 and 3.13
Windows onboarding
Static analysis
Dependency audit
Package and metadata verification
Clean installation from public PyPI
Async, payment, booking, voice-agent and manual preflight scenarios
Wide and deep 128-dependency benchmarks

The public package was then installed into a brand-new environment and verified again.

Try it

pip install freshctx==0.3.0
freshctx demo
freshctx doctor

PyPI:

https://pypi.org/project/freshctx/0.3.0/

GitHub:

https://github.com/Hyperwise-LLC/freshctx

Release notes:

https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.3.0

What comes next

This completes the current FreshCtx Core milestone.

We are testing the published package against real agent workflows involving mutable files, APIs, databases, approvals, bookings and MCP resources.

If you operate an agent that revalidates information before a write, I would be interested in one specific question:

Where do you currently place that boundary - inside every tool, inside the agent harness or in a separate control layer?

I am looking for developers willing to run one bounded scenario from a clean pip install freshctx==0.3.0 environment and publish the result either way.

An AI agent can make a reasonable decision from accurate information—and still take the wrong action.

Indu Das — Fri, 28 Aug 2026 19:16:30 +0000

The problem is timing.

Business systems do not pause while an agent reads data, calls tools, reasons, waits for approval, or prepares an action.

During that interval:

An account can be frozen.

A payment authorization can be withdrawn.

Inventory can be sold.

A price can change.

A policy can be revised.

A configuration file can be updated.

An API or database can become unreachable.

The agent may still be holding a conclusion derived from the earlier state.

The gap between checking and acting

Most production systems already have important controls.

Payment workflows have rules and approvals. Healthcare operations have authorization and access controls. E-commerce platforms have inventory and fulfillment checks. Engineering teams use GitHub, pull requests, branch protection, and CI/CD.

Those controls remain necessary.

But many of them establish whether something was valid when it was checked. An AI-supported workflow also needs to know whether the evidence supporting its current conclusion is still valid when the action is about to happen.

That is the reasoning-to-action freshness gap.

It resembles a time-of-check-to-time-of-use problem, but it also affects the reasoning derived from the changed source—not only the source itself.

Three examples

Payments

An agent reviews an account, beneficiary status, risk result, and approval records before preparing a payment.

Before execution, a fraud signal changes or the account is placed on legal hold.

The earlier reasoning may have been reasonable when it was produced. But the evidence supporting it is no longer current, so the payment should not proceed on the old conclusion.

Healthcare operations

An automated workflow reads an authorization or scheduling record. The authorization changes—or its source becomes unreachable—while the workflow is underway.

The workflow should not silently treat its earlier snapshot as current.

Freshness validation can complement operational and compliance controls. It does not replace clinical judgment, authorization policy, privacy safeguards, or regulatory review.

E-commerce

An agent prepares an order using inventory, price, fraud, and delivery-capacity evidence.

Before fulfillment, the inventory falls below the requested quantity.

The inventory observation is now stale. The fulfillment reasoning that depended on it must also be reconsidered. An unrelated fraud result, however, may still be current.

That distinction matters. Invalidating everything is safe but inefficient. Invalidating nothing is dangerous.

What FreshCtx does

Today, I’m releasing FreshCtx™ v0.1, an Apache-2.0 open-source freshness and dependency-validation runtime for AI agents.

FreshCtx records the declared sources an agent observed, connects downstream reasoning to those observations, and revalidates the dependencies at a protected action boundary.

It produces four explicit states:

CURRENT: every reachable, declared dependency was successfully revalidated as equivalent.

STALE_SOURCE: an observed source changed.

STALE_REASONING: reasoning depends on stale evidence.

UNVERIFIABLE: FreshCtx could not safely determine whether the dependency is still current.

UNVERIFIABLE never silently becomes CURRENT.

The configured policy can block, warn, allow, or perform one bounded refresh. Blocking is the default.

Install it

FreshCtx supports Python 3.10 through 3.13.

python -m pip install freshctx==0.1.0

To use the optional Postgres adapter:

python -m pip install 'freshctx[postgres]==0.1.0'

No account is required, and the runtime sends no telemetry.

A minimal example

Imagine an agent selecting a deployment target from a configuration file:

from pathlib import Path
from tempfile import TemporaryDirectory

from freshctx import MemoryStore, guard, observe, reasoning

def deploy(target: str) -> None:
print(f"DEPLOYED to {target}")

with TemporaryDirectory() as directory:
root = Path(directory)
config = root / "deployment.env"
audit = root / "freshctx-audit.jsonl"

config.write_text("TARGET=staging\n", encoding="utf-8")

with guard(
    policy="block",
    store=MemoryStore(),
    audit_path=audit,
) as ctx:
    source = observe(config)

    with reasoning(
        "choose_target",
        depends_on=[source],
    ) as decision:
        target = "staging"

    ctx.run(
        deploy,
        target,
        depends_on=[decision],
    )

print(f"FreshCtx state: {ctx.result.state.value}")
print(f"Audit file: {audit}")

Expected output:

DEPLOYED to staging
FreshCtx state: CURRENT
Audit file: /.../freshctx-audit.jsonl

Before deploy() runs, FreshCtx revalidates the declared dependency.

If the configuration changes after observation, the source becomes STALE_SOURCE, the dependent decision becomes STALE_REASONING, and the protected action is blocked.

Dependency-aware invalidation

FreshCtx does not automatically invalidate every conclusion whenever anything changes.

Suppose an audit contains three findings:

retention policy ──> retention finding
access evidence ──> access finding
backup evidence ──> backup finding

If only the retention policy changes, FreshCtx can mark the retention observation STALE_SOURCE and its dependent finding STALE_REASONING.

The access and backup findings can remain CURRENT.

FreshCtx follows the declared dependency graph rather than treating the entire workflow as one undifferentiated cache entry.

What CURRENT does—and does not—prove

CURRENT means that every reachable, declared dependency was successfully revalidated as equivalent under its configured adapter at check time.

It does not prove:

The source itself is true.

The agent’s reasoning is correct.

The action is authorized.

The action is safe or compliant.

Every relevant dependency was declared.

The wider world has not changed.

FreshCtx validates the freshness of declared dependencies. It is not a truth engine, authorization system, policy engine, or compliance certification.

Why CI/CD is not enough

CI/CD establishes that a particular commit passed its configured checks.

FreshCtx answers a different question:

Is the evidence supporting this specific action still current now?

A CI pipeline can verify a commit. FreshCtx can revalidate the declared Git path, file, API response, database row, or MCP resource supporting an agent’s current action.

GitHub and CI/CD remain essential. FreshCtx operates at the reasoning-to-action boundary they do not cover.

Similarly, memory tells an agent what it previously knew. FreshCtx checks whether that knowledge is still current.

Adapters in v0.1

FreshCtx v0.1 includes adapters for:

Filesystem

Git

HTTP

Postgres

MCP

The runtime is local-first, model-neutral, and framework-neutral. It does not require OpenAI, Anthropic, LangChain, or any other particular model or agent framework.

It also includes local JSONL audit events, SQLite and in-memory stores, machine-readable schemas, a documented adapter contract, security semantics, and executable reference scenarios.

Try the drift demos

Clone the repository and run the three reference demonstrations:

git clone https://github.com/Hyperwise-LLC/freshctx.git
cd freshctx

python -m venv .venv
source .venv/bin/activate

python -m pip install .
python examples/coding_file_drift.py
python examples/configuration_api_drift.py
python examples/audit_reasoning_drift.py

The examples demonstrate:

A file changing after an agent observes it.

An API-backed configuration changing while reasoning is underway.

Evidence supporting only one audit finding changing while unrelated findings remain current.

Project links

FreshCtx repository

README and quickstart

FreshCtx v0.1.0 release

PyPI package

Versioned specification

Adapter contract

Security model

Validated reference scenarios

FreshCtx™ is an independent Apache-2.0 open-source project owned and stewarded by Hyperwise LLC.

If you build AI-supported workflows that act on mutable systems, I would be interested to hear where the reasoning-to-action freshness gap appears in your architecture—and which sources your agent would need to revalidate.

_Disclosure: I am associated with the team releasing FreshCtx. AI-assisted editing was used to improve the structure of this article. The technical claims, examples, and final text were reviewed against the released FreshCtx v0.1.0 implementation and documentation.

The Missing Layer in Modern Supply Chains: Execution

Indu Das — Tue, 03 Feb 2026 04:44:20 +0000

Why visibility, planning, and control towers still fail without an execution layer

For the last decade, supply chains have invested heavily in visibility, analytics, and planning systems.

We can see disruptions in real time.
We can simulate scenarios.
We can forecast demand with increasing accuracy.

Yet supply chains still break at the same point: execution.

When a disruption occurs, the hard questions are not analytical—they are operational:
• Who reallocates inventory?
• Which orders get substituted?
• Which constraints apply?
• Which partners act first?
• How do we confirm the decision was executed?

Most organizations answer these questions manually, through meetings, spreadsheets, and escalations. That’s not a tooling failure. It’s a missing system layer.

The execution gap

Visibility tells you what happened.
Planning tells you what should happen.
Control towers tell you where attention is needed.

None of them ensure coordinated action across a multi-tier supply chain network.

This gap becomes more severe as supply chains grow more complex:
• Multiple suppliers
• Distributed warehouses
• External logistics partners
• Regulatory and contractual constraints
• Shared responsibility across organizations

At that point, execution can’t remain informal.

What is a supply chain execution layer?

A supply chain execution layer is the operational software layer that coordinates and enforces real-time decisions across multi-hierarchical supply chain networks.

It translates plans, constraints, and signals into executable actions across suppliers, warehouses, distributors, and retailers—and tracks what actually happened.

This layer sits above existing systems like ERP, WMS, TMS, and POS.
Those systems remain in place. The execution layer operates across them.

How it differs from existing systems
• ERP systems record transactions and internal processes.
• Planning systems optimize forecasts and scenarios.
• Control towers provide visibility and alerts.

An execution layer does something different:
• Validates decisions against constraints
• Orchestrates actions across parties
• Coordinates timing and responsibility
• Creates accountability for outcomes

Execution is not a feature.
It’s a system role.

Why this matters now

Modern supply chains are no longer linear or single-owner systems. They are shared networks.

In shared networks:
• Decisions have downstream effects
• Constraints vary by partner
• Accountability is distributed
• Manual coordination does not scale

Without an execution layer, organizations end up with excellent insight and inconsistent action.

Resilience is not achieved at planning time.
It is achieved at execution time.

A practical example

Consider a late supplier shipment.

Visibility tools detect it.
Planning tools recalculate scenarios.

But execution requires:
• Reallocating inventory across nodes
• Substituting SKUs within constraints
• Rerouting fulfillment paths
• Coordinating approvals across organizations
• Confirming actions were completed

Without an execution layer, this work happens outside the system.
With one, it becomes coordinated, auditable, and repeatable.

Where this fits in practice

At Opsis, we’re building systems designed to operate as this execution layer—coordinating real-time decisions across multi-hierarchical supply chain networks while operating above existing enterprise systems.

For a concrete explanation of how this layer works in practice, see:
👉 https://opsisone.com/execution-layer