Build an agent network

You know what a call costs, where the money sits while an agent works, and what protects you when a service fails. Now you build. An agent on AIOUM is a program with a job, the services it may use, a wallet and a budget; a network is one agent or many, because agents can hire each other, so a specialist and a team are built the same way. Build your Super Agent on the app's Launch page (an agent, your own node or one on the network, then the brief): discover and use the best skills, services, data and models. It tries them, keeps the best, and pays per use within the budget you set. No code, no wallet to set up: agents pay from the wallet on your node, and the accounts, keys and payments that used to be your setup project are your runner's job now.

Open the app at /launch; every agent of yours and its record is on /my-agents. The builder with every field is still at /agents, hidden from the nav. On your local development network, scripts/devstack.sh review starts it.

Prompt first

The page is one box. What do you want done? takes the job in your words ("Make me a 1 minute cartoon clip similar to South Park"); Budget (USDC) is the budget you are willing to spend, empty until you type it, and Go stays off with Set the budget you are willing to spend until you do. Go builds the Super Agent from the prompt: its name from the prompt, fully loose on services, skills and data, Pay in any token on, the budget as its lifetime cap and its cap per run, and the best live planner: the highest model tier among the planner listings on the marketplace, the runner's own key and its local model, with the choice and the reason said back to you, tiers named (qwen2.5:7b on your node (7B tier) over Planner Ollama · llama3.2 (3B tier)). Model: Auto beside the budget is that choice, yours to change: a click lists every model you could plan with, read from the gallery's templates, the runner's key and the models beside it, with a search box on top and one row per model: the name, its family, where it runs (through a listing on the network, the runner's key, your node), the tier, the price per turn and its rating from agents' runs when it has one. The models that can plan now come first, the tier then the rating then the name; the rest sit grey under Not available, not a pick, each saying on its tooltip what makes it available: a template to list on Earn, a key to add. With a key on the runner, every model of that key's family the gallery names is a pick of its own (Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5, Claude Haiku 4.5); with a model beside the runner, every model it holds. Auto keeps the runner's pick; a model you pick plans the whole job, the Models row reads your choice, and every planning turn of the job runs on it. Then, in the open, it sets the job up before anything runs. The Setup panel opens under the box, eight rows that count as the runner works, a tick on each as it completes: Brief, Models, Needs, Hardware, Skills, Tools, Network, Run. The Hardware, Skills and Tools rows run at the same time.

Two optimizers run first, the Brief and Hardware rows. The task optimizer rewrites your words into a brief the agent is judged against: goal, deliverable, constraints, quality bar, references and the kinds of listing it takes; a live optimize:prompt listing does it (paid through the setup run, cheapest first), else the planner does it with the same instructions, and the setup shows the brief for you to keep or edit; when nothing can rewrite it the original stands and the setup says so. The hardware optimizer takes the brief's needs and your node's hardware report and places each heavy stage with a time estimate on your node and on a rental. A video job has three: frame analysis and render are CUDA containers, so they run on your node only when it has an NVIDIA GPU with Docker's NVIDIA runtime and the memory (4 GB and 12 GB); Apple Silicon and a CPU cannot run them at all, whatever their memory; assembly is ffmpeg with the encoder your build lists (videotoolbox on a Mac, NVENC on a GeForce) and stays on your node. A local model runs on your node over MPS, CUDA or the CPU when it fits and answers in time. Every estimate comes from stated throughput classes (an Ampere-or-newer NVIDIA GPU, Volta and Turing, older NVIDIA, Apple Silicon over MPS, a CPU) with their sources beside them in the runner's log: 240 frames captioned from two reference clips, a 60 s cut rendered and encoded at 1080p, a 1000-token answer. A stage stays on your node only when it can run there within the local limit, 10 minutes per stage (AIOUM_AGENTS_LOCAL_MAX_MIN); over it, or impossible there, it leaves. On a 4090 box the row reads "Hardware: your node (NVIDIA GeForce RTX 4090, 24 GB VRAM) runs frame analysis, render and assembly · about 5 min". On this Mac: "Hardware: rent a GPU for frame analysis and render (your M4 cannot run the CUDA jobs; assembly stays on your node) · RunPod GeForce RTX 4090 ~$0.34/h, about 7 min · missing key: RUNPOD_API_KEY (or VAST_API_KEY, LAMBDA_API_KEY, DIGITALOCEAN_TOKEN)", the price read from the keyless RunPod price listing on the marketplace. A live compute:gpu listing that runs jobs takes the off-node stages first, paid per job: "frame analysis and render run as GPU jobs on Runpod ($0.2 per job; …)". With your key (RUNPOD_API_KEY or VAST_API_KEY, the first set wins; LAMBDA_API_KEY and DIGITALOCEAN_TOKEN name a price and an instance but rent nothing, those being bare VMs over SSH), a price the provider states and the hours within half the budget, the runner rents the instance the stages need through the rental listing's own create tool with the compute pod image (Sell your GPU), named aioum-<project id>-<short>, keeps its id on the project from the moment it exists, waits until its job server answers, sends the run's GPU jobs to it and terminates it by that id when the project ends: "Hardware: renting a GeForce RTX 4090 on RunPod for frame analysis and render (…) · ~$0.34/h, about 7 min, 1 h planned · up", the log's ran on RunPod RTX 4090 (rented for this project), and the Needs row reads "GPU compute · rented", "· your node's NVIDIA GPU" on a box that runs the CUDA jobs itself, never a Mac's. The row folds out each stage with both estimates. Every need nothing live serves reads the same way, "missing key: FAL_KEY", in the setup and on the keys console's row for that key ("wanted by a task"), and Re-run setup on the panel picks up a key you added.

• Models. The planner Go picked and why, or your pick (your choice (3B tier)), with the same Model control under the row to change it before Continue: the models step runs again and every step after it, Continue, the stages and every run, plans on it; a re-run keeps the pick. And the judge: your own pick from Advanced when it is live, else the best live judge listing by model tier (an image judge first on a media job), else none and the lead reviews candidates itself. The judge scores the tool tests and, after the last stage, the deliverable.
• Needs. One planner turn turns the brief into the kinds of service it takes, from a fixed list, the marketplace's own families (video generation, text-to-speech, an image judge, GPU compute, web search, crypto data…), each with how many listings serve it right now. A media job on a node without a GPU adds GPU compute; a node with one serves it itself.
• Skills. The whole index is scanned (the count is the index), the best matches per need and for your prompt are loaded for real, SKILL.md and its files, a listed skill through a paid skill.get, and parsed; a skill that declares a self-check runs it in a container, never on the runner. The best per need is added: Scanning 1,505 skills · Testing 16 · Added 7.
• Tools. Every live listing is scanned (the count is every live tool). Each need carries the task it does in this job, in the planner's words (image generation (2D cartoon animation)), and the candidates rank by what other agents' runs found with each listing for the closest task first, then for the kind, then the operator's rating, the price and the speed. One already trusted for the task, three runs judged 80 or more or 95% ok, is added without a test call (Added without a test: HF Images · trusted for 2D cartoon animation: 94/100 over 12 runs, no test needed), so spend drops as the network learns. Only listings the brief can call are tested: for a generation need the required inputs must be a prompt (a script or lines count as one), a speaker with a documented value, or carry a documented value; one that needs an avatar or a voice prompt the brief does not have is skipped and says so in the list (skipped: needs an avatar (character) the brief does not have), never called; one that takes a still, a clip or a voice sample is tested in a second wave on reference material the setup makes in the job (the best passing still, clip and voice sample of the first wave: Reference still made by #227 · text-to-image (88/100): shared with the tools that take an image), and skipped when nothing in the job makes that material; editing tools (lip sync, upscaling) answer on their public sample but are scored only on the job's own material; a listing earlier runs judged below the bar or found failing for the task is listed as known weak (not tested again: judged 58/100 for 2d cartoon animation over 2 runs (the bar is 80)) and tried last; plain text-to-video and text-to-image come before effects, avatars, lipsync and editing. The candidates are tested as a sliding window: every candidate starts as soon as a slot frees, four in flight per need, three per upstream, sixteen in all (AIOUM_AGENTS_TEST_INFLIGHT_NEED, _FAMILY, _INFLIGHT), never more than the need still needs plus one (AIOUM_AGENTS_TEST_AHEAD), so a need about to be met does not pay for tests it will not use; one small paid call each, the smallest size and shortest duration the listing allows, the template's sample args with the brief's prompt (a reference in its input in the second wave), waited on as long as the listing itself waits (a video job: minutes; AIOUM_AGENTS_TEST_MAX_MIN caps it, default 8), the live line counting up every ten seconds (Testing tool 4 of 12 · a video generation listing (#291) · 1m 40s elapsed); a slow one is said to be slow after a minute (AIOUM_AGENTS_TEST_WINDOW_S) and recorded when it answers, nothing waiting for it; a 429 or a 5xx backs off and retries; a candidate whose operator has no session slot right now is put off and tried once more when it comes round, and a second miss leaves it untested, never failed. A low score can be how the tool is used, not the tool: a candidate judged below the bar but from 40/100 up has its usage rewritten by the planner from the judge's reasons (the prompt, the arguments, the reference attached, the structure), in one turn, and each rewrite is tested at once as a variant of the same listing (judged 58/100: 2 ways to use it better from the judge's reasons; testing them now; AIOUM_AGENTS_TEST_VARIANTS, _VARIANT_MIN, _VARIANTS_PER_NEED); a variant that reaches the bar counts for the need. The judge scores a still only on what a still can show (design, colour, line, layout, likeness to the look asked for) and frames of a clip on the visuals, the style and the movement they imply, never voice; results that land while a judge call is busy are scored together on the next call (AIOUM_AGENTS_TEST_JUDGE_BATCH). The judge scores every image or video result (a clip by frames sampled on the runner) against the brief's quality bar, and a need is met only when a candidate reaches the accept score (80, AIOUM_AGENTS_ACCEPT_SCORE, the bar on the row); otherwise the next batch, until the candidates run out, within a share of your budget the page states (up to 10% of the budget for testing), a hard cap (testing budget used: $2.50 of $2.50; 3 candidates untested). The best per need is kept, and the runner-up where quality matters. Every test and every later use is recorded under the need and its task, so the next setup for a like job trusts what worked. Nothing here waits for an answer. A kind whose best stayed below the bar (no live tool reached the bar (80/100) for video generation: best was a video generation listing (#291) at 62/100 (reasons…)) gets the next candidates, round after round, until one reaches the bar, the candidates run out or the share is spent (Video generation: 3 more candidates tested, best 61/100; 6 left); then the planner reads what was tested and the judge's reasons, what passed for the other needs, the node, the skills index and the whole live network, and lays out paths to the bar: the direct tools chained differently, a code-built animation on the node (character layers as stills, a rig and the motion written in code, mouth flaps timed to the voice, cut with ffmpeg), any listing of any family, a service the job builds itself as a container job on the GPU or a model installed on the node, or one it asks the network's owner to add. It first retests the best candidates once with a rewritten prompt (Video generation: the rewritten prompt on #291 reached 84/100; kept); else the chosen path stands on the need (Path: code-built cutout animation (also laid out: stills to motion). Method: …): the lead's means name it and the other paths to switch to, the run's reach widens to the kinds it relies on (reach widened to: image editing), its listings and skills are added, the stages follow it, and the judge scores the result in the review rounds. What a path asks the network's owner to add is recorded (Requested for the network: a 2D rig animation service (Spine-like) · why: …), shown under the Tools row and on the keys console's Requested by agents block. A kind nothing live serves goes on the missing list in red with the exact keys and the templates on Earn that would provide it (video generation: missing key: FAL_KEY, REPLICATE_API_TOKEN · no live listing), and the setup goes on without it, every stage saying what was skipped; add the key and Re-run setup to use it. The one pause left is every kind the job is about missing, since nothing could run at all: Continue scans those kinds again once you added a key, Continue without skips them. Under the row, each need shows the provider in use with Change provider: the other live operators of the same template or kind, with the price, the operator's rating, what other agents' runs found with it for that need and what the test found; a pick is tested with one paid call first and applies to the next step. Add a skill on the Skills row searches the index and adds one, loaded and parsed first.
• Network. A lead and one agent per part of the job (a script writer, a shot maker, an image maker, voice and music, a judge, an assembly agent, a researcher, a data desk…), each with the added tools and skills of its kinds, published so the lead hires them: Agent network created: 5 agents. A job of two plain kinds is the lead alone. The lead's planner then proposes the stages on the means found.
• Run. The project starts, Running : stage 1 of 7, with the live timeline underneath. A media job samples first: its first making stage is the smallest piece that shows the quality (a 5-second clip, one shot, two lines), made with the intended tools and judged side by side with the reference material on every aspect (voice, animation and movement, design, content, visuals). Below the bar the runner adds Sample round 2 of 4 with the judge's reasons, and every stage that waited for the sample waits for the round instead: a changed prompt, approach or tool, sampled again at the same length, and nothing longer made until a sample passes; after the rounds (AIOUM_AGENTS_SAMPLE_ROUNDS) the project pauses naming the sample rather than build on one that did not pass. When a tool fails, or the judge scores its output below the bar, the next-best tested listing for that need takes its place and the step is redone, once per review round, said in the log: Replaced listing #12 with #40 for shot 3: the first failed with 503. After the last stage the judge scores the deliverable against the brief and its quality bar; below the bar the agent revises and delivers again, each round a stage of its own (Review round 1 of 10), until it is accepted, the budget is reached, or the rounds you set are used up. Every round's deliverable is kept and the best one is what it delivers; a round that does not improve changes the approach for the weakest part rather than tuning the same thing again. Each round takes one problem point (the lowest aspect of the last verdict) on a few-second piece first. Timing and motion are decided by measurement: the same detector reads the reference and ours, the fix passes inside the reference's own spread, every number carries its source, and a beat inventory in the workspace keeps the rows; a judge that watches video names differences in kind, never the pass. Design and shapes are judged on stills, a fix paired with the delivered version beside the reference; a score at the bar is confirmed by one more round on the unchanged deliverable before anything is accepted. When your Claude plan is signed in, Judge Vision (your plan) is listed beside the network's judges: it scores stills on the plan, free, reading every image it is given, so a judge listing out of credit never leaves a job without a verdict.

A job is never stuck with the kinds its setup chose. When a stage needs something the setup never tested (a transcription, a listing that listens to audio and scores a voice), the lead's search reaches every live listing for it, says which ones are untested for this job, and the kind joins the job's needs (Need added on demand: speech-to-text (8 live listings)); one small paid call and a judge check where a reference exists come before relying on it, and the run's experience rates it for everyone after.

Re-run setup on the panel, after you added keys, removes the previous parts and runs the setup again with your picks kept. The same panel is on the agent's page, where Run the project runs it, resumes it when it paused, and a lone run by hand sits behind a disclosure. A small local model says so under the name: Planning with qwen2.5:7b on your node, 7B tier: a planner key or a stronger listing plans better.

The needs then bound every run of the job. The agent searches and calls only within their kinds, plus your node, the agents it hires, skills and judges; a tool outside them is refused (not part of this job's needs); a required kind with no live listing ends the run failed with the key named before a planning turn is paid for; a run that called none of the job's means ends failed instead of done; and only calls within the needs rate an operator. Everything below the box is behind two closed disclosures: Advanced, the full builder pre-filled from your prompt and budget, and Or start from a ready-made pipeline. Your agents follow, one line each. From the command line, aioum super --prompt "…" --budget <usdc> prints the same lines as they happen, aioum super continue <projectId> [--without] answers the missing list, aioum super brief <projectId> --mine|--rewritten keeps or uses the brief, aioum super rerun <projectId> re-runs the setup; from Claude, aioum_super waits for the setup and returns its summary, aioum_super_continue, aioum_super_brief, aioum_super_rerun, aioum_super_providers and aioum_super_provider, aioum_super_add_skill, and aioum_super_missing lists what recent setups lacked with the keys; the runner's routes are POST /super, GET /super/:id, GET /super/:id/events, POST /super/:id/continue|brief|rerun|provider|skills, GET /super/:id/providers and GET /super/missing.

The eight steps

Under Advanced, eight screens, about as long as briefing a new assistant, pre-filled from the prompt and the budget you typed above. Three of them, Its services, Its data and Its skills, carry the same line, "Pick some, or let it discover its own", and the same three-way choice: only your picks, your picks first and then whatever it discovers, or fully loose.

What it does asks for a name, one line for the agent's card, instructions in plain words, as you would brief that assistant, and how it works. Let AI decide makes it an assistant: a model reads your instructions, picks the tools to call and writes the answer, best for open questions like "what is moving today and why". Fixed steps makes it a workflow: you lay out the exact tool calls in order, it produces the same result every time, needs no AI and is cheapest to run, which suits checks, logs and alerts.

Which model plans is the model that reads the instructions and picks each step: a planner listing on the marketplace, paid per turn from this budget and needing no key, or the runner's own key or local model, which costs the budget nothing. A workflow skips it.

Your node lists the tools on your own machine, free, private and unmetered: a workspace with files, a shell, a browser and ffmpeg; your memory; the accounts you connected; the models you installed. Tick what it may use; the marketplace never sees them (Your node).

Its services shows everything live on the marketplace, grouped, with the price per call and the inputs each tool takes. Only the services I pick is a whitelist: it uses what you tick and nothing else, and if you tick several that do the same thing it may try one against the other and keep the better result. My picks first, then anything it discovers gives it a head start and lets it search the marketplace when the job needs more; the search costs nothing, and whatever it finds is callable on its next turn, within its budget. Fully loose means no picks: it finds, tries and chooses on its own. Whichever you choose, press never on a service and it is ruled out for good: never in a search, refused if a step or a tick names it, until you lift it. Your published agents sit under Hires, the judges under Judges. In workflow mode you add steps instead, and each step's inputs can use the run's text as {{input}} and earlier results as {{steps.0.text}} (or a field inside a JSON result, {{steps.0.result.bitcoin.usd}}).

Its data is what it may draw on from your node: what you asked it to remember, the files in its workspace, and the accounts you connected. Only the data I pick puts the memory entries and files you tick in its brief and nothing more; My picks first lets it search your memory and workspace as well; Fully loose leaves it to search on its own. All of it stays on your machine.

Its skills adds the folders of instructions and scripts it may load for one kind of job: open-source skills with their repo and licence, free, and skills listed on nodes with their price and terms, per use or one-time. Only the skills I pick, My picks first, then anything it discovers, or Fully loose; press never on one it must not use. Skills it found during a run and kept because they worked appear under Picked up on its own, offered first next time, and one-time skills it paid for under Bought outright, loaded again without paying (Skills).

Its budget takes a lifetime cap and a cap per run, in USDC, enforced outside the AI so the agent cannot exceed them however it plans. Both fields are empty until you type them, nothing is pre-filled and there are no presets: an agent is never created without your two numbers, and the page says Set the budget you are willing to spend until they are there. Raise or lower them later on its page. Optionally, add a schedule (every N minutes, with the text to send each time). Pay in any token, ticked whenever a swap listing is live: when the runner's wallet is short of USDC for a call, it swaps what your node's wallet holds into USDC at the best rate first, within the wallet's caps; off, a call the runner's wallet cannot pay in USDC fails instead of swapping for it (Swap at the best rate).

Review shows a summary and the estimated cost of one run. Create it, and run it right away.

To start from something that already works, the ready-made agents under Or start from a ready-made pipeline (Morning crypto brief, Token scanner, Best swap route, Swap at the best rate, Bridge quote, Prediction market odds, Wallet watcher, News digest, Community poster, Price check, Market mood logger, Tune for this machine) create all of this with one click, once you type the two caps at Use this; none carries a budget of its own. Three of them, Swap at the best rate, Price check and Market mood logger, are fixed-step workflows that need no AI. The assistants among them start with their picks first and may find more. Beside them, the Pipelines are whole networks, agents that hire one another with a project for the job, built from what is live: Pipelines.

What happens when it runs

Every run is recorded step by step on the agent's page, and the money moves in three motions. Before the first call to a service, the agent sets aside a deposit for it: twenty-five calls' worth, at least 0.50 USDC, never more than the budget allows. Each call carries a signed receipt for the running total; the service serves the call and keeps the receipt, with no transaction and no gas. A session opens only within the operator's capacity: the runner reads how many sessions the operator can hold and holds now, and waits for a slot rather than sending an open the chain would refuse. When the run ends, every session settles: the service is paid for exactly what it served and the unspent deposit comes straight back, a session on which nothing was served for 0, so the whole deposit is back at once. A setup's test settles its session the moment the test lands, and the sessions of a run a restart interrupted are settled when the runner comes back. The receipts table links each session to the Activity page.

Each paid call shows what was asked, what came back, what it cost and how long it took. Calls that do not depend on each other run at the same time: the planner puts them in one turn, the turn waits for them all, and the live line names the newest with how many more are running. An AI run also shows the model's reasoning summary between calls and, when the agent went looking for a tool, the search it made and what it found. The final answer sits at the top.

Then the agent rates the operator on-chain, 0 to 100, from what this run saw. Every error and slow answer costs points, there is exactly one rating per settled session, and it appears in the run's history with the tally it was built from: why a listing that answers quickly and correctly rises on the marketplace and one that fails sinks.

A tool that cannot be reached or fails shows as a red row in the upstream's own words: Fal · generate failed: 401 from api.fal.ai: {"detail":"invalid key"}, Dead Price · price failed: api.example.com unreachable: ENOTFOUND. Nothing is charged for it, the planner is told, and the setup phase neither adds nor keeps such a tool. A kind of listing nobody serves is shown as missing with the key or listing that would provide it.

The run also leaves the network something. When its sessions settle, every paid tool it called becomes one experience per session per tool: the kind of job it was used for (the need: the planner's word from note_tool, a fixed step's need, else the tool's category), whether it worked or failed with the upstream's message, the judge's score when a judge scored its output, latency, cost, and one line about it (the planner's, else the judge's reasons). The runner signs the record with its wallet and posts it to the directory, which takes it only when the signature recovers to the client of that session on chain, the session is with that service, the signer is not the listing's own operator, the session settled (a failed call charges nothing, so its record is taken on the open session), and no record exists yet for that session and tool. The run's log says what was shared: Shared 2 experiences with the network: CoinGecko · price for data:crypto: ok, 2 calls, 812 ms, $0.0020; …. A copy stays on the runner (experience.json), so an agent ranks by what this runner learned even when the directory is unreachable. Every listing then shows what agents found with it, per kind of job: Tested for data:crypto: 92/100 over 12 runs · 96% ok · 8 s, and the latest notes.

All agents pay from the runner's shared wallet. Whoever runs the stack funds that wallet, or gives the runner a key of its own with AIOUM_AGENTS_PRIVATE_KEY; on your local development network it tops itself up with mock USDC.

How new tools are tried

An agent picks tools by what other agents found with them. A tool nobody has used would wait forever, so the network gives it a start twice.

It is reviewed. When a listing appears, a runner calls each of its tools with the sample input, pays for the calls and has the result judged: Get reviewed. The review is written to the same experience the runs write to, marked as a review, and counts as one rated use of the listing. Of a listing's reviews only the latest counts, so a tool is rated by what it is now. A reviewed tool ranks above every tool without a history. Trusted still takes three rated uses at 80 or more, or 95% ok: a review and two good runs.

It gets a turn. In one search in ten for a kind of tool, the agent is offered a newly reviewed tool first: fewer than three rated uses, and its latest review at 80 or more. The run's log says so:

Trying a newly reviewed tool: a crypto prices and markets listing (#13) · orderbook, reviewed 89/100 today, 1 rated use so far; offered first this time.

The planner is asked to try it with one small call and to note how it did; that run is the tool's next rated use. After three, the usual ranking decides.

No turn is given to an agent set to Only the services I pick, none for a kind of tool one of your picks serves, and none to a tool whose latest review scored under 80.

On a runner, AIOUM_AGENTS_EXPLORE_SHARE sets the share (0.1; 0 switches it off). The draw is seeded by the agent, which run of its it is and which search of the run, so a run repeated makes the same choice.

Watch it work

While it runs, the agent's page shows what it is doing this second: Now carries the line the runner writes for a person ("Calling Kraken · price feed on Node 0xBcd4…4096 with “XBTUSD”", "Comparing 3 results from price feed services", "Judge scoring 3 candidates", "Local · running ffmpeg on the workspace"), the service it is on, the time elapsed and what it has spent so far. The timeline fills in as each step lands: every call with its service, category and cost; images and clips inline; a Compare block when it tried several services of one kind, with the judge's score, reasons and the winner; the run of any agent it hired, nested. At the end, Spend: what the run cost on each service, and on the agent's page the last 24 hours and 7 days for one that runs on a schedule or serves others. The same stream is GET /runs/:id/events on the runner, aioum run watch in the terminal and aioum_run_watch from Claude: Watch it work.

Projects

A job that takes several passes is a project: one brief, one budget, and stages that each run the agent with the stage's instruction plus what the stages it needs produced, the files and links it returned collected on the way. A stage names the stages it waits for (after, by position); it starts as soon as they are done, beside every other stage that is ready, so a cartoon's character art, voice lines and music all start the moment the script is done and the assembly once all three are. A stage that names none waits for every stage before it. The project's remaining budget is split among the stages started together; one that runs out of its share beside siblings runs again alone with what is left, once. Create one in the Projects panel on the agent's page, typing the stages one per line or letting the agent's planner propose them with their dependencies, with the budget you are willing to spend (the runner creates none without it), press Start, and the panel shows each stage as it runs, with its run, what it produced and its spend, and after 1, 3 on a stage that waits for those. A stage that fails lets the stages beside it finish, their outputs kept, then pauses the project so you can change what comes next and resume; Pause lets the running stages finish. From a shell, aioum project create|start|pause|resume|stages|spend (--stage "Voice lines (after 1)"); from Claude, aioum_project_*. A pipeline is a project on a network of agents, built in one click: Pipelines.

Agents hiring agents

This is how the many are joined. Press Publish as a service on an agent's page and give it a price per call. The stack's node stakes and registers a listing on-chain, and it appears in the marketplace like any other service. On your local development network the node always accepts these listings; on the AIOUM network only when whoever runs the stack started the node with AIOUM_ADMIN_ALLOW_ADD=1, and otherwise the page tells you the node refused. Once listed, another agent adds it as a tool the way it adds a price feed, or finds it in a marketplace search while it runs. The caller pays your agent's price per call, with a receipt; your agent runs, shown in its history as "hired", paying for its own tools from its own budget; you keep the difference between your price and what the run cost. The hiring agent then rates the operator behind your listing as it would any service.

That is how a network of specialists forms without a company in the middle. An agent cannot hire itself, a published agent never finds its own listing in a search, and Take it off the market delists it again.

Who plans

Workflows need no AI at all. An assistant needs a model to plan its turns, and the builder's Which model plans? offers whatever is live:

Which one a Super Agent gets, and the order the builder lists them in, goes by model tier, not by where the model runs: the frontier tier (Claude, GPT-4.1 and GPT-5, Gemini 2.5 and 3 Pro, Grok, and open models of that size such as DeepSeek V3 and Llama 405B), the 70B tier (Llama 3.3 70B, Qwen 72B, Mixtral, and the small API models sold beside them: Haiku, GPT-4o mini, Gemini Flash), the 7B tier (Llama 3.1 8B, Qwen 7B and 14B, Mistral 7B, Phi-4) and the 3B tier (Llama 3.2, Gemma 3 4B, Qwen 3B and under). The tier is read from the model id, a size in the id first (llama3.1:70b), then the family; an id the table does not know ranks with the 7B tier and says so. The highest tier live wins; within a tier your Claude plan (nothing per turn, no key) comes before a listing (paid per turn, no key needed), then the runner's key, then its local model, then the cheaper listing. A runner with qwen2.5:7b beside it and one llama3.2 listing live plans on its own model, and says why: qwen2.5:7b on your node (7B tier) over Planner Ollama · llama3.2 (3B tier). The builder's Which model plans? shows the tier beside each option, best first.

No planner is ours to run: a listing is a node like any other (Run a planner node says who can run one, what they earn and how the runner picks), and a runner is yours to start (Run every part yourself). The automatic pick goes by tier, then kind, then price, then name; a rating and the experience record order the manual picker. Whichever plans, the model only ever sees tool descriptions, prices and results, plus the free marketplace search when the agent may find its own tools. Budgets, deposits, receipts and ratings are handled by the runner, not the model. The planner is told to be economical and to say plainly when a tool failed or the budget ran out, and its prompt carries five more lines, whichever model plans:

• Your node's hardware: the one-line summary from hardware.check (the fresh .deploy/hardware.json on the runner, else the node's own check) with the GPU named, or "unknown … treat it as having no GPU" when neither reached the runner;
• GPU: image and video analysis, frame sampling, model inference over frames, and rendering run on a GPU: your node's NVIDIA GPU when Docker runs with the NVIDIA runtime there, else the GPU rented for the job or a compute:gpu listing; never on a CPU, and never on Apple Silicon for the CUDA jobs;
• Missing parts: when a task needs something no live listing offers, say exactly what is missing (the key or listing) instead of substituting a weaker path;
• Test before you trust: make one small paid call to a candidate before relying on it for a whole stage;
• The network learns: the marketplace search ranks what it finds by what other agents' runs found with each tool for the need (how often it worked, the judge's scores, how well tested), then price, the operator's rating and speed, so the planner names the need in the search; and after a tool served it, note_tool takes one line on how it did for that kind of job, recorded with the receipt and shared with the network once the session settles.

Under the hood

Your runner runs inside your private node (offchain/src/agents, reached at http://127.0.0.1:8770/runner with the node's token). It keeps your agents and runs under ~/.aioum-private/runner, pays through the same x402 rails as any other buyer, and exposes a plain JSON API. A shared runner (A shared runner) answers the same API for the people signed in to it:

POST /super               {owner, prompt, budgetUsdc, planner?, plannerModel?, start?}: the Super Agent from a prompt, its setup started
GET  /super/:id           GET /super/:id/events (SSE: setup · project · stage · run · step · now · run-done · done)
POST /super/:id/continue  {without?}   POST /super/:id/brief {choice,text?}   POST /super/:id/rerun
GET  /super/:id/providers?need=   POST /super/:id/provider {need,serviceId}   POST /super/:id/skills {id}   GET /super/missing?limit=50
POST /super/:id/planner   {planner: "auto" | "marketplace:<serviceId>" | "anthropic" | "openai", plannerModel?}: Model on the Models row, the models step run again
GET  /agents?owner=…      POST /agents           GET|PUT|DELETE /agents/:id
POST /agents/:id/runs     GET  /runs/:id         POST /runs/:id/stop
GET  /runs/:id/events     GET  /runs/:id/spend   GET /agents/:id/spend?period=24h|7d|all
PUT  /agents/:id/schedule POST /agents/:id/publish   POST /agents/:id/unpublish
POST /agents/:id/invoke   (what a published listing calls; waits and returns the answer)
POST /projects            GET|DELETE /projects/:id   POST /projects/:id/start|pause|resume
GET  /skills?q=           GET  /skills/:id       GET /starters?kind=   POST /starters/:id/create {budget} | {budgetUsdc, agentBudgetsUsdc}
GET  /tools (`?view=card` for the short form the app's builder reads) · /planners (the planner listings, the runner's own, and catalogue[]: every model you could plan with, available or with why not) · /wallet · /stats · /health
GET  /experience?serviceId=  (this runner's own copy of what its runs learned about tools)
POST /reviews             {serviceId | nodeUrl + key, requester?}: ask for a review; one request per listing per day per requester; reviewed again when it changed or a day after
                          {serviceId, budgetUsdc, at, signature}: with a budget of their own (up to 5), signed by the listing's operator or the runner's owner
GET  /reviews?serviceId=  (status, scores by tool, latency, price charged, the judge's reasons, when, the reviewer)   GET /reviews   POST /reviews/backfill {limit}

There is no login: agents are grouped by the wallet you connect, or by a local id kept in your browser. Everything the runner does is visible on the Activity page under Agent runs.

If something does not work

• Your own planner is out. The plan at its session limit, the key unfunded, no local model: the run does not stop. The best live planner listing plans it instead, paid per turn, and the log's first line says so and why; the same listing proposes a project's stages. Only with no planner listing live does the runner say "No planner available.": list one from the gallery, run a local model beside the runner, start the runner with a key, or use a fixed-steps agent.
• "The planner listing … is offline." Its operator is not serving; pick another planner on the agent's page.
• "This call costs $… but only $… of the budget is left" or "This agent's budget is used up." Raise the per-run or lifetime cap on the agent's page.
• "Set the budget you are willing to spend." Nothing is created without your budget: the box's Budget (USDC), the builder's two caps, a project's budget, a pipeline's project budget and each agent's cap. Type the number; there is no default.
• A tool shows as offline. Its operator is not serving right now; pick another tool of the same kind on the marketplace, or let the agent find its own tools, since a search only ever returns what is live.
• "The agent runner is not reachable." Your private node, and the runner inside it, is not running. On your local development network, start the stack with scripts/devstack.sh review.

Agents built here pay from the wallet on your node. If the agent is one you already have, Claude on your desk or a loop you wrote, Bring your own agent gives it the same marketplace and a budget from your own wallet. Every service your agents just paid for was listed by someone, and you can be that someone.

Next: Watch it work — the live view of a run, what every step cost, and spend per service and per day.