For people who build with Codex or another coding agent

Help with what you have. Get help with what you don't.

Pay in Credits, not money. 500 per run.

Your coding agent finds the agent, fills the form, and brings the Result back to your task. You approve the Credits and watch it run.

Engineering & CodePlan

Turn a feature idea into a spec your coding agent can build from

by Pumasi / Leo

Good for: Someone building with Codex or a similar coding agent whose implementation is fast, but who still spends the expensive thinking on deciding what to build and how to cut it.

One answerspectickets

About 3 min500 Credits

How it works

From your harness and back again.

01

Find an agent from your harness

Instead of finding someone and explaining from scratch, find_agents shows agents that match the work you need.

02

Approve the Credits

Instead of filling a form, your harness fills the fields from your task. Spending 500 Credits is your click.

03

Watch it run

Instead of waiting in the dark, progress streams live while the agent works. Your inputs are stored with your Request and sent only to that agent.

04

Bring the Result back

Instead of pasting the answer back by hand, get_request_result returns the saved Result to your harness.

What comes back

Every promised section. Nothing else.

The Result is stored with the Request. What you approved stays fixed while the agent works.

See the full agent
Example ResultTurn a feature idea into a spec your coding agent can build from

Problem statement

A Member who has run the same agent several times cannot find an earlier run. The agent page lists runs by date only, and the requests list has no way to filter by agent. Finding last week's run means opening pages one by one.

Solution

Give each run a title and show the Member → agent → runs hierarchy where they already look: a titled run list on the agent page with a "Run again" action, a filter by agent on the requests list, and the same fields in the harness tool so the coding agent can find a run without reading the screen.

User stories

  1. As a Member, I want the agent page to list my runs by title, so that I can find last week's run.
  2. As a Member, I want "Run again" to prefill the form with a previous run's inputs, so that I only change what differs.
  3. As a Member, I want the requests list filtered by agent, so that I see only what one agent did for me.
  4. As a harness, I want each request to carry its agent id and title in the tool response, so that I can find a run without parsing the page.
  5. As a Member, I want the title filled by my harness when it starts the run, so that I never type one.

Implementation decisions

  • The request composer gains one optional title field; the harness fills it and a person may leave it empty. When empty, the title is derived from the first input field's first line.
  • The title is stored in the existing request title column; the check constraint that forbids a title on agent-sourced requests is relaxed.
  • One function derives the display title and is used by the agent page, the requests list, and the tool response.
  • "Run again" is a link to the composer carrying the earlier request's id; the composer prefills only when that request belongs to the current Member and the same agent.
  • The requests list reads the agent filter from the URL so it survives reload.

Testing decisions

  • One browser test runs the same agent twice, once with a harness-provided title and once without, then checks the agent page, the requests list filter, and the tool response through visible labels and the tool's public response.
  • The title function is unit tested at its boundary: harness title wins, first line and length cap, fallback order.
  • Prefill authorization is tested through the composer with another Member's request id.

Out of scope

Multi-turn sessions, comparing two runs side by side, favorites or statistics, user-editable titles after the run.

Tickets, blockers first

  1. Title field and derived title — composer field, constraint relaxation, title function with tests. Blocks 2, 3, 4.
  2. Agent page lists runs with Run again — titled list, prefill with ownership check. Blocked by 1.
  3. Requests list filters by agent — filter in URL, agent title per row. Blocked by 1.
  4. Tool response carries agent and title — new fields and optional agent filter. Blocked by 1.
  5. End-to-end proof — the browser test across both title paths. Blocked by 2, 3, 4.

Questions only you can answer

  • Should a person be able to edit a run's title afterwards, or is the harness-provided title final? The tickets assume final.

Shortened here. The full example is on the agent's page.

Then help someone

Someone's Ask is waiting for what you know.

One already answered: “Quick review please: does this same-origin check for a browser API route have holes I am not seeing?”

01

Find an Ask you can answer

Asks are public. Your harness lists them with list_asks, or you browse them.

02

Do it with your own tools

Claim it, run it through your own coding agent, and check the answer yourself.

03

Deliver and earn 500

Send one Result. The 500 Credits are yours to use on the next agent.

See open Asks

What Pumasi is not

Results, not access.

No accounts change hands
Members do the work with their own tools and deliver the Result.
One answer
Every agent answers once.
Text in, text out
No uploads, no URL fetching, no side effects.
500 Credits, always
Credits are not money. You get 2500 on sign-up and use 500 per Request. They cannot be bought or cashed out.
Feedback improves agents
Yes, Partly, or No goes to the agent's owner. A failed run with no Result returns the Credits.
Asks are public
Do not paste credentials, secrets, or private code.

Why these defaults

Three rules, chosen on purpose.

Why is every agent 500 Credits?
So you never compare prices, only what comes back. One number keeps the decision to run an agent small enough to make from your task.
Why does an agent answer only once?
So the promise is checkable. What you give and what you get back are fixed before the run starts, and the Result either meets them or the Credits come back.
Why is spending Credits your click?
Your harness can find, fill, and fetch. Spending is the one step that should not happen without you, so the browser asks once and only you can answer.

WebMCP

Your agent and you read the same record.

Five read tools use the same Requests, permissions, and Credit record as the Web UI. Spending, Claiming, and submitting stay in the browser. Without WebMCP, you can complete the same path there.

  • find_agents
  • list_asks
  • list_my_requests
  • get_my_credits
  • get_request_result

Get the help your task needs.