Votemap (votemap.eu) is an analytics platform dedicated to European Parliament voting records. It runs Mastodon, PeerTube, and a custom multilingual application on our cluster. This is a large enough system that proposing an agent to watch it was a reasonable technical exercise, not a theoretical thought experiment. The initial brief outlined four specific tasks for this proposed agent: watching that the pods were running, triggering a redeploy, watching data freshness, and reporting incidents.
Itemising that scope dissolved the agent. Every task on the list turned out to have a cheaper answer that was already running, and what remained were three alerts. We are a company that sells AI, and this is a piece about a place where we did not use it. That is worth writing down, because the decision not to build something leaves no artefact behind and therefore tends to go unrecorded.
Itemising the scope
The first task was to watch the health of the pods. The brief assumed that an agent would be required to constantly monitor the operational status of the containers. While this was a plausible requirement, the function is already measured by kube-state-metrics. An agent would have added a layer of interpretation on top of this raw data, which was unnecessary overhead.
The second task concerned data freshness. The requirement was that the agent should monitor the timeliness of the data ingested into the platform. This condition, however, can be expressed and monitored using a standard alerting rule. An agent would have been asked to interpret the alert, adding complexity where simple threshold checking was sufficient.
The third task involved triggering a redeploy. The brief suggested the agent should initiate a redeployment when certain conditions were met. This action is already handled by a scheduled pipeline. An agent would have been tasked with deciding when the pipeline should run, adding a decision layer that was not required.
The final task was incident reporting. The brief stipulated that the agent should report incidents when they occurred. This functionality is already routed by a webhook mechanism. An agent would have been responsible for formatting and transmitting the report, adding a layer of abstraction over an existing, reliable communication channel.
When these four tasks were itemised, the proposed agent was left with nothing. What remained were three distinct, manageable alerts.
Why a rule beats an agent
A rule is a deterministic piece of logic that executes when a specific condition is met. It is not a system that interprets intent, and it does not attempt to work out what you meant. Rules are designed to operate on clear inputs and produce predictable outputs.
Rules are cheaper to implement than agents, because they require only defined logic rather than complex, general-purpose reasoning. They do not hallucinate, meaning their output is always traceable back to the input data. They cannot be talked out of it with a prompt, ensuring predictable behaviour regardless of conversational context. Furthermore, their failures are visible, providing clear points of failure that are easy to diagnose.
This is not an argument against the use of agents in complex systems. Rather, it is an argument about where the boundary sits between necessary automation and over-engineered complexity.
The mistake was one step earlier
The initial scope for the agent was copied from a brief written elsewhere. It read plausibly and contained all the necessary technical jargon to appear complete. This initial plausibility is often the most misleading aspect of technical planning.
A scope inherited from someone else's brief is a premise, not a fact. The technical challenge was not solving how to constrain the agent, but rather determining whether the agent should exist at all. Focusing on the implementation details before validating the core premise is a common pitfall.
Checking the premise cost only one pass through the list of requirements, item by item. This simple validation step proved to be the cheapest step in the entire exercise and successfully removed the entire project.
When an agent does earn its place
An agent earns its place where the work is gathering and writing up, spread across systems that do not share a technology stack, and where the useful output is a summary a person reads and acts on. Watching is not that work: a metric crossing a threshold is a rule's job and always will be. The distinction is between noticing a condition, which a rule does better, and assembling a picture out of things that live in five different places, which a rule cannot do at all.
An agent is not required when a single condition can be expressed as a simple threshold. Monitoring watches the machines, the agent writes up what it gathered, and a person decides what to do about it. For more detail on this distinction, read how a small team runs many systems.
Questions and answers
Do I need an AI agent for monitoring?
Not necessarily. You should first ask if the monitoring task can be defined by a simple threshold or a scheduled check. If the requirement is simply to check if X is greater than Y, a rule is the correct tool.
When is an alert better than an agent?
An alert is better when the required action is binary and immediate, such as a service falling below a defined performance metric. An agent is needed when the required action is a summary of disparate events that requires human judgement to triage.
How do you decide whether to build an agent at all?
Itemise the scope before you design anything, and for each item ask what already covers it. If every line has a cheaper answer that is already running, there is no agent left to build. What survives that pass is the actual scope, and it is usually much smaller than the brief.
Before building any agent, the most critical question to ask is: which parts of this scope cannot be written as a rule?