Kcalbin has spent the past weeks building data agents and putting them on the Agent Commerce Protocol — twenty of them, each wrapping a real public data source. We now do that for other people. This post is the honest version of what that work consists of, because the marketing version is useless to anyone deciding whether to attempt it.
The short version: the part everyone budgets for is the part that takes the least time, and four distinct things stand between "my agent works" and "someone can buy from my agent."
Stage 1 — Building it is the easy half
An agent that answers one question well is a thin wrapper: take a request, call a data source, shape the response, state your coverage. If you have written an API client you can write an agent.
What actually varies is the data source. A clean, documented, generously-rate-limited REST API is an afternoon. A source with undocumented pagination, an auth flow that expires, patchy historical coverage, or licence terms that don't clearly permit resale is not an afternoon, and no amount of agent framework helps. Every one of our twenty agents was licence-checked before it was built rather than after — that ordering matters, because discovering the problem afterwards means throwing the work away.
Budget your time here, not in the agent logic.
Stage 2 — Registration is mechanical, and full of papercuts
Once a signer key exists, registering an agent is fast — the API call itself completes in about five seconds. We measured it five times in a row today: 4.67, 4.31, 5.34, 8.73 and 5.49 seconds. Knowing the sequence is what takes weeks; performing it takes minutes.
The friction is elsewhere, and it is mundane:
- The marketplace rate-limits agent creation to roughly two per 24 hours. If you are launching a portfolio, queue position is the scarce resource, not engineering time. Ours is still draining through that queue days later.
- Validation rules are not always in the docs. One of our agents failed
registration repeatedly and logged nothing more useful than "agent create failed." The real
cause, once we read the raw response, was
description must be longer than or equal to 10 characters— our registration driver was passing the agent's name as its description, and that agent's name is eight characters long. It could never have registered, at any hour, on any attempt. A one-line fix, invisible for three days.
The lesson worth stealing: log the raw error body, not your own summary of it. A generic "failed" message turned a five-minute validation bug into a multi-day mystery, and the information needed to solve it was in the response the whole time.
Stage 3 — Registered is not sellable, and this is where the honest number lives
This is the stage nobody talks about, so here is our own scoreboard, read off the live registry on the day of writing:
| State | Count | What it means |
|---|---|---|
| Agents built | 20 | Written, licence-checked, deployable |
| Fully live | 4 | Registered and offering visible to buyers and seller process running |
| Registered, no offering | 3 | Exists in the registry, but there is nothing to buy |
| Not yet registered | the rest | Queued behind the creation rate limit |
Four of twenty. We are not going to round that up. It is the number that tells you something true about this work: an agent can be registered, appear in the marketplace, and still be entirely unbuyable because its offering was never published or was published hidden.
One of ours entered exactly that state this week — the agent was created successfully, and the step that publishes its offering never ran. From the outside it looks registered. From a buyer's side there is nothing there. Nothing alerts on this by default, which is why we now define "live" as all three conditions at once, and compute it rather than type it: our agents page marks an agent Live only when it is registered, its offering is actually visible, and its seller process is running. It also now shows when that was last verified, so a reader can tell a check that ran minutes ago from one that last ran weeks ago.
Stage 4 — Taking money, and refusing to
There are two payment paths and they are independent: agent-to-agent through ACP, in USDC from an agent's wallet, and a direct card checkout for human buyers. Both need building. The human path is the one that catches people out — webhook signature verification over the exact request bytes, live-mode keys, and a decision about what happens when someone tries to buy something that isn't really ready.
We made that last decision the unusual way. Our checkout refuses sales for agents whose underlying data source is a shared demo key or a throttled free tier, and states the reason in the refusal:
checkout REFUSED (live hold) asia-equity runs on Twelve Data's DEMO key — only a small
sample of symbols resolves
Four of our own agents are held back by that rule right now. It costs us sales we could technically process. We keep it because a buyer who pays for data and receives a rate-limited partial answer does not come back, and does not need to — they simply tell other people. The refusal is cheaper than the reputation.
If you build this yourself, decide the rule before you are tempted. It is much harder to introduce a refusal path after money has started arriving.
Stage 5 — Keeping it alive is the recurring cost, and it is not glamorous
Here is a real failure from this week, in full, because it is more instructive than any architecture diagram.
Our command-line tool stores its marketplace auth token in the Linux kernel keyring. Kernel keyrings are not permanent storage: this machine expires them on a fixed timer, which you can read directly.
/proc/sys/kernel/keys/persistent_keyring_expiry → 259200 seconds.
Exactly three days.
So the credential was always going to die on a schedule, and it did — mid-afternoon, somewhere
in the hour between a call that succeeded and the next one that returned KeyRevoked.
Everything depending on that token was dead from that moment: the job that keeps the catalogue's
status column honest, and the queue registering the remaining agents. One agent was left
half-registered in the crossfire — created seconds before the expiry, with the step that publishes
its offering never reached.
The genuinely bad part was not the expiry. It was that the failure was silent. The status job failed correctly — it changed nothing rather than rewriting the public page to "everything is launching" — but it announced that only into a log file nobody reads. The page kept serving. Nothing looked wrong. It was found by accident.
Three fixes, in order of importance:
- Move the credential to storage that persists. The tool supported an encrypted file store the whole time and never used it, because its automatic fallback checked for four specific error types and the one we hit was not among them. Pinned to the file store, it now survives reboots, session end, and the three-day timer.
- Make failure reach a human. The job now sends a message when it cannot verify state. Failing closed is correct; failing closed and silent is how a system rots politely.
- Publish the verification time. A page that claims to report live state should say when it last succeeded in checking. Otherwise "live" is an assertion, not a fact.
None of that is exotic. All of it is the actual content of "managed hosting" — and none of it exists until someone has been bitten once.
What we are not claiming
The Agent Commerce Protocol is young and the population of AI agents that autonomously buy things is still small. We can show that the pipeline works end to end, because it is running. We cannot show you a revenue chart, and we are not going to imply one: at the time of writing, Kcalbin has not completed a sale through the agent marketplace. The infrastructure is proven. The demand is not, for us or for anyone claiming otherwise.
That is worth saying plainly, because the honest reason to do this now is positioning — being present and working in a market before it is contested — not near-term revenue. If someone tells you they can forecast agent-commerce demand in 2026, they are guessing, and you should price their other claims accordingly.
If you want this done rather than learned
Everything above is reproducible. The information is public, the protocol is open, and a capable engineer will get there — the cost is the three days lost to an eight-character description, the queue you didn't know was rate-limited, and the credential that silently expires on a timer you had no reason to know about.
We have already paid those costs. We now build, register, verify, sell and host agents for other people — flat build pricing plus monthly hosting, no revenue share, and you own the agent, the Stripe account and the registration. The catalogue of what we run for ourselves is public, including the parts that are not live yet.
Agent build & operate — pricing See the agents we run
Figures in this post were read from Kcalbin's own systems on 14 August 2026 and will move as agents are registered and offerings published. The Agent Commerce Protocol is published by Virtuals Protocol; Kcalbin is not affiliated with it.