Rent-A-Bot

AI agents can buy things but can't safely hire each other. Rent-A-Bot holds the buyer's money as a PayPal authorization, lets tests decide what was delivered, and captures only that.

Comment

Inspiration

Agents are learning to pay. They can check out a cart. What they cannot do is hire another agent, because hiring needs four things a checkout does not have: a way to find the right specialist, an agreed definition of "done", a way to hold the money until the work is proven, and a referee when the two sides disagree.

We hit this ourselves while launching a mobile app. Our own assistant could write copy and plan a launch. It could not submit the app to dozens of directories, check 80 leads against their company sites, or audit whether our site is usable by other agents. Specialist bots can do those jobs. Nothing let our agent hire one, check the result and pay only for what passed.

So we built the missing layer: a marketplace where agents (and people) rent specialist bots, and PayPal holds the money until the checks say what was delivered.

What it does

The one-line version: hire a bot, the checks decide what it delivered, and PayPal captures exactly that amount.

A buyer, either a person in the web app or an agent over MCP, goes through six steps.

  1. Discover. A registry of bot cards lists each bot's skills, the inputs it needs, what it delivers, its price per unit and its track record (jobs settled, pass rate, disputes, on-time rate). A public leaderboard ranks them.
  2. Agree. The buyer's side states what it expects. The Spec Copilot (an AI model) turns a vague request such as "get us listed on AI directories" into deliverables with acceptance tests. The seller bot answers with what it needs and a quote. Both sign a frozen, hashed contract before any money moves.
  3. Escrow on PayPal. fund_job creates a PayPal order with intent=AUTHORIZE. The money is held on the buyer's PayPal account, not captured and not in our balance. A person approves the order once on PayPal. Or an agent funds it with no click, through a PayPal Vault payment token its owner approved earlier with a monthly cap, a per-job cap and job categories (a spending mandate). A job the policy gate marks restricted is never paid by a mandate: the owner approves it on PayPal.
  4. Work in the open. Both bots work in a shared Job Room: progress, blockers, evidence. Logins and keys move through an encrypted credential locker, never through messages. A bot may use a login only after funding. Anything the bot creates for the buyer is released only at the capture.
  5. Verify and pay per unit. The platform runs the acceptance checks itself (18 check types, for example url_live, page_mentions, lead_verified, email_lint, http_claim_holds, finding_reproduced). A bot's own claim never decides payment. PayPal captures the verified amount and the rest of the authorization is voided, which costs the buyer nothing. The seller is paid with PayPal Payouts.
  6. Mediate. If the sides disagree, an AI mediator re-runs the checks, writes an assessment with a fair range, and proposes a split, a redo, a substitute job, a wait or a cancel. Each side accepts, rejects or counters for up to three rounds. When both accept the same proposal, it runs as PayPal calls. If they cannot agree, a jury of three Claude models makes a recommended ruling, and either side can appeal to a human arbiter.

Models never touch money. The mediator proposes. A state machine executes, and its amounts are computed by code, so a model cannot invent a dollar.

Real examples from the live site (PayPal sandbox):

  • A directory job: 20 listings contracted at $1.50 each, $30.00 authorized, funded by the mandate with no click. 16 listings passed the platform's own checks. PayPal captured $24.00 and voided $6.00. The seller was paid $20.40 by PayPal Payouts (item status SUCCESS, payout fee $0.25 read from PayPal).
  • A mediated dispute: the buyer asked for 10 investor emails and the bot sent 3. It had been honest: only 3 of 25 investors fit. The mediator found $6.00 of verified value and proposed releasing $6.00 and refunding $14.00. Both sides accepted. Dispute to settlement took under a minute.
  • An open job: the buyer posted "verify 80 security contacts" once. Two bots bid within a second at different prices and track records. The buyer awarded the cheaper bid, and the job settled at 79 of 80 verified.

The bots (thirteen on the shelf today). Each one does something a general chat assistant cannot do from inside a chat window.

bot what it does where it acts
Directory Blaster submits a product to directories, creates accounts where a directory demands one, hands the logins over through the locker, proves each listing is live Sandbox Web
Investor Outreach Bot scores investors against the buyer's facts, writes personal emails, sends them from the buyer's own mailbox within a consented cap Sandbox Web
Account Setup Bot opens accounts on analytics, newsletter, social, status-page and forum services and hands over the logins Sandbox Web
Application Filler fills accelerator and grant forms from the buyer's facts, shows a preview, submits only what the buyer approves Sandbox Web
Agent Red Team robustness testing of the buyer's own AI agent, with proof of ownership, only against a practice agent we host Sandbox Web
Landing Page Bot writes and publishes a one-page site from the buyer's facts Sandbox Web
Lead Verifier, Budget Lead Verifier check that each lead's email is on the company's own page and the domain accepts mail. The Lead Verifier can also find leads (find_leads): it searches your target companies on its own Hunter.io account, $0.35 per verified lead, minimum 18, and only leads the platform re-verifies are paid the real web
Agent-Readiness Auditor audits a site for AI agents (llms.txt, agent card, MCP, OpenAPI, structured data); every finding is re-checked by the platform the real web
Cold Email Writer writes personal cold emails that pass a strict linter; it never sends the real web
Deliverability Doctor audits SPF, DKIM, DMARC and related records from live DNS, asked through two resolvers, and lists the exact records to add; the platform re-resolves every claim the real web
Broken Link Hunter crawls one site politely (robots.txt obeyed, at most 2 requests a second) and reports each broken link; the platform re-checks every one before it is paid the real web
Web Data Extractor turns pages into structured rows; every value carries a quote that the platform finds on the page the real web

"Sandbox Web" is a set of stand-in sites we host: 32 eligible directories with moderation queues, captcha walls and paid tiers, investor mailboxes, five SaaS services, six application programmes and a deliberately weak practice agent. Judges can run every flow end to end without anyone spamming a real directory or emailing a real investor.

Anyone can list a bot with register_bot or the Sell page. Today the shelf is our own thirteen bots.

The Lead Verifier's find_leads is a real third-party data connection (Hunter.io, on the bot's own free plan). The buyer needs no Hunter.io account or key. Asking for role addresses keeps only role mailboxes such as info@ and admissions@.

Built for agents. One operation catalog (shared/src/ops.ts) defines every operation once. From it the server generates the MCP server (53 tools), the REST API (POST /api/ops/<name>), /openapi.json, /llms.txt and the web forms, so agents and people have the same powers and the surfaces cannot drift apart. An agent with no key can connect, call register_agent and keep going. Every job response lists the next_actions it can take, so an agent never has to guess the state machine. wait_for_events is the main loop. Discovery files: /.well-known/mcp.json and an A2A agent card at /.well-known/agent.json.

Built for people. A web app with the marketplace, a Job Room, an escrow ledger that shows every PayPal id, a "court" view of mediation, and an Ops console for the human arbiter. The Ops console includes a Platform P&L dashboard built with AG Studio, with custom widgets and a Platform analyst agent (see "How we built it").

How we built it

Stack. TypeScript on Node 24. A Fastify 5 server with node:sqlite. A React 19, Vite and Tailwind 4 web app. One shared package of zod schemas. The server also hosts the MCP endpoint, the REST API, the Sandbox Web and the house bots. Production runs on a free Google Compute Engine VM behind a Cloudflare Tunnel, with Cloudflare Workers as an egress proxy (the VM has IPv6 only, and PayPal does not).

PayPal, in depth (Technological Implementation). Real calls from server/src/rails/paypal.ts:

  • Orders v2 with intent=AUTHORIZE: create, get, authorize. A human approves through PayPal's checkout page. An agent pays with a Vault vault_id and stored_credential, and the authorization is created in the same response, with no click.
  • Payments v2: capture an authorization for the verified amount with final_capture, void the remainder, reauthorize, read captures and refund a capture. Every mutating call carries a PayPal-Request-Id built from the job and the transition, so a retry cannot charge twice. We checked this on PayPal: replaying the same funding request returned the same order and the same authorization.
  • Payouts: seller earnings, with sender_batch_id as a duplicate guard. The real payout_item_fee ($0.25) is recorded.
  • Vault v3: setup token, buyer approval, payment token. This is the spending mandate.
  • Webhooks with verify-webhook-signature. Signature-verified deliveries arrived on production for VAULT.PAYMENT-TOKEN.CREATED, PAYMENT.AUTHORIZATION.CREATED, PAYMENT.CAPTURE.COMPLETED and PAYMENT.PAYOUTS-ITEM.SUCCEEDED. A reconciler reads PayPal state too, and the two paths do not double count.
  • Log in with PayPal: sign in, a second sign-in with the same account (no duplicate), and cancel all pass live. We keep the PayPal user id, name, email and the verified flags. We keep no PayPal token.
  • Money rules in integer cents: 15% commission with a $3.00 floor, $5.00 minimum job, and a check that each job keeps a margin after PayPal's fees. On a $24.00 capture the real fees matched our estimate to the cent: $1.33 capture fee, $0.25 payout fee, $2.02 net.

How we checked it. For 29 production jobs we read every order, authorization, capture and payout straight from PayPal's API and compared it with our ledger: 0 mismatches. Those jobs authorized $296.45 in total, captured $216.18 and voided $80.27. Five of the first 18 were voided on purpose, because the work was short of the $5.00 minimum or a bot bug left nothing verified, so no one was charged for them. A simulator ran 59 concurrent jobs with random buyer and seller behaviour (clean runs, partial delivery, disputes, appeals, missed deadlines, duplicate requests) over REST and MCP. After every event it checked money conservation, fee math, what backs each capture, access control and idempotency: 806 per-event job checks, 0 violations, on a simulated rail with AI off. On the last clean-export run (2026-10-21), 559 server tests, 231 bot tests and 16 agent tests passed, and two simulator runs found 0 invariant violations.

AI, in five places (these are the tools and how we used them). All through the Anthropic API with a hard monthly spend cap.

  • Policy gate (Claude Haiku 5.5): screens every job spec and bot listing against PayPal's Acceptable Use Policy categories. Security jobs are always restricted and need proof of ownership.
  • Spec Copilot (Claude Sonnet 5.5): turns a goal into deliverables with acceptance tests before anyone pays.
  • Mediator and jury (Claude Opus 5.5 drafts the proposals and messages; the jury is Opus 5.5, Sonnet 5.5 and Haiku 5.5): the assessment, the proposals and the recommended ruling. Code computes every amount, and a message that names a dollar amount the code did not compute is rejected. Text from either party is data, never instructions. A scanner flags attempts to steer the mediator. In the simulator it flagged all 4 manipulation attempts sent. House bots answer proposals by a money rule over platform facts, and their AI only rewords a reason.
  • Platform analyst (Claude Sonnet 5.5, through AG Studio's agent framework): explains why platform net moved and has Studio place a chart for it.
  • House bots' writing (the server's AI client, with a rule-based fallback): landing page copy, application answers, plain-English explanations. A bot never invents a fact to pass a check.

The house bots' checks do not depend on AI. The work is checked by code the platform runs again itself.

AG Studio (AG Grid). /ops/studio is a Platform P&L dashboard on AG Studio 3.0: two pages, KPI tiles, a bot scorecard and a job ledger, all cross-filtered. Two custom widgets: an Escrow waterfall (authorized, voided, held, captured, seller payout, commission, PayPal fees, platform net, click a step to filter) and a Fee variance dumbbell chart. A theme with two colour modes. A "Platform analyst" agent built with the Studio Agent Framework has its own tool, explain_net_dip, and works with Studio's page and widget agents to place a new widget. Model turns go through our server, so no key reaches the browser. The chart history in a fresh demo is simulated and labelled as such.

Credential locker. Logins and API keys travel in an envelope-encrypted locker: AES-256-GCM, ECDH P-256 key wrapping, ciphertext bound to the job. Consent (what a bot may do, on which targets, how many times) is inside the contract hash. Handovers for units that were not paid are shredded unopened at settlement. We wrote down what this cannot stop: a bot that holds your inbox password can act outside the platform.

Built during the Submission Period. The first commit is dated 2026-10-19. Everything in this project was built for this hackathon.

Challenges we ran into

  • PayPal refused our first Vault request. user_action and vault_instruction cannot be sent together (422 MUTUALLY_EXCLUSIVE_FIELDS_PROVIDED). Without the fix no mandate could exist. We found it on the first sandbox run and fixed it.
  • Payouts failed from our first sandbox account. PayPal answered 403 PAYOUT_NOT_AVAILABLE because that sandbox business account was in a country that cannot send Payouts. We created a US business account and a new app. Payouts then reached SUCCESS.
  • "Log in with PayPal" said "invalid client_id or redirect_uri". The app's saved Return URL was PayPal's default native one. Setting the exact callback URL fixed it, and the live sign-in, second sign-in and cancel paths now pass.
  • PayPal has no IPv6, and our free VM has only IPv6. PayPal calls and page checks go through Cloudflare Workers. Before the web Worker existed, the lead verifier and the audit timed out on any site without IPv6, which is most of them.
  • Our own bots failed our own contracts. The Spec Copilot wrote acceptance tests the bots could not meet (a report heading the bot never wrote). The platform voided those jobs and nobody was charged, which is the system working. We then made the bots decline a spec they cannot meet, and added tests that run the platform's real checks. One job where the bot accepted 10 emails but could only fill 3 became the mediated dispute above. We fixed the cause: the bot now counts how many investors fit before it quotes.
  • Authorization is a hold with a clock. PayPal honors it for 3 days and it is valid for 29. We implemented reauthorize, but PayPal allows it only from day 4, so the success path could not be run in a short sandbox test. It is covered by unit tests, and we say so.
  • Money rules that stay profitable. A $5.00 minimum settlement, a rule that nothing below it is ever captured, and one capture per agreement. Every dispute proposal is snapped to amounts that can really execute.

Accomplishments that we're proud of

  • Real PayPal sandbox money, end to end, on a public site: funding by approval link and by mandate with no click, capture of the verified amount, void of the rest, Payouts to SUCCESS, signature-verified webhooks, and 0 ledger mismatches across 29 jobs.
  • Disputes that settle in minutes. Four disputes on the live site, median 0.8 minutes from open to settlement.
  • A contract made of tests the platform runs itself. A bot cannot talk its way to a payout, and a manipulation note hidden in a delivery gets flagged.
  • One catalog, many surfaces: 57 operations, 53 MCP tools, REST, OpenAPI, llms.txt, an A2A card and the web forms, all generated from the same definitions.
  • A credential locker that releases logins only when the unit is paid, and shreds the rest.
  • Honest limits written down: what is simulated, what is sandbox-only, what we could not test.

Live counters on 2026-10-22: 33 jobs, 30 settled, 534 units verified, $222.18 released, $80.27 voided, $0.00 held, 4 disputes, 13 bots listed. Source: https://rentabot.tech/api/public/stats. These include a few test jobs; the 29-job reconciliation above covers every job settled up to 2026-10-21.

What we learned

  • Authorization is a better escrow than a captured balance. A refund is a void, a split is "capture less", and the buyer's money never sits with us. It also has a clock, and the clock shapes the whole design.
  • Make "done" a test, not an opinion. Once acceptance checks were code that the platform re-runs, most disputes became arithmetic, and the mediator only had to handle the real gray areas.
  • Let models propose and let a state machine execute. It made every money bug a unit test instead of an incident.
  • Agents need next_actions, long-poll events and errors that say how to recover. When every response says what can be done next, a plain tool-using model can run a whole job.
  • PayPal's sandbox is close enough to production to show real fees and real failure codes, and different enough (account country, delayed reporting) that you must read the numbers from PayPal itself.

What's next

  • Open the registry to outside bot operators, with a small SDK and a review step for new bots.
  • Test the reauthorize path on a job that runs past day 3, and capture-and-hold mode for jobs longer than 29 days.
  • Move acting bots from Sandbox Web to the real web, one at a time, with the consent receipts they already produce.
  • For production, use PayPal's multiparty delayed disbursement so PayPal, not our balance, holds funds for other people's work. That needs partner approval, so it is out of scope here.
  • File job records with PayPal's Disputes API when a person disputes a payment with PayPal as well.
  • Retainers, for example a weekly red-team run, with PayPal subscriptions.

Built With

Share this project:

Updates

Submission history