Assembled, not prompted: what a custom agent actually is

A subscription rents you a chat window and a monthly bill. An assembled agent is a workspace you own: chosen parts, your own accounts, a wallet you fund, ceilings you set, and a ledger of every paid call.

The difference that matters

A subscription is a rental with a good interface. You buy a seat, a plan, or a bundle of tokens, and in return you get a window that answers questions and a charge that arrives at the end of the month whether the work was done or not. The model behind that window may be excellent. It is also, more often than not, the model anyone else can rent, which makes capability the least useful thing to compare between two products that both offer it.

What separates them is not what the agent can do. It is who holds what, and how the money moves. Three holdings decide it: the workspace the agent runs in, the accounts it is allowed to touch, and the wallet it spends from. Under a subscription all three belong to the vendor, and the monthly figure cannot be attributed to any particular piece of work. Under an assembled agent all three belong to the client, and every call carries its own price.

An assembled agent is equipped for a job rather than ordered as a product. A workshop is not bought as one machine; it is fitted out — a lathe for turning, a press for forming, a bench for assembly, a lock on the door. An agent is fitted out the same way: specific parts for a specific job, connected to specific accounts under allow-lists, drawing on a wallet with three limits attached, and keeping a record of every call it paid for. All of it under the client’s name — the assembly, the connections, the wallet, the ceilings, the record.

Two questions sort the market cleanly. Whose container does the agent run in, and what does one call cost? “Our platform, and it is included in your plan” is a rental: the container, the price and the record are the vendor’s. “Your container at your address, and $0.007 a call” is a purchase. A vendor that answers the first question with a plan name has already answered the second, and the answer is that nothing here will be attributable to a job.

Ownership is not a free upgrade. It moves work to the client: someone funds the wallet, someone chooses the ceilings, someone issues and revokes credentials, someone reads the record. A subscription hides that work inside the price, which is most of why it sells. The honest question is not whether the work exists but whether the client wants to see what the work costs. A metered workspace makes the cost legible and the labour visible at the same time, and a buyer who wants neither should rent.

This article describes one implementation of the assembled model: the agents offered on x402.press and reviewed on this site. It is written from the published parts bin, the published prices and the stated limits. Where something is not built, it says so. Where a number is an assumption, the assumption is labelled.

The parts bin

A part is one capability with a version number. The bin holds thirteen of them in four classes, and all thirteen roles described in the next section are assemblable from it today. Table 1 sets out the bin in full.

Table 1. The parts bin: thirteen parts in four classes. Source: x402.press parts catalogue, 30 October 2026.

The descriptions in the fourth column are read from the part names, except for graphify and wolfram_alpha, which are described as the catalogue describes them; where a name is ambiguous, the catalogue is the authority rather than this table.

The classes are not decoration. They fail differently, and a buyer should price a part by how its failure presents. A documents part produces an artefact — a table, a deck, an invoice, a report — and its failure is visible, because the client reads the artefact. A compute part produces a judgement over numbers, and its failure is quiet, because a wrong view of a company’s accounts looks exactly like a right one. An external part reaches outside the workspace for retrieval or computation, and its failure usually arrives as a timeout or an absent answer. A connections part is the only kind that touches the client’s own accounts, which is why it is the only kind that needs an allow-list, and why it is the smallest class in the bin.

Two notes on the bin as it stands. wolfram_alpha is in build. WhatsApp is not built at all: the adapter ships in the image, but it needs a Node bridge and a paired session that the container does not run, so no role is offered with WhatsApp today. email and telegram are the two built channels, which is a short list and is meant to be read as one.

The argument for a bin over a monolith is not elegance. It is three practical differences.

A monolith is priced as a whole. A job that needs one of six document functions pays for the six, and pays the same in a busy month and an empty one. Parts are costed where they consume something metered, and a part that consumes nothing metered adds nothing to the bill.

Versions move separately. data_table sits at 0.2.0 beside deck at 0.1.0. When one part is replaced, the role built on it does not have to be abandoned; when one part is immature, the parts beside it are not held back to its level.

The bin can be published in full, so its absences are visible. A monolith’s gaps are discovered by hitting them — you ask for a channel and learn at that moment that it does not exist. Thirteen named parts with version numbers tell the reader, before the conversation starts, that there are six document parts, two built channels, one external part in build and no WhatsApp.

The thirteen roles

A role is a job, not a persona. It is the unit at which the client buys: a name for a repeated piece of work, with a parts list and a services list attached. The role adds no capability to the parts. It fixes which parts a job needs, so that the same job is assembled the same way twice.

Table 2. The thirteen roles, each a job with a parts list and a services list. Source: x402.press role gallery, 30 October 2026.

The one-line descriptions in Table 2 are ours, written from the role names. The gallery’s own wording differs, and the authority on any specific role is its own page, which states the parts it needs and the services it buys from. Those two lists, not this table, decide what an assembly costs.

Two consequences follow from treating a role as a job description rather than a product. The first is that close is often good enough: a client who wants trade documentation assembled will find the Trade Analyst nearer than the Writer, and the design conversation is where the difference between the two is settled. The second is that a role name is not a qualification. ISO Auditor names a job; it confers nothing, and we return to that under Where it stops.

Every one of the thirteen is assemblable today, and assemblable is not the same as available. Four services are sellable today, and on this site they are the four whose reviews carry the live status: DeepSeek, Qwen, HyperFusion and SpiralStake. The rest are offline pending review. A role whose assembly buys from an offline service can be built and cannot spend until that service returns, which is a distinction worth having before the proposal rather than after it.

Assembly, step by step

Assembly takes about ten exchanges. It is a design conversation, not a form. The job is described in the client’s own words, and the exchanges narrow that description until it has the shape of a proposal.

The exchanges have to settle five things.

1. The job. What arrives, what leaves, who reads it, and how often. Described in the client’s language, not the catalogue’s.
2. The role. Which of the thirteen names that job, or how near the nearest one is. A role that is close but not exact is normal; the gap is what the parts list is adjusted for.
3. The parts. The assembly the role page states, plus anything the job needs that the role does not carry.
4. The connections. Which accounts, under which allow-lists, and which of the built channels. This is the point at which a client discovers that the short list of channels is short.
5. The limits and the projected running cost. Three ceilings, and the monthly figure that follows from them at the measured prices.

Five decisions, about ten exchanges. The number is not fixed because jobs are not: a well-described job converges in fewer, and a job that has never been written down takes longer. That longer conversation is usually the most valuable part of the exercise, because it is the first time the work has been described without a person standing in the middle of it.

The output is one document. It states the role, the parts, the connections, the limits and the projected running cost. Read it against what was said in the first exchange: the gap between the two is where scope drifts, and it is cheaper to close before provisioning than after.

Then a person approves it. Not a flow and not an automatic acceptance — someone on the client’s side reads the proposal and says yes.

Then the balance is confirmed. The opening balance is 0.50 USDC on Base, held in the client’s own wallet and credited to the workspace, as the next section sets out.

Then the workspace is provisioned at https://workspace.x402.press/<slug>, in its own container with its own volume, separate from every other client. Credentials for connections are held only inside that container. portal.x402.press redirects to the same path, so there is one address for the workspace and no second console to learn.

The wallet and the ceilings

0.50 USDC on Base, in the client’s own wallet, credited to the workspace. The first thing to get right is the one most often misread: it is an opening balance, not a fee. Nothing is transferred to the operator at provisioning. The money is the client’s, remains in the client’s wallet, and is available to the workspace to spend on calls. It buys the first calls; it does not buy the right to make them.

It is worth being precise about what $0.50 is not. It is not a deposit held by a third party, not credit that expires, and not a setup charge dressed as a balance. It is working capital at call-sized scale: at the DeepSeek price a single call is $0.007, so the opening balance is a little over seventy calls at that price.

The agent pays per call from that wallet under three ceilings the client sets: a maximum number of paid calls per message, a maximum per message, and a maximum per day. The three are not variations on one idea. The first bounds how much work a single instruction may trigger. The second bounds the price of one answer. The third bounds the month’s pace, which is the figure that surprises people.

A ceiling is a control, not a promise. A promise is a statement about the future that cannot be checked until it is too late: we will not overspend. A control refuses the call before the money moves. The distinction is testable, and it should be tested. Set a ceiling low, send the agent a job that wants more, and watch what the workspace does. If it stops, the control is real. Whatever the agent says about its own restraint is not the evidence; the refusal is.

The ceilings are arithmetic the client can do before the first message. At $0.007 a call, seven paid calls inside one message is $0.049. If five cents is the most any single instruction should cost, set the per-message ceiling at five cents and the maximum number of paid calls at seven; the two move together. The per-day ceiling is the one to set from an expectation about the month rather than about a single answer.

Three limits on what a ceiling can do, stated plainly. It bounds the workspace, not the market: a service that raises its price brings the ceiling closer, and the ceiling is a limit on calls, never a guarantee about prices. It bounds spending, not correctness: an answer bought inside the ceiling can still be wrong. And a ceiling set too tight is an availability limit wearing a budget’s clothes — the agent stops, and a stop looks like a fault to whoever sent the job.

What the wallet buys beyond calls is the record. The workspace records every call it paid for: the service, the price, the time. That record is the other half of metering. A claim of no markup is only credible if the client can add up the calls and reach the same total the operator does. A monthly figure that cannot be attributed to work cannot be argued with, only paid.

What the client owns

Six holdings, each of which the client can point at.

• The workspace. https://workspace.x402.press/<slug>, reachable at that address, with portal.x402.press redirecting to it.
• The container. Its own, running the workspace’s image, separate from every other client.
• The volume. Its own storage, holding the workspace’s files and its record of calls.
• The wallet. The client’s, on Base, funded by the client.
• The accounts. The mailboxes and channels the agent may use, under the allow-lists the workspace was given.
• The data. What the agent reads and produces, in the container’s volume rather than in a shared pool.

What the operator does not hold follows from that list. It holds no credentials for the client’s connections: those live only inside the client’s container. It holds no funds: the balance is in the client’s wallet. It holds no access to the client’s accounts beyond what the workspace is configured to use. And it holds no copy of the client’s data as a matter of course, because the volume is not shared.

What the operator keeps is the other side of the line: the parts and their versions, the image the container runs, and the catalogue of services with their prices. The split should be read literally rather than generously. The client owns the workspace, not the software that fills it, and cannot take the parts elsewhere. That is still enough to matter — credentials, files and the call record sit in one container the client can account for — and it is less than owning a product the client could carry to another supplier.

What it costs to run

Cost is the sum of the calls, at prices that were measured rather than estimated. In Base USDC: DeepSeek deepseek-v4-flash at $0.00700 exact, with a metered ceiling of $0.00955 at max_tokens: 1000; Qwen qwen3.8-flash at $0.00875; a SpiralStake build call at $0.006125. The document parts carry no separate per-call price in the public catalogue, so they do not appear as a line in the table below. That is an omission, not a saving: it means the total understates what the workspace is doing.

The month below is illustrative. There is no reference tenant yet, so the call counts are ours, chosen to be plausible rather than observed, and each one is an assumption.

• Twenty working days.
• One hundred requests: five a working day.
• Three paid model calls per request, 300 in the month — 240 on DeepSeek and 60 on Qwen, all priced at the exact rate rather than at the metered ceiling.
• Twenty-five reports, one request in four, produced by the document parts.
• Eight build calls, on the assumption that the role also buys a build service at the SpiralStake price.

Table 3. An illustrative month for one role, priced at measured Base USDC rates. Call counts are assumptions, not observations; there is no reference tenant. Source: x402.press catalogue prices, 30 October 2026.

The arithmetic is short. 240 calls at $0.00700 is $1.68000. Sixty calls at $0.00875 is $0.52500. Eight calls at $0.006125 is $0.04900. The three add to $2.25400 for 308 paid calls in the month, with 25 reports on top at no separately published price.

Divided out, that is $0.02254 per request, $0.11270 per working day, and 15.4 paid calls a working day. Twelve months at the same volume would be $27.05, before anything the document parts cost that the catalogue does not publish.

The ceiling is the sensitivity to check. Every DeepSeek call above was priced at its exact rate. If the same 240 calls settled at the metered ceiling of $0.00955 instead, the model line becomes $2.29200 and the month $2.86600 — $0.61, or 27 per cent, above the exact-price total. That difference is the size of the discretion a metered call sells, and it is the figure to look at when deciding whether a fixed price is available for the work.

Double the volume and nothing changes but the total: $4.50800 for 616 paid calls. The opening balance is the number that needs the most careful reading. At $0.11270 a working day, $0.50 covers about four and a half working days. It is not a month’s running cost, and treating it as one would misread the mechanic entirely. It is enough to start, to run a first real job, and to watch the record fill — which is the only way to find out whether the assumptions in this table are anything like the client’s month.

What it refuses

Five refusals, each of them a boundary the workspace enforces rather than a policy it prefers.

1. No unconnected accounts. The agent acts only where a connection has been configured under an allow-list. A mailbox it has not been given is a mailbox it cannot read, and it will not improvise a route to one.
2. No publishing without a channel. Drafting is a document part; publishing needs a connected channel. Where there is no channel, the work stops at the draft, and no amount of instruction inside the message changes that.
3. No WhatsApp. The adapter ships in the image and is not wired: it needs a Node bridge and a paired session the container does not run. A role cannot be assembled with it today, and any claim that WhatsApp works through this workspace should be treated as wrong.
4. No spending outside the ceilings. The workspace refuses the paid call that would cross a limit, and it does not negotiate the limit with the agent mid-message. The refusal is the whole mechanism.
5. No claim of certification. Nothing in the workspace is certified, accredited or compliant, and nothing about an assembly should be read as conferring a status on the client’s process. A role named for a standard is a job description, not a qualification.

Where it stops

There is no reference tenant yet. No client can be named, no testimonial quoted, no case study shown, and nothing on this site rests on one. What exists is a published bin, published prices, a stated mechanic and the arithmetic above. That is enough to evaluate a design and not enough to conclude that it worked for someone like you.

The parts are only as good as the source material. A Researcher reading three good documents will beat one reading thirty poor ones, and no amount of assembly changes that. The workspace retrieves and assembles; it does not know what the client’s corpus is worth.

A role is not a regulated professional. The ISO Auditor role assembles evidence against a clause set and notes what is missing — it does not certify anything, cannot certify anything, and the audit opinion remains a person’s to sign. The same holds for the Financial Analyst and the Trade Analyst: they read and assemble, and the decision, the advice and the liability stay with a human being who is accountable for them.

Per-call pricing suits spiky work and is worse for steady volume. A metered total falls to zero in a quiet month and a subscription does not. Above some steady volume the arithmetic inverts, and the subscription’s fixed price undercuts a total that keeps counting calls. The crossover depends on the subscription’s price and on how many calls the work actually needs, and this article will not invent either. The rule is to compare like with like: a month of real call counts against a real subscription quote, at which point the crossover stops being an argument and becomes two numbers.

Assemblability is not availability. Four services are sellable today and the rest are offline pending review. Thirteen roles are assemblable, and the number that can spend today is smaller.

How to start

Start with a job that can be marked wrong. A first output nobody can grade teaches nothing about the assembly; a first output that a colleague can read and correct does.

Describe the job in a paragraph, the way it would be described to a new member of staff: what arrives, what comes out, who reads it. Then take it into the design conversation and let the exchanges settle the role, the parts, the connections and the ceilings. Ten exchanges, one proposal, one person to approve it.

Fund the balance. 0.50 USDC on Base, to the client’s own wallet. It is the opening balance, not a fee: at the rate in Table 3 it covers about twenty-two requests, which is four and a half working days of the illustrative month and enough for a first job with room to correct it.

Then run one output end to end and read the record before reading the result. The record says what the job cost: which services, how many calls, at what price. A first job whose cost cannot be explained from the record is a design fault, and it is worth fixing while the workspace is still new.

Related

• what x402 is: the payment handshake and its failure modes — the technical pillar: the two-round payment handshake, the schemes, and where the standard fails.
• Service reviews, live: DeepSeek, Qwen, HyperFusion, SpiralStake.
• Service reviews, in build: Wolfram Alpha (in build), ElevenLabs (in build), Mage (in build).
• The catalogue, with every operation priced per chain: https://x402.press/catalog.json

Method note

Everything here comes from three sources, all read on 30 October 2026: the published parts and role pages on x402.press, the catalogue’s measured prices, and the stated mechanics of the workspace, the wallet and the three ceilings.

Two limits on that evidence. Table 3’s call counts are assumptions chosen to make the arithmetic visible; they are not observations, because no tenant exists to observe. And Table 2’s one-line descriptions of the thirteen roles are ours, written from the role names, because the gallery’s wording is the gallery’s to publish. Where the two could diverge — what a role costs — the role page’s parts and services lists are the authority, and we have not restated them here.

We have measured no tenant, no time saving and no percentage improvement, and no figure of that kind appears in this article.

Filed under Agents · Tags: x402, agentic-ai, custom-agents, per-call-billing

All seven reviews: the services reviewed

Running it: the float, the ceilings and the record