When Agents Started Working on Their Own: How Autonomy Hit the Hardware Ceiling

What Changed This Week

This week, agent autonomy within the Arcanada ecosystem advanced noticeably. The solution is assembled on the fly, but it works — and that was enough to change the infrastructure question entirely.

The mechanism is simple in concept, layered in execution. A senior terminal orchestrator (Claude running in a TMUX session on the development server) checks active tasks and the backlog, picks a task, and spins up a separate orchestrator for it. That orchestrator, in turn, opens one or more additional TMUX sessions, which run the task through the Datarim pipeline: initialization, product analysis, planning, technical design (architecture and interfaces), implementation, quality check, requirements verification, reflection, archiving. Inside each task, the entire pipeline is driven by a single command — /dr-auto. The upper layer, which parses the backlog and distributes tasks across sessions, is assembled by hand for now; a dedicated Datarim command for such orchestration does not yet exist and is still under development. When a lower terminal hits a question, the answer comes from the senior orchestrator, not from a human.

So development autonomy began operating on top of Datarim. Two things surfaced with it. The first, pleasant: far more tasks closed per hour and per day — the pipeline pulls them from backlog to archive with almost no human involvement. The second gave pause: infrastructure load rose manyfold. Every iteration, every pipeline step noticeably loads the server, and steps now run in several threads at once.

That raised a suspicion that the whole prior infrastructure plan was wrong. The question is not "how to save on servers," but "where does all this land in three months, and what infrastructure sustains such a pace." There is no commercial sale yet; products are still being built. But the load is no longer created by users — it is created by the agents building them. So infrastructure has to be thought about now.

Context and the Second Trigger: Prices and the Starting Point

Infrastructure at the moment of reorganization — four dedicated servers at Hetzner Robot (Helsinki) and fifteen cloud VMs. Total cost around €332 per month, or €3,987 per year.

A second reason to reconsider the hardware came from a Hetzner announcement: cloud prices rose by 30–37% from April 1, 2026, with a further increase scheduled for June 15. The cause is structural — a shortage of RAM and NVMe driven by demand from the AI industry. The announcement is not a one-off: more increases will follow. A detailed breakdown showed the opposite of intuition: the main cost item is not cloud VMs, but dedicated servers. They take the larger share of the budget — and that is where the headroom worth revisiting first was.

The moment for reorganization was chosen deliberately — before paying users appear. Moving servers, changing architecture, and migrating data under live load is an order of magnitude harder and riskier. While the system is small, the move is cheaper and safer.

What the Audit of the Servers Revealed

Before buying anything new, it pays to understand the old. On June 3, 2026, the agents ran a full investigation: they connected over API keys and SSH to all four dedicated servers and took measurements. The picture was paradoxical. The growing load came mostly from the development server, where the autonomous pipeline runs. The production machines, by contrast, were idle.

Three of the four servers (model AX41-NVMe at €36.70 per month each) were barely working. CPU load held in the low single digits, RAM nearly free as well. The servers were waiting not for load, but for something to be placed on them.

The fourth server, running production, looked different: the disk was nearly full. The first thought — the data had grown. But it did not add up: the services on that machine do not generate that much data. The cause turned out to be Docker build-cache and old images — technical debris from builds, not the result of work. The rest was simple: docker prune freed the disk, and nothing in production was affected.

The databases themselves turned out to be modest — all of them together would fit on a single flash drive. The audit picture: three servers idle, the fourth clogged with cache, and little actual data. Underutilization was massive. A convenient moment for reorganization: there is room to grow, but order has to come first.

Hetzner Server Auction: Mechanism, Pricing, and Hidden Traps

Hetzner Server Auction is a marketplace for "refurbished" servers: machines returned after rental or reassigned from other tasks. Billing is monthly, no minimum term, setup fee €0. Pricing is dynamic: it drops on a timer (the next_reduce field), so a favorable moment can be waited out.

A live list of servers is available in JSON, holding 217 machines at the time of research. The data carries everything needed: processors, memory, disks, error-correcting memory (ECC), location, and current price. That is enough to pick the right candidates automatically — without eyeballing web pages by hand.

The listed price, however, turned out to be a trap. It systematically understates the real cost. The same server — i9-13900, 3.84 TB ECC — showed €87.70 in FSN1 and €125.70 in HEL1. At checkout, the price rose. The gap between the "display" and the actual invoice reached €38 per month for identical hardware, purely by location. A mistake in choosing the site can cost hundreds of euros a year if only the listed price is trusted.

One more thing: the disk-capacity filter. If you select large capacities, always check what type of disk it is. A range like "3–16 TB" mostly surfaces machines with ordinary hard drives (HDD) — cheap, but slow. For databases, where access speed matters, they will not do: you need fast NVMe disks, not terabytes of slow space. Large capacity on its own says nothing about fitness — disk type matters more than size.

The Purchase: Two Servers, i9-9900K, 128 GB RAM, 2 TB NVMe

After analysis, two servers of identical configuration were chosen: Intel Core i9-9900K, 128 GB RAM, 2 TB NVMe.

The first — an application server in HEL1, next to production. Around €97 per month. Its job is to offload the current setup: take on AI services (the agent-council backend, speech recognition) and new modules due shortly.

The second — a database server in FSN1, around €84 per month. Storage under isolation: Postgres, Mongo, ClickHouse. The isolation is not only logical but physical — different products sit on different servers so their data never crosses.

Why 128 GB RAM over a larger disk, say 3.84 TB? The audit answers: the databases are tiny, they do not need the space. They need memory — so working sets sit entirely in RAM instead of hitting the disk. 128 GB is headroom for 2–3x growth without a performance hit. A 2 TB NVMe is fast and plenty for current volumes.

Economics: a Premium for Future Scale, Not Savings

The honest read is not cost-cutting, but an extra investment.

Decommissioning seven cloud VMs saves €48.93 per month. But the two new servers cost €180.94 per month. The net is +€132 per month. The reorganization does not make infrastructure cheaper — it makes it more expensive.

Why pay more before the first sale? Two reasons.

First — the price lock. Dedicated servers bought through the auction fix the cost at order time. It does not climb with cloud tariffs, and those have already risen 30–37% and will rise again. In a year, today's €464 may be cheaper than the cloud alternative with new markups.

Second — provisioning for scale. The move to hardware with headroom happens while the system is small and the move itself is cheap and reversible. Under load with paying users, shifting databases and services is many times harder, costlier, and riskier.

The reorganization is an investment in architecture for two-to-three-times growth, not a cut to current spending.

From "Infrastructure as Code" to "Infrastructure as the Agent's Service"

This case is not just about swapping servers. It illustrates a shift in how modern AI agents can manage infrastructure.

The old paradigm — "infrastructure as code" — assumes a declarative description of resources: a human writes the configuration upfront (in Terraform, say), listing what to create, and the system executes it. The agent here is the executor of a ready-made plan.

The new paradigm — "infrastructure as the agent's service" — swaps the roles. The agent does not execute someone else's plan; it builds the economically optimal one for the task. Through SSH access and keys it connects to live systems and reads metrics. In this case, exactly that happened: the auction list of 217 servers filtered by criteria; the gap between display price and checkout price caught; the difference between ordinary and fast disks accounted for; real database sizes measured to justify memory over surplus disk; the economics recalculated. Not the execution of a ready-made plan, but the plan itself.

The final action is controlled by the human. The purchase is made by the human — paid with their own card; access to secrets stays with them too. The agent carries the analysis to the decision point, lays out the breakdown, argues the choice. The human confirms or rejects.

This is the new level: IaaS 2.0, where the agent not only creates and deletes machines but picks the price-optimal option for a business task. Infrastructure stops being code and becomes the agent's service.

And here the story closes its loop. The question of new hardware was raised by agent autonomy — their work loaded the servers until the old architecture no longer fit. And the answer was found by an agent too: live data gathered, auction traps caught, real load measured, economics calculated up to the decision point. The agents that build products hit the hardware ceiling — and an agent found the hardware to clear it. The human is left to confirm the purchase and hold the keys to the secrets. For now, that is enough.

I would gladly use a service that picks hardware for a specific task like this — one that reads real metrics, runs the economics, and carries it to the decision point. If you have an idea for how to make such a service convenient, tell me — let's discuss it on Telegram.