When permission expires, PromisePatch knows when not to act.
One disruption, six promises: 2 recovered, 2 need the owner, 2 untouched.
Reality changed after approval, so PromisePatch refused the stale permission.

Inspiration

A failed delivery sounds like an inventory problem. But once products have already been promised to customers, it becomes a permission problem.

One customer may have pre-approved a substitution. Another may need to be asked. A third may have explicitly forbidden substitutions. Some orders may not be affected at all.

That led to the core question behind PromisePatch:

Can an AI help recover disrupted orders without treating every technically possible action as an authorized one?

What it does

PromisePatch is a consent-aware recovery system for disrupted customer orders.

In our demo, one failed raspberry delivery affects six promises differently:

A can be recovered under an existing customer preference.
B requires the customer’s approval.
C and D cannot be safely changed and are handed to the owner.
E and F are unrelated and remain untouched.

The successful run ends with:

2 recovered · 2 need the owner · 2 untouched

But the key idea goes further: permission can become stale.

In a separate run, the customer approves a substitution for one cake at order version 1. Before PromisePatch acts, the order is deliberately changed to two cakes at version 2.

PromisePatch reads the fresh state again, detects that the approval no longer matches reality, records the recovery as STALE, and sends no recovery amendment for that order.

When permission still matches reality, PromisePatch acts.
When reality changes, it doesn’t.

How we built it

PromisePatch separates language understanding from authority.

Amazon Bedrock with Nova 2 Lite interprets the worker’s conversational intent and selects among a bounded set of actions.

A self-hosted MCP server using Streamable HTTP exposes the operational workflow. Our simulated Alexa+ experience is a case-scoped MCP client: a worker can interact conversationally with the real deployed MCP endpoint.

But neither Bedrock nor MCP can invent human authority.

A human plan approval is recorded separately through the authenticated browser. MCP can later spend that existing approval, but it cannot create one. Customer consent is also separate and arrives through a signed approval link.

Before any approved recovery is committed, deterministic code re-reads current state and checks whether the permission still applies.

The deployed system runs on AWS using:

Amazon Bedrock
EC2
RDS PostgreSQL
ECR
IAM
SSM Parameter Store
CloudWatch
CloudFormation

Telegram is used for the real outbound customer approval request.

Challenges we ran into

The hardest problems were not generating text. They were preserving authority and fresh state across a workflow that can pause, restart, and change underneath us.

We had to answer questions such as:

Who is actually allowed to approve this action?
What happens if the customer answers after the order has changed?
Can an MCP service credential accidentally impersonate a human?
Can a recovery safely resume after the worker restarts?
How do we prove that unaffected orders truly received no incident effects?

We also encountered practical AWS deployment friction, including EC2 container access to IMDS credentials, conservative handling of CloudFormation change sets, and validating a tightly scoped IAM role across several AWS services.

Those experiences are documented in our friction log.

Accomplishments that we're proud of

The strongest result is not a benchmark score—it is the visible difference between two almost identical situations:

Control run:
The customer approves, the world is unchanged, revalidation passes, and the recovery is applied.

Changed-world run:
The customer approves, the order changes, fresh-state revalidation fails, and PromisePatch refuses the stale permission.

We also demonstrated live that:

Bedrock selected CONFIRM.
The real MCP endpoint executed the confirmation.
MCP used a human approval that already existed.
No additional human approval was created by MCP.
Customer consent remained a separate authority.
Unaffected orders received zero incident effects.
Recovery survived worker restarts without duplicating the external order changes.

What we learned

The main lesson is that finding a good action is different from being allowed to perform it.

For consequential agents, the model should not be the final authority.

We found a much stronger pattern:

candidate action → permission → human authority → fresh-state revalidation → act or refuse

That lets the model remain useful for understanding and orchestration while deterministic code protects the boundary between suggestion and consequence.

What's next

PromisePatch is currently a working prototype built around a constructed bakery scenario and a simulated external order system.

The initial target would be small custom-order food businesses where ingredient disruptions affect both customer promises and production work.

A production version would require:

integration with a real order/catalog system,
business-specific substitution and permission policies,
customer-channel configuration,
onboarding and validation with real operators.

We do not claim a merchant pilot or measured ROI yet. The next meaningful step is validating whether this permission-aware recovery workflow actually reduces operational work for real businesses.