Worked integration
A verified outcome in the loop
A worked LangGraph example shows how an agent runtime can verify delivered work, read earned value from a signed Spoolis Outcome Receipt, and gate its own payment step on that result.
An agent framework can stop before a payment tool runs. It still needs a trustworthy answer to a different question: what did the provider earn? In the LangGraph and Spoolis example, the graph gets that answer from a signed Outcome Receipt, then applies its own policy before resuming its payment step.
The distinction matters. LangGraph gates its own payment step. Spoolis does not pause the graph, authorize payment, or move money. Spoolis compiles the agreed criteria, verifies the submitted evidence, calculates earned value, and signs the result.
The loop in one line. The graph requests verification, reads receipt.amounts.earned, checks the receipt under buyer policy, then resumes its own payment step with that amount.
Why an interrupt is not a verdict
LangGraph's interrupt() gives a graph a clean place to stop before a consequential tool call. It does not decide whether the work passed or how much was earned. A human can make that decision for an exception. Requiring a person for every routine agent purchase defeats the point of an automated workflow.
The example separates those jobs. A verification node sends the agreement and evidence through Spoolis. A later payment-gate node interrupts with the receipt ID, result, and earned amount. The runner checks its policy and sends a resume command bound to that receipt. Only then can the graph reach its payment tool.
The worked example
The public example uses the account-free Spoolis sandbox to model a $10.00 task: 10 records at $1.00 each. Ten records arrive. Eight contain both required fields, while two omit status. Deterministic checks accept eight records, reject two, and produce a signed sandbox receipt with $8.00 earned.
The graph saves the receipt and carries receipt.amounts.earned forward. The payment tool receives that decimal amount as its input. In this example the tool is deliberately a stub. It prints what it would pay, so no real money moves.
You can inspect the code, notebook, and independent receipt verifier in the public repository. To see the same sandbox mechanics in the browser, walk from compilation to a verified receipt.
Keep verification outside the interrupted node
LangGraph restarts an interrupted node from the beginning when the graph resumes. The example therefore keeps the Spoolis network call in the preceding verification node and puts interrupt() in a separate payment-gate node. Resuming the graph does not rerun verification.
The example also uses a checkpointer and a stable thread ID. The runner resumes the same thread and binds the resume value to the saved receipt ID. Those details are framework mechanics, but they protect an important boundary: the value approved by buyer policy is tied to the receipt the graph actually received.
What the signature proves
The repository includes a separate Node.js verifier that checks the receipt against Spoolis's published trust set. A valid Ed25519 signature proves that the receipt came from a trusted published key and was not altered.
It does not prove that the underlying evidence was true. It does not authorize payment. It does not establish that settlement happened. Those decisions remain with the buyer's application, payment authority, and rail. The Outcome Receipt specification defines these boundaries in detail.
What changes in production
This worked example is a sandbox integration, not a production payment system. The sandbox moves no real money. Its in-memory LangGraph checkpointer is suitable for a short example, not durable production state.
A production buyer would verify receipt authenticity before a consequential action and define explicit rules for identity, replay protection, amount limits, authorization scope, and settlement. It would also choose how to handle a partial result. Spoolis's built-in settlement flow does not automatically settle one, while an external runtime may choose to act on receipt.amounts.earned under its own authorization policy.
The verification boundary is also intentionally plain about current capability. Deterministic checks and human-confirmed checks are live. AI-assisted verification is planned and is not live.
The reusable pattern
LangGraph is the worked example, but the pattern belongs to any agent runtime that can separate verification from a consequential tool call:
- Fix the criteria and evidence requirements before evaluating the work.
- Ask Spoolis to verify the evidence and sign the resulting earned value.
- Verify the receipt's authenticity and apply the buyer's own policy.
- Let the runtime resume its payment step with
receipt.amounts.earnedas the input.
That puts a verified outcome in the loop without confusing the referee with the bank. Spoolis remains non-custodial. The runtime decides whether its workflow continues, the payment authority decides whether spending is allowed, and the rail handles money movement.