Resqueue

Demo

About

ResQueue is a human-in-the-loop safety net for autonomous robots. Today, warehouse, delivery, and industrial robots handle most tasks on their own, but still get stuck on edge cases — a jammed gripper, a blocked aisle, an object they can't classify — and that usually means an expensive on-call specialist and a long wait. With ResQueue, every robot stays connected to an AI agent (like Claude or Codex) that constantly monitors its status. When a robot signals it's stuck, the AI agent reads the situation, decides whether a human is needed, and — if so — posts a priced job to an open marketplace in real time. Any human can claim that job, but only after verifying their unique personhood with World ID, which keeps the marketplace free of bots, farms, and duplicate accounts. Once claimed, the human teleoperates the robot remotely to resolve the issue and submits proof of completion. The same AI agent that raised the alarm then reviews the fix, scores it on speed, accuracy, and task difficulty, and releases a WLD payment sized to that score — automatically, with no manual invoicing or approval chain. The result is a global, on-demand workforce that lets autonomous fleets scale without needing to hire and staff round-the-clock human supervisors, while giving anyone with a WLD wallet and a World ID a way to earn by helping robots get unstuck.

How it's made

Resqueue is a marketplace where a stuck robot's own agent hires a verified human, and the whole thing runs as one Node process plus a browser front end. Physics in Node. The robot is a Unitree G1 humanoid running in MuJoCo compiled to WebAssembly, using the official @mujoco/mujoco bindings on the server, not in the browser. The server loads the official MJCF and 34 MB of STL meshes into an in-memory virtual filesystem, steps the simulation, runs an endless pick-and-place routine over 29 position-controlled joints, and streams body poses to clients over a WebSocket at 30 Hz. The browser renders those poses with three.js, loading the same STLs from the backend. Because physics is server-side, every viewer, the console and the phone see the same robot, and control authority can be enforced in one place. Getting stuck is physics, not a script. Three triggers pull the robot out of autonomy: a person's mocap body comes within 0.6 m of a hand, joint tracking error stays high for three seconds because a rail landed on the feeder, or the next box is more than 15 cm off its mark so the grasp misses. On any of these the robot holds position and hands its telemetry to its agent. The agent writes and reviews the job. The agent is Claude with structured output validated by Zod: title, brief, ordered steps, acceptance criteria, urgency and a reward between 0.05 and 0.1 WLD. It runs in one of three modes. It can call the Claude API directly, fall back to rules when no key is present, or run in "external" mode, where the server exposes a task queue over HTTP and a live Claude Code session polls it, reads the situation, and posts the JobSpec back. That last mode is how we demoed it: the developer's coding agent literally was the robot's onboard agent, watching the queue in a background monitor. Reviews time out to the rule-based verdict after 15 seconds so payouts never wait on a slow model. World ID is the trust layer. Accepting a job opens a QR built with @worldcoin/idkit-core. The backend signs the RP context with the SDK's signRequest, binds the proof to the job and browser session through the signal, and forwards the proof to the Developer Portal v4 verify endpoint. The RP-scoped nullifier becomes the worker's identity: same human, same nullifier, one balance, one payout wallet, so nobody farms rewards with multiple accounts. Teleop messages over the WebSocket are accepted only from the session holding the active verified claim. A tampered, replayed or foreign proof unlocks nothing and the job returns to the pool. Payouts on World Chain. Every approved job triggers an ERC-20 transfer of WLD from a treasury EOA on World Chain mainnet using viem. Payments are ledgered in Supabase Postgres through the transaction pooler, with the job, worker and explorer link, and failed transfers can be retried from the console. A finished job always pays the full reward. The score only shapes the summary. Phone controller. A PWA acts as a gamepad: two virtual sticks drive four joints of the selected limb, shoulder buttons switch limbs and joint pages, A/B/X/Y map to the job's actions, and a push-to-talk button streams Opus audio plus a live Web Speech transcript so the operator can literally talk to the person standing next to the robot. The console pairs a phone by showing a QR with a six-digit code; redeeming it hands the verified session's cookie to the phone. Hacky bits worth admitting. - The G1's pelvis is welded to a stand so it can be posed freely without balance control. - The grasp is kinematic: the held box is pinned to the hand, because the WASM bindings do not expose runtime constraint toggling yet. - Raw STL data had to get MuJoCo's mesh_pos and mesh_quat inertial-frame transform applied by hand or every part rendered offset. - World ID 4.0 uniqueness proofs are one per person per action, so every verification attempt gets its own action, registered on demand through the Developer Portal's MCP endpoint from inside the server. - The pairing link asks the local ngrok agent for its tunnel URL at request time, so a fresh tunnel never needs a config edit. - The phone cockpit forces landscape by rotating the whole app with a CSS transform against a measured viewport, since browsers rarely honour orientation lock.