u/HotPocketWaves

Disclosure: I'm the founder and this is my project. The overview link is in the comments, per the sub rules.

The problem I kept running into: an agent calls a tool that charges a card, issues a refund or places an order. The response gets lost or times out. The agent retries. With nothing sitting between the agent and the tool, that retry can turn into a second charge.

What I built is AMW (Agent Middleware), a governed MCP gateway between the agent and the tool. Agents act under a permit; a same-key retry returns the original receipt, no second call or charge. The permit sets which tools are allowed, a credit budget and an expiry, and calls outside it are refused before anything is charged. Every call gets a signed receipt you can check offline.

Where it stops, because I'd rather say it up front: a retry under a new key is treated as a new call, within the permit's budget and expiry. If the response is lost after the call already went out, AMW marks it uncertain and does not resend it on its own. Whether the remote side effect happens once still depends on the tool honoring the key.

Honest stage: pre revenue, no customers. One outside developer is testing it on staging right now. I'm a non technical solo founder in Pasadena and have been building it with AI assistance since February.

Two asks:

1. If you run agents against tools that change state, how do you handle a timed out call today, and what still breaks?
2. I'm also looking for a technical cofounder to own engineering. Equity only until a raise, written terms, remote is fine.

Blunt feedback welcome. I'd rather hear what is wrong now than after a pilot.

I’m building Agent Middleware API, an open-source control layer for autonomous agent actions.

The narrow goal is not “another agent framework.” It is infrastructure for the moment an agent wants to do something with a real tool:

discover -> authenticate -> authorize -> invoke -> meter -> receipt -> audit -> govern

The current repo focuses on governed MCP/tool invocation. A tool call can be scoped by a signed permit, checked against wallet/tenant authority, run through a governed adapter, idempotency-protected, metered, charged once, receipted, and written into a tamper-evident audit chain.

There is also an AWI-over-MCP proof surface for web agents: semantic web actions, progressive representations, human intervention controls, and draft action vocabulary docs. I’m treating AWI as a workload that exercises the trust plane, not as the core product.

The main proof command is:

make prove-trust-plane

It checks the full loop: discovery, signed permit issuance, valid governed MCP call, one-time wallet charge, signed receipt, audit-chain verification, replay without double charge, denied out-of-scope action, and tamper detection for receipt/audit evidence.

I’m looking for critique on the architecture, especially:

• Should the core wedge be MCP governance, signed receipts, or metering?
• Is the permit/receipt/audit model enough to be useful to security reviewers?
• What would make this credible as infrastructure rather than a demo-heavy agent backend?

This is production beta, not production complete. I’m trying to keep the claims narrow and make the trust loop falsifiable.