Spoolis

Essay

Two services. No accounts. One signed Outcome.

I wanted to see how far a useful agent workflow could get with no signup, no API keys, and no human checkout anywhere in the loop.

Jared FranklinAugust 2026

Yesterday I ran a small experiment with two services that don't know who I am.

No accounts. No API keys. No OAuth. I gave one service a job, handed its output to another, and ended with a signed result anyone can verify.

The first was Firecrawl. Its keyless endpoints will search the web and extract structured JSON from a page for anyone, rate-capped. The second was the Spoolis sandbox, which will verify a delivered dataset against explicit acceptance criteria for anyone, also keyless, also rate-capped.

So I wired them together in one script. No credentials anywhere:

  1. Search for pages that list B2B SaaS companies.
  2. Scrape a page and extract a structured list: company name, website URL, pricing URL, using a JSON schema.
  3. Treat that extraction as delivered work: "20 company records, each complete, no duplicate websites, well-formed pricing URLs, 25 cents per accepted record."
  4. Submit the rows to the Spoolis sandbox as evidence and let the deterministic checkers decide what counted.

The result: 20 of 20 records accepted, $5.00 of $5.00 earned, four conditions passed (row count, completeness, duplicate rate, URL format), and a signed Outcome Receipt hosted at a public URL. Anyone with the link can check the verdict and verify the signature themselves. They don't have to trust me, Firecrawl, or the script.

The interesting part wasn't the scrape

It's that the acceptance record exists at all.

A lot of agent tooling still assumes an account exists before anything useful can happen. For tiny, one-off machine transactions, that feels backwards. An agent that needs 20 verified records shouldn't need a signup flow on either side of the job.

What the composition actually produced:

  • The agreement was pinned before the evidence arrived: what a record is, what disqualifies one, what each is worth.
  • The receipt preserves what was checked, which verifier made each call, where the evidence came from, and when it was observed.
  • Partial would have been payable. If 3 records had duplicate domains, the receipt would say 17 accepted, $4.25 earned, and why.

What actually broke first

This took three attempts, and both failures are instructive:

  • I lost some time because Firecrawl's v1 and v2 scrape routes expect different shapes. The docs were close enough that I assumed they behaved the same. They didn't. The v1 endpoint quietly returns nothing useful for a v2-style JSON-format request.
  • My first extraction schema asked each page for a single company. A listicle can't answer that, so extraction returned nothing. Asking the page for a list of companies, with a prompt, fixed it in one try.

Neither failure reached the verification side. Pinning the acceptance criteria first doesn't make the gatherer trustworthy. But it does mean the downstream system has something explicit to test instead of simply trusting "done."

What this does not prove

  • No money moved. The $5.00 is computed earned value on an external settlement, not a payment.
  • Firecrawl is a public API we used anonymously. This is not a partnership, endorsement, or adoption in either direction.
  • One walk proves the composition works, not that anyone wants it.

What I like about this pattern is how little either service has to know about the other.

Firecrawl produced the work. Spoolis judged it against an explicit agreement. The signed Outcome is what survives.

No shared account system. No custom integration. No human checkout.

That feels like a pretty useful shape for software buying work from software.

Notes

Related reading: pay per verified unit · the workflow doesn't continue · authorization is not earned value

Two services. No accounts. One signed Outcome. · Spoolis