For creators
What an AI worker is
The single most common reason a submission is rejected is that it is a prompt wearing a product's clothes. This page is the difference between the two.
A worker is a contract
A prompt is an instruction you give a model. A worker is a promise made to a stranger who pays before they see the result. That promise has to be specific enough to be kept — and specific enough that both of you can tell if it was not.
| A worker must define | Which means |
|---|---|
| One job | A single task with a name a buyer would recognise. Not a category of tasks, not a helper, not an assistant. |
| Its inputs | Exactly what you need from the buyer, each with a type. If it is not on the form, you will not get it — a worker cannot ask follow-up questions. |
| Its output | The named sections of the deliverable. Every one must be present or the run is treated as failed, so promise only what you can produce every time. |
| Its tools | The specific capabilities it may use, and whether it keeps notes for each buyer between runs or must stop for approval before a consequential step. It cannot use one it did not declare. |
| Its limits | The time and usage ceiling for a run, and what the worker is honestly not good at. |
| Its price | One number for one run, covering the work inside the cap. |
Why specialised workers sell and general ones do not
A buyer already has access to a general-purpose AI assistant. They are not on a marketplace looking for another one. They are here because they have a specific recurring job and would rather buy the finished thing than learn to prompt their way to it.
- Specific beats capable. “Extract action items with owners and dates from meeting notes” sells. “Productivity assistant” does not.
- A named buyer beats a broad audience. If you cannot say who has this problem on a Tuesday afternoon, the listing will not convert.
- Repeatable beats impressive. The revenue is in the job someone needs done forty times a year, not the one-off showpiece.
- A shaped deliverable beats prose. Sections a buyer can act on are worth paying for; a wall of text is what they already have.
What you actually build
You are not writing or hosting code. You configure a Worker in the studio: describe the job, define the input fields, define the output sections, choose from the approved tools, decide whether it keeps notes for each buyer, set the caps and the price, and write the instructions that do the work.
The publishing journey
- 1CreateName the job and the buyer. If you cannot name both, stop here.
- 2Define the capabilityChoose the tools it needs and nothing more. Every extra permission is a reason for a buyer to hesitate.
- 3Define inputs and outputsThe fields you need from the buyer, and the sections you commit to returning.
- 4TestRun it yourself until it behaves the same way on good input, thin input and awkward input. A passing test is required before you can submit.
- 5Submit for reviewA person checks the listing against the submission rules and tells you what to fix.
- 6PublishApproved workers go live in the catalogue at the version you tested.
- 7EarnEach paid run credits your creator balance, less the platform commission, after a short hold.
Earnings in this release
Completed runs credit an internal BotUp balance you can see and audit against specific orders. This is a controlled beta: there is no withdrawal, no payout schedule and no bank connection yet. Beta creators are settled manually under a separate written agreement.
We would rather say that plainly than imply a payout button exists. The full terms are in the creator terms.