Models can invoke tools.
MCP defines how models discover and call tools that interact with external systems. Those interfaces make execution available to more kinds of software.
MCP tool specificationOur vision Payments first. A bigger horizon.
The control layer
for an
autonomous world.
Intelligence gives software more ways to act. Authority must hold through every change.
HALTSEAL starts with one concrete consequence: an authorized payment must not become two. Our ambition is to make that continuity a foundation for consequential machine actions.
The architecture we are working toward
Many ways to act.
One authority.
Before the effect.
Exact action.
Current authority.
Shared capacity.
The executor can change.
The authority cannot multiply.
01 / The technical frontier
A valid tool call can still
create an invalid effect.
Two agents can each have valid credentials. Two payment instructions can each pass an approval process. If both spend the same right to pay, the organization can still pay twice.
Our control model follows the underlying obligation across changes in actor, request, provider, account and rail. Completed payments and unresolved attempts draw on the same authorized capacity. A new execution path cannot create more of it.
That is the frontier we are pursuing: continuity of authority at the moment software creates an effect. The release decision is deterministic. No generative model decides ACCEPT, HOLD or REFUSE.
Read the public control modelThe local question
Can this actor use this tool?
The shared question
Can this exact action still use the organization’s authority?
Scott Lee develops this question in ACM Queue. Publication explains the idea; product evidence is recorded separately.
02 / Why now
Software is moving
from answers to actions.
Agents can initiate commerce.
OpenAI and Stripe introduced the Agentic Commerce Protocol for agent-assisted purchases, while merchants retain their payment systems.
OpenAI’s ACP announcement · 2025The same obligation can reach another path.
An API retry, a bank portal or a recovery worker can act on the same payment. Each path needs to preserve the original limit.
Our illustrative payment workflowOur thesis: as execution choices multiply, preserving authority across them becomes an infrastructure problem.
03 / A precise starting point
Start with the
second payment.
A payment outcome is unclear. The supplier still needs to be paid. Another bank or provider is available. The original might still settle.
That decision already belongs to AP, Controller, Treasury and Payments teams. It gives us a concrete place to establish the control, the evidence and the person accountable for the next step.
Start with a free company Workspace Sandbox and one supported workflow. Use the separate SDK fixture to understand the API contract. Shadow has no payment authority; live enforcement requires technical qualification and operating approval. Optional assistance is separately scoped.
Explore the Payment APIProvider idempotency is useful for retrying a protected request. Our question concerns one obligation across independent execution paths. Stripe’s idempotency scope · Where a shared control fits
04 / From one workflow to enterprise control
One workflow is the entry.
Shared control is the opportunity.
Our strategy is to turn a specific payment problem into a repeatable enterprise control product.
- 01 / Establish the need
Review one workflow.
Identify whether existing controls hold, a gap needs repair or more evidence is required. Keep controls that already work.
- 02 / Prove the boundary
Validate connected paths.
Establish provider outcomes, release coverage and safe recovery in the customer’s accepted test environment. Evaluate Shadow before separately qualified enforcement.
- 03 / Make it repeatable
Expand a proven control.
Extend to additional obligations, paths and teams only after their conditions are verified. Build reusable integrations and a recurring software offering.
Why the opportunity can compound
The same enterprise can have many payment workflows and independently controlled paths. A validated shared boundary could serve more of them while the enterprise keeps its banks, ERP and agents. Our strategy is to turn that expanding coverage into recurring software.
The critical test is the next integration: can another path reuse the same core control, with provider-specific evidence and adapters? Each qualified integration should extend coverage without rebuilding the product for every customer.
05 / The work behind trusted control
Trust is earned
at the boundary.
- Provider outcome semantics
- Know what proves that the exact original paid, or can no longer pay. A status label alone is insufficient.
- Continuity through recovery
- Preserve the same limit through retries, competing workers and qualified recovery. A restart must not create fresh authority.
- Coverage that operators can inspect
- Connect every agreed release path and expose exclusions. An unconnected manual portal remains a bypass.
- Evidence that survives scrutiny
- Bind the decision to the exact action, current authority and prior outcome. Give operators a record they can examine.
Our ambition is a neutral control layer whose value comes from verified integrations, recovery discipline and evidence operators can inspect. It should remain useful as models, tools and providers change.
06 / The larger horizon
Payments are the first proof.
Authority is the larger problem.
Every consequential action must stay within its authorized scope.
Changing the agent, tool, provider or route must not create more authority.
Payments are where we prove that principle first.
Starting domain
Payment release
Preserve one authorized right to pay across connected replacement and recovery paths.
Current scoped Sandbox evaluationPossible expansion
Enterprise-wide control
Carry the same payment limits across more verified workflows, teams and execution paths.
Future directionLong-term ambition
Consequential actions
Apply the continuity principle wherever software changes a system and an organization bears the consequence.
Research horizon07 / Ambition with evidence
The next proof
must leave the lab.
What the evidence shows today
Actual Increase Sandbox. One installed reference uses fictional own-account USD 10, one Linux host and two paths both using Increase. It records original recovery, replacement HOLD and fresh release checks. HALTSEAL controlled the test companies.
Controlled BILL and Agent profiles. Separate tests preserve the original through Agent handoff, lost replies, restart and current installation checks. One installed BILL payment owner also survives a reviewed v1-to-v2 executor change. Its original approval, UNKNOWN reservations and PAID consumption stay intact. Provider effects and signing custody are controlled. One controlled HTTP record also retains an unresolved journal-repair finding after a provider CREATE.
Learning and client fixtures. Browser examples, SDK recovery exercises and the diagnostic Lab remain synthetic. Their amounts, sources and test counts are separate from the installed records.
Inspect current Agent recordsReview controlled profiles and limitsRequest the exact supporting recordWhat we must prove next
- 01
A buyer-hosted workflow
Test the buyer’s existing controls and agreed payment paths.
- 02
The customer’s exact provider paths
Qualify source authority, provider finality, deployed credentials and retained-original recovery in the intended environment.
- 03
Repeatable paid deployments
Establish customer value, accepted operations and reproducible delivery.
Evidence boundary. Actual Increase Sandbox calls, controlled BILL profiles and synthetic fixtures establish different things. The finite executor test does not qualify arbitrary upgrades, legacy-profile migration or host loss. Native BILL execution remains NOT_QUALIFIED; external customer acceptance remains NOT_PERFORMED; real-money Production remains NO_GO. These records establish no availability percentage, recurring revenue or commercial demand. Other action domains need their own rules, integrations and proof.
Start with your workflow
More autonomy.
One authority.
Have a payment workflow where the original outcome can become unclear?