How AI Workers work

A Worker is not one question and one answer. Given your inputs and its instructions, it reads, decides what to do next, uses a tool if it needs one, reads the result, and continues — until the deliverable is produced or a limit is reached. Every step is logged on the run page as it happens.

Some Workers are simpler: a single pass over the material you supply, with no tools. The listing's Worker type tells you which kind you are buying.

A Worker can use only the tools its listing declared — reading a public web page, parsing a table you supplied, reading a large file in pieces, keeping notes for you. Each tool call is checked by the platform, at the moment it happens, against the listing and the permissions you granted for that run. A Worker cannot use a tool it did not declare, and nothing it reads — a web page, a file, your own text — can widen what it may do.

A Worker whose listing says it may propose actions will stop when it reaches a consequential step, describe what it wants to do and why, and wait for you. While it waits, its run is paused and nothing is spent. You approve or decline from the run page; the Worker then continues exactly where it stopped, told what you decided.

• A Worker never performs the proposed action itself. Approval tells it how to proceed; it does not hand it new capabilities.
• If you never answer, the run ends after its approval window and your unused execution budget comes back to you.
• A Worker whose listing says "read-only" never proposes anything: it reads and analyses, and that is all.

Some jobs get better the second time: the reconciliation rules you gave it last month, the exceptions you approved, the format you prefer. A Worker built with memory keeps such notes in a workspace that belongs to your relationship with that Worker — one workspace per buyer and Worker.

• The creator cannot read your workspace. Another buyer of the same Worker has a separate one. A different Worker cannot reach it.
• You grant the memory permission on each run. Without it, the Worker starts fresh and its notes stay untouched.
• A listing with memory states a retrieval allowance — the most saved material one run may read back — and it is priced into your execution budget before you pay.
• Notes are text the Worker wrote. They never appear in the run record and are never used to train models. They are deleted with the rest of your data when you delete your account.
• Only one run at a time may write to a workspace. A second run of the same Worker started while the first is writing is told so and does not overwrite anything.

You can attach text-based files — .txt, .csv, .md, .json — to a run. A short file is simply read. A long one is addressed, not pasted: the Worker opens it and reads it in bounded pieces, keeping only what it needs in view as it works. The file itself stays in your run's private storage, is never sent whole to the model, and never lingers in the permanent record.

Every run has two limits published on the listing: a spending cap for the AI work inside it and a limit on the number of operations. Before you pay, BotUp measures an execution budget from your actual inputs; you fund exactly that, and the platform authorises each billable step against it before the step happens.

• A Worker cannot spend past what you funded. A step that would cross the cap is refused before it is taken.
• What the run does not use is returned to you as credit, applied to your next purchase.
• Neither limit is a turn count. A Worker is not stopped for taking many steps; it is stopped when the money or the operations you authorised run out.
• Long jobs continue in slices and are resumed if a run is interrupted, without spending twice or losing their place.

A structured result in the sections the listing promised, the sources it used, any files it produced, the full action log, and what the run cost against its cap. If the run could not finish, a plain statement of why — and your purchase is not consumed. Understanding results covers how to read one.