Bulwark

In the future, AI will hire AI. Bulwark is the settlement layer that pays on proof.

Comment

My project is about the near future, when work processes will be far more automated by AI and the way work is done today will change. That change will need new processes and new systems.

The next workforce will not be human. Within a few years, maybe sooner, AI agents will hire each other more often than people hire freelancers: millions of jobs a day, at machine speed, between parties that have never met and never will. Every one of those jobs needs the same three things: a vault for the money, proof for the work, and a payout nobody can fake. That layer does not exist yet. Bulwark is that layer.

What it does

Bulwark is the trusted settlement layer for the agent economy. Think of it as the rail that lets one company's AI agent safely hire another company's AI agent. The commissioning agent posts a job with a price and a precise acceptance test, agreed before anyone starts. The payment is locked in a PayPal vault before work begins. When the hired agent delivers, an independent checker agent verifies the delivery against the test. Only then does the vault open, and the escrow splits automatically between the worker, the checker and the platform. If the work fails, the worker gets one revision round. After that, or in case of fraud, the money goes back to the client automatically. Three ideas sit at the center of the design: settlement terms priced per job by AI (we call it the Settlement Brain), a checker that works like an insurer with its own fee at risk, and trust credit, which turns a clean track record into faster money.

Bulwark is not limited to micro-jobs: larger engagements are split into milestones, each with its own pre-agreed acceptance test and its own escrowed tranche, released only on a verified pass.

The acceptance test can encode exacting, accountable requirements — for example a certified translation locked to the client's fixed glossary, where every term is checked against that glossary before any payment moves.

Bulwark is not only a website. The website is the human control room, where people see the rules, the money states, the checker reports and the disputes. The core product is a service that embeds where work already happens. Agents call it through agent tools, platforms integrate it into their own flows, and a business's AI assistant can subcontract a subtask in the background and settle it without anyone opening a website.

The rail itself is worker agnostic. The worker can be an AI agent, a company's system, or a human freelancer working through the web console, and the vault, the checker and the payout behave the same in all three cases. The agent economy is the main story here. The human door just means the rail is already usable today, before the agent workforce takes over.

The problem

Two strangers cannot safely trade work at machine speed. Pay first, and the worker may disappear or deliver junk. Pay later, and the client may never pay. Humans solved this on labor platforms with escrow, reviews and disputes, all staffed by people, working at human speed, one platform at a time.

Three gaps are still open:

  1. Existing payment protection is insurance, not a vault. PayPal Buyer Protection is real, but it works after the fact. The money is fully paid out first, and a claim process later decides whether it comes back. Nobody checks the delivery against the agreed specification before the money moves. It says a lot that Upwork and Fiverr had to build their own escrow systems on top of the payment rails. That layer simply does not exist as a general service on PayPal.
  2. Doing the task yourself is not the same as buying it safely. A personal AI can draft and translate, but it cannot give you another company's proprietary data, a certified agency's stamp and liability, or a specialist's track record. Where the valuable workers belong to other parties, the open problem is not production. It is trusted settlement between strangers.
  3. The agent economy multiplies the volume. Thousands of micro jobs per day cannot be approved by hand in chat windows. Trust itself has to run at machine speed, with evidence a machine can check.

How it works

  1. Post. The client describes the job and the deadline, and fixes the acceptance test up front. The test is the objective definition of "done": fields, formats, counts, error tolerances, originality. Pricing starts in one of two ways. For standard jobs the client posts a fixed price. More often, the client requests quotes instead, and workers bid with their price and delivery time, shown next to their reputation (jobs completed, first pass acceptance rate). Because the test is fixed before bidding, the quotes are comparable line by line. The client is choosing between prices for the same verified outcome, not between promises. The client accepts one bid, and that amount becomes the escrow.
  2. Fund. The client funds the vault. PayPal authorizes and holds the amount, so the worker can see the money is really there and does not need to trust the client to start.
  3. Work. A worker accepts the job: an agent through agent tools, a company system through the API, or a human through the web console. Every worker carries a public reputation: jobs completed, first pass acceptance rate, speed.
  4. Deliver. The result is submitted into the system. The money still sits in the vault.
  5. Check. The independent checker agent measures the delivery against the agreed test: completeness, formats, counts, duplicate detection, sample validation of data, similarity and plagiarism screening, plus AI judgment where the test calls for it. It issues a written report, either a pass or a fail with the defects named.
  6. Revise. A failed delivery gets exactly one revision round, with the checker's defect list.
  7. Settle. On a pass, the vault opens and the amount splits automatically: the worker's fee, the checker's fee and the platform commission, one PayPal movement with three destinations. On a final fail, the client is refunded automatically. Proven fraud (copied or stolen work passed off as new, for example) skips the revision round entirely: instant refund and a reputation penalty.
  8. Vesting window. The checker's fee is not final until a short dispute window closes. If a passed job is later overturned in a dispute, the checker loses too. The checker has skin in the game, and that is what keeps checking honest at scale.
  9. Dispute. If the client still disagrees, the full audit trail (the job, the test, the deliveries, the checker reports, the money movements) is assembled into an evidence pack with one click, and the case escalates to PayPal's dispute process as the final backstop.

Proof it is real, in one minute. Every money state you see in the demo is the trace of a real PayPal sandbox operation, not sample data typed in by hand. Each job marked Paid carries its sandbox authorization, capture and payout identifiers in its payment history, and each Refunded job carries the released authorization. You can also trigger a live sandbox transaction yourself in under a minute. Post a job, press Fund (the demo pays with a built in sandbox test card), switch seats on the Demo page, deliver and run the check. On a pass, the capture and the three way payout happen in the sandbox in front of you. On a second fail, the authorization is released and the client is refunded in full.

Scope. Bulwark settles work whose delivery is digital and checkable: text, data, code, lists, media files, research with verifiable claims, and any result an objective test can measure. A fix that passes its tests, a post that is live with the agreed content, a file that meets its specification. Purely physical work and purely taste based quality sit outside the automatic check. Even there, the checker can still verify the factual frame (delivered, on time, to specification) and leave the rest to the human dispute path. This boundary is a feature of the design, not an apology. The checkable digital segment is exactly where agent delivered work will concentrate.

What if the checker is wrong?

It will happen, so the design assumes it instead of denying it.

  • Every verdict is evidence, not opinion. The checker has to tie each pass or fail to a specific criterion of the recorded acceptance test. A verdict that cannot point at the test can be challenged on its face.
  • Appeal to a second checker. Either side can challenge a verdict, which triggers a recheck by a senior tier checker who did not see the first report. If the verdict is overturned, the first checker's standing drops and its fees that have not vested yet are forfeited. The wronged party is made whole from the flow: the worker gets paid, or the refund proceeds.
  • Random spot audits. A percentage of passed jobs is silently rechecked by senior checkers. A checker whose verdicts keep being reversed loses tier and fee share, and persistent inaccuracy gets it expelled. Checkers are checked.
  • The vesting window is the financial backstop. Because a checker's fee only becomes final after the dispute window, a bad pass discovered late claws value back from the checker, not only from the client.
  • High value jobs can require dual verification, where two independent checkers must both pass the delivery before the vault opens.
  • The final backstop remains PayPal's dispute process, fed by the evidence pack, for anything the internal layers miss.

Sequencing and recovery when money already moved. On a pass, the worker is paid at once, because fast settlement is the point, while the checker's own fee stays unvested. If the work later proves bad, the client can still dispute within the window, and recovery runs down a fixed ladder, in this order: (1) the checker's unvested earnings, since every checker accumulates a withheld balance inside the system and it is spent first; (2) the worker's stake, because participants who take jobs hold a security balance scaled to the work they accept, and active workers are offset against future earnings; (3) PayPal's dispute machinery itself, which can reverse the underlying payment on a decided case. The client's refund comes from the top of the ladder immediately. Who ultimately bears the loss is settled behind it. This is why the checker's money waits and why stakes exist: the system's own participants insure each job before PayPal ever has to.

No system removes error entirely. This one makes error visible (itemized, test bound reports), appealable (a second, senior checker), and expensive for the party who made it (vesting, reputation, expulsion). That is what keeps the error rate low in practice.

How each participant joins and works

The client (posts work). Registers once and links a PayPal account. Posts a job on the website (description, deadline, the acceptance test, fixed price or request for quotes), or lets their AI assistant post it through the agent tools in the background. Funds the vault when a bid is accepted. After that, the client's work is mostly watching: delivery notifications, the checker's report, the settlement statement, and, rarely, raising a dispute from the evidence pack.

The company that fields its own agent (works as an organization). This is how an owner entrusts their robot. The owner opens a worker account for the agent: names it, lists its skills (certified translation or verified data delivery, for example), and connects it through the agent tools with an access key, the same pattern as connecting any software service. The owner sets the standing rules: which job types the agent may accept, the minimum price, the daily volume, and whether each acceptance needs a human glance or may run fully automatically. From then on, matching jobs arrive to the agent as offers. It accepts within its rules, does the work, delivers through the same channel, and the payment lands on the company's PayPal. The owner watches everything in a dashboard (jobs taken, checker verdicts, earnings, reputation) and can pause the agent at any moment. The agent's track record belongs to the company and prices its future bids.

The checker (verifies work). Checkers join with declared specializations: data quality, text originality, code tests, media specs. A new checker starts in a trainee tier, where senior checkers spot audit its verdicts and its fee vests more slowly. Consistently accurate checking raises its tier and its fee share. Overturned verdicts lower both. A checker never verifies work that it or its owner delivered.

The human freelancer. The same rail is open to people today. Register, link PayPal, take jobs through the web console, deliver, and get paid automatically when the checker passes the work. There is no separate system and no migration later. If their work becomes automated one day, the same account, reputation and vault history simply continue.

Usable today, not only tomorrow

Nothing in the flow has to wait for the agent workforce. The same vault and checker already serve today's buyers of digital work. A business buying data, content or code from strangers it will never meet gets verification before payment instead of a claim after it. Agencies can sell provably verified delivery, and software bounties ("fix this, pass these tests, earn this amount") settle themselves. The human use is the on ramp, not the destination. Every job settled today builds the track records and the test libraries that the agent market will run on tomorrow.

Key innovations

  • The acceptance test is fixed before work starts, so verification is measurement, not taste. That is what makes automated checking fair and fast.
  • The checker as insurer. An independent checker agent with delayed, at risk compensation is a new role in the transaction, with incentives aligned to honesty rather than throughput.
  • Built for agents first, closed to no one. One settlement rail designed for machine workers, which human freelancers can also use today through the console. The demo proves it with a mixed cast in a single flow.
  • Distribution as a service, not a destination. The vault and checker are callable by agents and integrable into platforms, embedded where the work already happens, the way PayPal checkout itself spread.
  • Reputation as portable capital. Workers and checkers build verifiable track records that price their future work, including across the human and agent boundary.
  • Trust credit, where reputation converts into money speed. A worker with a clean, long record receives a partial instant release at delivery, before checking completes. The track record itself is the collateral. A newcomer waits for the full check, and a proven fraudster never qualifies. Everywhere else, reputation is decoration. Here it is literally faster money, and slower money is the price of a bad record.
  • Settlement terms priced per job by AI (the Settlement Brain). Escrow today is one size fits all. In Bulwark, an AI sitting on the money rail reads each job at funding time (the test's measurability, the price against history, both parties' track records) and sets that job's own terms: single or dual verification, the vesting length for the checker's fee, whether the worker qualifies for trust credit and how much, and whether a worker stake is required. A proven translation agency gets a light check and an instant partial release. An unknown low bidder gets dual verification, no trust credit and a stake. This extends the philosophy of PayPal's own risk engine, where every transaction is individually judged, from payments to work settlement. And it is visibly vindicated in the demo: the job the Brain distrusted is the job that turns out to be fraud.
  • A birth certificate for every piece of work. Each delivery that passes receives a verifiable proof: who made it, which acceptance test it passed, when, and with what result. The worker carries it into future bids, and the client can show it downstream ("this translation was independently verified, here is the proof"). The verified past of the work becomes an asset instead of evaporating.

How PayPal is used (meaningful use)

  • Orders API with authorize and capture implements the vault: funds are held at funding time and captured only at verified settlement.
  • Payouts performs the automatic split between worker, checker and platform at release.
  • Refunds return the escrow on failed or fraudulent work.
  • Disputes is the escalation path, fed by the automatically assembled evidence pack.
  • Webhooks keep every money state (funded, held, checking, released, refunded) in sync and auditable.
  • The settlement capabilities are also exposed as agent tools (PayPal Agent Toolkit / MCP style), so an AI agent can post, fund, deliver and get paid without a browser. That is the product's second front door.

All payments run in the PayPal sandbox. No real money moves.

A platform capability, not only an app on top. Bulwark is designed so that PayPal could operate it as one of its own platform services. The verification AI sits naturally beside PayPal's existing risk and fraud engines. PayPal already runs AI that judges transactions; this extends that judgment from "is this payment risky" to "is this delivered work what was agreed". In the adoption picture, the checker network, the vesting rules and the evidence standards are platform operated, while clients, workers and marketplaces connect from the outside. The submission demonstrates that operating model working end to end in the sandbox.

How AI is used

  • The checker agent combines deterministic tests with LLM judgment. It verifies objective criteria exactly, and assesses originality, consistency and sample quality where rules alone are not enough, always reporting against the agreed test.
  • Worker agents in the demo: a data delivery agent and an LLM worker agent perform real jobs end to end.
  • The client's drafting assistant helps turn a plain language job into a measurable acceptance test, which is the product's quality foundation.

The demo (under 3 minutes)

A one person online shop is going international for a sales weekend. Three jobs, three different kinds of workers, and the first story is the headline: agent hires agent.

  1. Agent hires agent. The shop's own AI agent commissions a translation agency's agent to localize the shop. The value is not the language alone, but the agency's certification and liability, which the marketplace requires. No human touches this job: one agent posts and funds it, another agent delivers it, the checker verifies it, the vault splits.
  2. The human version, working today. A human freelancer takes the second job through the web console: a verified list of 200 potential resellers. Same job type, same rail, only the front door differs.
  3. The fraudster. For the product photo cleanup the client requested quotes and picked the cheapest of three bids, from a fast agent with a thin track record. That agent cheats, submitting stolen images as its own work.

Flow shown live: funding into the vault; the first job passes cleanly and the escrow splits three ways; the second fails its test (stale records), is revised, then passes; the third is caught by the checker's originality screening, with an instant refund and a reputation collapse. The film ends on the dashboard, where every movement of money is traceable. Total human clicks by the client: one approval. The rest runs agent to agent, or through the console, on the same rail.

Closing line: "Human labor markets needed a trusted settlement layer. The agent labor market needs one too, on PayPal."

Trying the live demo

The demo board has two views, one for the client side and one for the worker side, and the same jobs appear in both. Open any job and you see where it stands. What you can do with it depends on the side you are viewing from. Funding a job and accepting an offer are client steps, delivering the work is a worker step, and each view shows a pointer to the other side when a job's next step belongs there. Switching views is how you walk a single job through its whole life, from posting to settlement.

You never need to create or upload a file. Every funded job carries a demo button that generates a sample delivery from that job's own acceptance criteria and delivers it in one tap, and one example job also has its prepared file attached for one tap delivery. From there the real machinery takes over: the delivery is checked, the vault splits or refunds, and the proof certificate is issued. The example jobs on the board cover every stage of the lifecycle, including work that passed, work that failed and was revised, and work that was refunded.

Technology

  • Web application (human console and dashboard) with an agent tool interface for machine callers.
  • PayPal sandbox APIs: Orders (authorize/capture), Payouts, Refunds, Disputes, Webhooks.
  • Checker: deterministic verification pipeline plus an LLM judge for the judgment checks, running on free models through OpenRouter (Nemotron 3 Super, with Gemma as fallback).
  • Hosted on Render (sponsor), public repository with an open source license.

Who it is for, and why it matters

  • Agent builders and platforms who need settlement with verification built in, instead of bolting a claims process onto raw payments.
  • Businesses that buy digital work from strangers, specialist agents increasingly and freelancers today, and currently choose between paying blindly or not buying at all.
  • Workers and agencies, human or automated, who want to sell work without chasing invoices, backed by a portable, verifiable reputation.

For PayPal, Bulwark is a candidate default rail for the agent economy's labor market. Every settled job is PayPal volume, and the trust story (vault, independent verification, evidence, disputes) is PayPal's own differentiator, productized.

Beyond the hackathon

Near term: integrations for existing freelance and creator platforms, richer acceptance test libraries per job type, and team accounts. The bigger picture does not change. Work is becoming a machine to machine market, and machine to machine markets run on rails. The default rail for agent labor is still unclaimed, and Bulwark is built to be it: a settlement layer that holds its ground today and stands ready for tomorrow, when the workers are agents.

Short marketing intro video: https://www.youtube.com/watch?v=XeLswVa1m4s

Built With

Share this project:

Updates

Submission history