Heap-4

Inspiration Something I dread, as a solo founder, is the potentially overwhelming amount of comments or fixes that need to happen within a short period of time for user retention and enjoyability in an app. I initially wanted something that would scrape the web or bug that user submitted, then fixed them for me. However, this is very security-vulnerable and not good practice. I did see a future product in this though, so I determined the next steps would be to create a minimal yet compliant demo that did some variation of this.

That variation landed to be: a user does something, something else goes wrong --> how do we still get it to work? Well, the intention was still there (evidence, what went wrong, why--like an obvious invoice needing to be sent).

Heap 4 was inspired by that gap: applications preserve errors, but often lose the user’s intention, partial progress, and safe next steps.

*Quick side note on the name: I typically utilize random DSA terms with a number because it sounds cool on miscellaneous projects. AI did not come up with this name (however apparent it may or may not be).

The core idea is: Developers define what is legal. The agent discovers what will work. Heap 4 verifies every step. --> define a set of parameters, let the agent do the rest so you don't over-engineer the app with a load of try/catch or if/else statements.

What Heap 4 Does Heap 4 is a runtime for unfinished workflows. It captures: The user’s desired outcome What has already succeeded The failed route and runtime evidence Available capabilities Policies and constraints Invariants that must never be violated An agent can then inspect the situation, choose and sequence available actions, observe failures, and replan. The agent does not receive unrestricted access or authority to mutate arbitrary state. Every action is verified by deterministic application code.

The Demo The concrete example is invoice delivery.

The user wants Acme Corporation to read invoice INV-2841 for $4,850. The invoice is successfully persisted, but the email provider fails with an HTTP 500. Retrying the whole operation could create a duplicate invoice, so Heap 4 preserves the existing invoice and marks the workflow as interrupted.

The agent then: Inspects the interruption, customer policy, and available contacts. Attempts Acme’s preferred procurement portal. Observes that the portal is unavailable. Selects Dana Lee, the designated acting AP approver, rather than an archival mailbox. Requests approval for a temporary one-hour, read-only access grant. Creates the scoped grant. Discovers that creating authority alone does not deliver it. Sends a policy-compliant notice without attaching the invoice. Continues monitoring the original email route while Acme remains unblocked. Resumes the existing invoice after a human approves the bounded repair. Revokes the temporary share link. Verifies that the invoice was sent, no duplicate was created, and temporary access has stopped. The application does not contain a single recover_invoice button or a hardcoded “if portal fails, send a link” branch. It exposes smaller primitives whose availability changes with server-authoritative state.

How I Built It Heap 4 is built with TypeScript, React, Vite, and native WebMCP. Moreover, help with agents (Codex, GitHub Copilot), although strictly code-only, nothing with idea development.

The system is split into three responsibilities: The agent interprets evidence, chooses parameters, sequences primitives, and replans. Heap 4’s runtime preserves intent, exposes state-gated capabilities, and coordinates recovery. The server enforces policy, authorization, state transitions, and invariants. The invoice workflow uses a server-authoritative state machine:

active → blocked → mitigated → resumable → completed

The alternate route is deliberately staged. Creating a share grant does not satisfy the outcome. A separate send_access_notice capability must verify the recipient, message, attachment choice, and current customer policy before delivery is recorded.

The share link is implemented as a real capability:

Scoped to one invoice Limited to read_invoice_only Expiring Revocable Stored server-side only as a SHA-256 digest Returned as plaintext only once Tracked with a server-stamped first-access timestamp The repair path is separately bounded. A repair worker reproduces the failure, validates a narrow candidate change, and prepares it for review. Deployment requires explicit human approval. Once deployed, the agent can resume only the unfinished delivery step.

The application runs locally through Express and is also deployed as a Cloudflare Worker with D1-backed session state. Native WebMCP registration is used where supported. For browser-agent hosts that can inspect the page but cannot invoke native WebMCP tools, the application provides clearly labeled, parameterized compatibility controls that call the same server-verified transitions.

What I Learned I was able to answer a tough question: when does something go form: "a human could engineer this"; "an architecture's best practices should contain fallbacks"; and whatnot. It led me to: a route selector is not enough to demonstrate useful agency. A workflow becomes meaningfully agent-native when the agent must compose multiple independently verified operations whose sequence depends on policy and runtime evidence.

Challenges As stated before, I struggled a lot. Not with "what do I want this to be", but rather: "where does agency really belong in a website/workflow?"

I had to really separate authority from agency. It was obvious that an agent cannot be responsible for actions, nor should it. However, what use does it bring if it cannot do what's convenient nor has the authority to do so?

The second issue I had to tackle was the limitation of the nature of WebMCP: "what can an agent do for me that might be something I don't want to do for myself?" I'm under the impression that an agent with WebMCP strictly does the things you can but with slightly more knowledge and efficiency.

Both of the issues were resolved with agency belongs in orchestration; authority belongs in deterministic application code.

The agent is allowed to inspect evidence, choose parameters, compose legal primitives, react to failures, and replan. Heap 4 remains responsible for authorization, policy enforcement, state transitions, invariants, and human approval for deployment. The agent can propose and initiate actions, but it cannot directly mutate arbitrary state or make an unsafe action legal.

The second question was harder because, for one workflow, a human can often do the same things. A human can select a contact, choose a duration, click a button, and revoke a link. WebMCP does not make the agent magically capable of actions a user could never perform.

The value is continuity and coordination. In a normal system, someone would need to notice the failure, understand what already happened, interpret the customer’s policy, choose a valid recovery, monitor the repair, return later, resume only the unfinished step, revoke temporary access, and verify the final state. That is manageable once. It becomes expensive and unreliable across thousands of interrupted workflows.

In this project, the agent handles that orchestration while Heap 4 keeps it bounded. It does not receive a single “fix everything” capability. It receives specific tools whose availability changes with the workflow state. It must inspect the situation, attempt the preferred route, react to the outage, request approval for a disclosure change, compose the grant and notice steps, and clean up afterward. <--The earlier defined 'parameters'.

A final issue: browser support. The testing browser could report that native WebMCP was unavailable and could not invoke page-defined tools. I intentionally did not install a fake production polyfill. Instead, I added a transparent compatibility path and kept its controls parameterized, so the agent still has to choose the contact, duration, message, attachment handling, and sequence.