What an agent system costs to maintain: 134 days measured

What does an agent system cost to maintain?

Maintaining an agent system costs you roughly one look a day and one clean-up a week, and the bill arrives in attention rather than in euros. That is not an estimate. We have been running our own agent system without interruption since March 2026 to help run our agency, and that system logs everything it does to a single database. On 16 September 2026 it held 44 thousand events, collected over 170 days. Scheduled tasks have been tracked separately since 5 May, which gives us 134 days of run data.

Here is what those numbers say, in one paragraph. Of 1065 scheduled runs, 803 finished and 241 did not. So just over three in four succeed. Of those 241 failures, almost a third was not a malfunction at all but our own quality gate refusing the output. On 54 out of every 100 days something needed attention. And the single most common error in the whole logbook, good for 492 lines, is not a defect but an exhausted credit balance at an outside service.

That is the honest version. Not "AI automation is amazing" and not "it does not work". Below is the full measurement, including what you cannot get out of it. If you are weighing up automating something that goes beyond a tool subscription, this is the maintenance bill you want to see up front. If you first want to know how to pick a supplier, read how to separate the real AI providers from the rest.

What exactly we measured, and what the logbook does not know

The system is called Milo. It runs on one machine at our office, starts tasks on a fixed schedule, and writes every start, every ending and every error to a SQLite database. There is no measurement rig built around it for the sake of this article. We pointed the questions at an existing logbook after the fact, and that is precisely why the numbers are usable: nobody could make them look better while they were being created.

There are four things this logbook cannot tell you, and we will name them first.

There are no euros in it. We measure compute time, not spending. There is no cost log, so any amount in this article would be invented. This piece is therefore about time and attention.

It is one system, not a benchmark. Different setup, different tasks, different numbers. What transfers here are the ratios between kinds of tasks, not the absolute figures.

Two counters are broken and we do not use them. The logbook holds 5825 session endings against 122 session starts. That is an artefact of how the writing works, not a restart counter. Build an availability claim on that and you build on sand.

The correction table stops in May. There is a table recording when a human corrected the system, and it runs from 30 March to 11 May and then stops. 24 rows. Too few and too old to say how often someone intervened. So we leave that number out rather than estimate it.

One more thing: 1065 runs started, 803 ended well, 241 ended badly. Those three do not add up. 21 runs never wrote an ending at all, which means the machine or the process underneath fell away before anything could be logged. Every percentage below is calculated over the 1044 runs that did record an ending.

One in four scheduled runs does not finish

The headline numbers fit in one table.

Seventy-three percent, eighty percent, seventy-seven percent: for your planning it does not matter which of those is exactly right. What matters is that the fourth attempt behaves structurally differently from the first three. So you do not build a chain where step four waits on step three, unless you also build what happens when step three disappears.

We solved that in one way that visibly pays off: a task that fails automatically gets a second attempt. In this period, 24 runs only succeeded on that retry. Those are 24 tasks that would otherwise have quietly vanished, without an error anyone would notice, because a task that does not run makes no sound. That retry is the cheapest piece of engineering in the entire system and it returns the most.

Where things go wrong, they rarely go wrong spectacularly. Not a single run destroyed data or pushed something incorrect out into the world. The failures are boring: something hung, something took too long, something was missing on the machine. That is good news, and it is also exactly why the error list is so easy to ignore.

Almost a third of all failures is the system stopping itself

This is the number that surprised us most. "Failed" is not a category but a bucket, and when you open it there is something inside you do not want to count as failure.

76 of the 241 failures, almost a third, is the system refusing its own work. That is not a malfunction, that is the design. For every kind of output that can reach the outside world there is a gate in between checking whether it holds up: is there a source behind every number, is there an English version, is the tone right, are there placeholders left. If it does not get through, the run enters the logbook as failed.

Measured more broadly, across all tasks rather than only failed runs, that gate stopped something 371 times in this period, spread across 205 different tasks. The same piece of work is judged again on a fresh attempt, so you cannot add those two numbers together. 205 unique blocked tasks is the figure that holds. Two hundred and five times there was work ready that would simply have gone out without a gate.

If you take one thing from this article, make it this: build the brake before you build the engine. In a tally, a quality gate looks like a source of failures. In practice it is the only component that stops a system from driving the wrong way at speed. Anthropic writes the same thing in its own guide to building agents, in different words: the most successful implementations use simple, composable patterns rather than complex self-directing constructions. Simple and inspectable beats clever and opaque.

Why writing hits 97 percent and publishing hits 29

The most interesting pattern in the measurement is not the average but the spread. Broken down per task, the success rate runs from 97 to 29, and that order is no accident.

At the top sit the tasks that make something. Writing, researching, summarising: all of it happens inside the machine, with text as the raw material and text as the result. There is no third party halfway through that can say no.

At the bottom sit the tasks that need the outside world. Network growth leans on a logged-in session that expires. Signals on X lean on a service whose credit has run out. Publishing has to pass a run of checks, a git push and an external build step, and any link in that chain can drop the whole thing.

That gap is not about technology, it is about who holds the key. A language model writing a text needs nobody. A task that puts something on a platform depends on a session, a balance, a price and somebody else's decision. So anyone starting an automation project should not look at what is most exciting to automate, but at where the key sits.

There is a caveat to this table and it belongs in it. The sample sizes vary wildly. Writing content has 100 runs behind it, the validation round has 17. The bottom of this table is an indication, not a conclusion. The top, with 100 and 152 runs, is one.

And then the nuance that makes publishing less bad than 29 percent suggests: of the 27 failed publishing runs, 21 were the gate itself holding the publication back. So that is not a broken machine but a strict check on the step where a mistake is most expensive. Our publishing wrapper aborted 111 times in this period across 86 different articles, usually because a number had no source or an English version was missing. That is exactly what it exists for, and it is the same discipline we describe in tracing brand statistics back to the source.

What breaks, and above all how long it stays broken

Now the error messages. There are 791 in the logbook. That sounds like a system on fire. It is something else: a handful of causes that keep beeping for months.

Two things stand out. First: 552 of the 791 error messages, seventy percent, come from one task. A radar that collects replies to our own posts. That task keeps calling a service we have known for months is shut.

Second: the biggest "failure" is not a defect at all. The balance at one of the platforms we published on has run out, and that is a subscription matter. Nothing is broken. But the task calling it is still in the schedule, so for three months it has been shouting every hour that something did not work. The last message came in this morning, three months after the first.

That is the lesson worth the most and the one you will not read in any sales deck: the error list gets polluted, and the real problem disappears into that pollution. Sixty-six percent of all messages come from one parked cause. Seventy percent comes from one task. Anyone alarming on counts is alarming on noise. Worse: anyone who sees the same message for three months and does nothing teaches themselves to ignore the whole list. And then you miss the message that does matter.

Look at the lifespan column too. The missing program was fixed in eight days, because it blocked visible work straight away. Message delivery has been beeping since 2 May, because it fails rarely and without consequence. The maintenance burden is not in the big failures. Those disappear fast, because they hurt. The burden sits in the small things that force nobody to act.

What it costs in attention

This is the part most business owners are looking for: how much of your week does this take?

On 61 of the 133 measured days nothing went wrong. On the other 72 it did. Rounded: on 54 out of every 100 days the system asks for attention. That is the honest price and it is the best antidote to the sales pitch. This is not a device you switch on and forget.

At the same time, attention is not the same as work. Most of those 72 days did not cost half a day but a two-minute glance at a list, ending in "that is the familiar one, see you tomorrow". The real work sits in the days where you decide to clear one of those familiar causes for good, and there are a few of those a month.

The compute time says something different: 119 hours of machine time over 681 runs, with a median of just under nine minutes per run. That is time the system spent on your work while you were doing something else. Against that, in the same period it recorded 359 pieces of content, processed 2128 tasks and gave 563 risky actions an audit trail. The ratio between those two columns, machine hours against your minutes, is the entire business case. Not a percentage in a brochure.

What this means for a company that still has to start

First the environment, because it matters more than most people think. The share of companies using AI doubled in two years, and 35% of AI-using companies now apply it to marketing or sales. That is the largest application area. More interesting is the other side of the same survey: of the companies that considered AI and decided against it, 73% name lack of experience as the main reason. Not cost. Not technology. Experience.

That is exactly why an article like this exists. What business owners are missing is not a tool but a picture of what it looks like when it runs. One caveat belongs here and the statistics office states it itself: the 2026 figures only become available in December 2026, so this is data about 2025.

Concretely, translated to a company of five to fifty people:

Start with what stays in-house. Texts, summaries, research, sorting your inbox. That is the side of the table where 97 and 82 percent sit. The temptation is to start with the most visible piece, usually publishing or advertising, and that is the side where 29 sits.

Build the refusal before you build the output. What absolutely must not go out? Write that down as a check that can stop the output, and build it before the task that produces the output. Our gate blocked 205 pieces of work. Without it, those were 205 things that would have reached clients.

Put an expiry date on every error message. If the same message is still there in two weeks, it does not belong on the list any more. Then it is a decision you have to make, not a fault you have to see. We looked at the same message three months too long ourselves, so this advice comes out of our own failure.

Count in attention, not in hours. The question is not "how much time does this save". The question is "who looks at it every morning, and what does that person do when something is red". If there is no answer to the second question, the system is not finished, however well it works.

A practical way to grasp this without building anything yourself: look at how agents already walk past your brand. We describe that in brand positioning in a world of AI agents and in what agents.md does on a Shopify store.

How we use this at Oase Creative

We are a brand agency in Arnhem, not a software company. Milo exists because we had the same problem as our clients: too much execution work, too few hands, and no appetite for a team that only pushes buttons. In six years we have delivered hundreds of brands, and the pattern is always the same: the thinking is scarce and the doing is endless.

What we learned from this and carry into client work comes down to three rules.

A human on quality control, always. The creative concept comes from a person. A system executes and sharpens. We do not reverse that order, and the numbers above are exactly why: a system running at 77 percent needs someone who sees the other 23 percent.

Automate the repetition, not the decision. Anything that is the same every week can go. Anything containing a judgement stays with a person. The difference between the two is usually clear within ten minutes and it saves months.

Show the logbook. We show clients what runs, what failed and what was blocked. It feels exposed and it works better than a presentation, because it is the only proof that something is actually running. If you are considering a supplier: ask for the logbook. Anyone without one has a demo, not a system.

If you want to know what is worth automating in your case without picking up a second job, look at our services or simply get in touch. We regularly say something is not worth it, and that is usually the most useful answer. For the store side, the broader explanation sits in AI in your store and the last 20 percent and in agentic commerce on Shopify. To make it measurable: how to measure AI referrals in GA4.

What an agent system costs to maintain, in four numbers

Not as a closing summary but as the four numbers you take into a conversation with a supplier.

77. The share of scheduled tasks that finish, in a system that has been running for months with someone looking at it daily. If somebody promises you more than ninety, ask for their logbook.

76 out of 241. The share of failures made up of the system stopping itself. If a supplier has no number at all for "how often did your system refuse its own work", they do not have that gate.

97 against 29. The gap between a task that needs nothing from outside and a task that does. This is the number that decides where you start.

54 out of 100. The share of days on which the system asks for attention. This is the line item that appears in no quote and that you have to schedule yourself.

Know that before you start and you build something that keeps running. Miss it and you build something that spends three months shouting into an empty room. For a technical introduction to how agents carry out their tasks and where the control belongs, the documentation on tool use is a good first step, and our explanation of AI branding as a brand system goes further.

Frequently asked questions

How much time does maintaining an agent system take? In our own logbook, something needed attention on 54 out of every 100 days. That is not a full-time job, but it is not zero either. Budget five to ten minutes a day scanning the error list, plus half an hour a week clearing the causes that keep coming back.

How often does a scheduled AI task actually fail? Of 1065 scheduled runs, 803 finished and 241 did not. Of those 241, 76 were the quality gate refusing the output, 90 were a process that hung and 67 were a time limit being exceeded.

Which tasks should you automate first? The ones that need nothing from a third party. Writing hits 97 percent for us, research 82 percent, publishing 29 percent. That gap is not about technology, it is about who holds the key.

Is an agent system something you switch on and forget? No. In this period our system produced 791 error messages, of which 552 came from one task and 492 from one known cause open since 16 June. The upkeep sits in clearing that noise, not in the build.

How many Dutch companies actually use AI? One in six companies used AI in 2025, double the share of two years earlier. Of those users, 35% apply it to marketing or sales, and companies that backed out name lack of experience as the main reason.