Last year, a client asked me to set up an automated technical watch. The need looked simple: monitor about thirty RSS feeds, filter the noise, group articles by theme, summarize the relevant ones, send a mail every morning. The kind of task you gladly hand to an intern, except there was no intern.

I started by looking at what existed. The SaaS watch tools did the job, but badly: rigid filters, no classification by business theme, generic summaries. Homegrown scripts piled up fast, and nobody knew what was running or why it failed yesterday. And then there were the autonomous agents, OpenClaw, Hermes Agent, and the whole wave that promises to delegate work to an LLM that decides, acts, learns. I looked, I read the security incidents documented at Cisco, and I saw an agent that, in theory, could send a mail to a client without anyone validating it, simply because the LLM had judged it was the right action.

This is not a tuning problem, it is a philosophy problem. An agent that decides its actions on its own is not a tool I can audit, replay or interrupt with confidence: it is a black box that burns tokens at every loop, whose decisions are not reproducible, and whose attack surface grows with every skill you add. For personal or experimental use, I understand the appeal, but for a scheduled business pipeline that runs every hour, sends mails and touches client data, it makes no sense.

So I built something else, but not an autonomous agent. A supervised agent: a scheduled worker that executes a deterministic plan, where the LLM steps in only where it is useful (classify, summarize, draft), and where everything else, fetch, dedup, routing, delivery, is explicit, traceable, replayable code.

This post explains why I made that choice, which problems it solves and what it changes concretely. It is the first of a three-part series: the second will compare approaches (all-in-one platform, framework, custom build), and the third will detail the implementation.

Defining a “supervised agent”

The term “supervised agent” is deliberately in tension with the established phrase “autonomous agent”. In the industry, an autonomous agent is a system driven by an LLM that, at every iteration, decides the next action, picks a tool, interprets the result, starts over. The loop is at the center, the code is at the margin. A supervised agent reverses the ratio: the code is at the center, the LLM is at the margin, and there is no loop.

Concretely, a supervised agent is a scheduled worker that runs without human intervention on a trigger (a cron, an event, a manual start), but follows a deterministic plan written in code, not a plan improvised by a model. The LLM is invoked only at explicit extension points (extraction, summary, classification), with a strict output schema that bounds what it can return. Every execution is traced: inputs, outputs and decisions are timestamped and auditable. A human can interrupt, replay and audit any execution. “Autonomous” here means “runs unsupervised on a schedule”, not “decides its actions on its own at runtime”.

This definition rests on four pillars that guide the rest of the series and that I will reuse in the following posts.

Determinism: the pipeline is an explicit sequence of Steps, and the execution order does not depend on a model. The LLM produces content inside a Step, it does not pick the next Step.

Control: a human can interrupt a running execution, restart it, replay it, inspect every step. Risky actions (send a mail, reply to a client) are framed by explicit rules, not by a probabilistic judgment.

Auditability: every run traces and persists its inputs, outputs and metadata. A decision taken three months ago can be found, understood and, if needed, corrected.

Token efficiency: because LLM calls are targeted and non-conversational, token consumption is predictable and bounded. Every extension point can use the model best suited to its task, a cheap model to classify, a stronger model to synthesize, rather than a single model for everything.

A supervised agent pipeline looks like this:

flowchart LR
    A[fetch] --> B[dedupe]
    B --> C[classify<br/>LLM Step]
    C --> D[summarize<br/>LLM Step]
    D --> E[deliver]

The Steps marked “LLM Step” invoke an LLM with a strict output schema and consumption limits. The other Steps are deterministic code: HTTP fetch, dedup, mail delivery, database writes. The LLM never has a say on the flow, only on the content of a specific Step. That asymmetry is what changes everything else: control goes back to the code, intelligence stays with the model, and the boundary between the two is readable in the pipeline itself.

The problems autonomy does not solve

The argument for autonomy is seductive because it shifts the load: you stop writing logic, you delegate it to the model. In practice, that shift does not make the problems disappear, it makes them opaque. Four of them come back systematically as soon as a full-LLM agent touches a scheduled business process.

Cost

An autonomous agent runs in a loop: the model is called, it picks an action, it runs the action, it feeds the result back to the model, which picks the next one. Every iteration consumes input and output tokens, and the context length grows with every turn. Consumption is not bounded by construction: it depends on the number of iterations, the verbosity of the model, the back-and-forths needed to reach a terminal state. On an hourly cron, the bill becomes an uncontrolled parameter of the system, not a predictable cost.

A supervised agent, by contrast, calls the LLM at fixed extension points, with a bounded prompt and a strict output schema. Consumption is computed per Step, budgeted per run, and capped by explicit limits. The same pipeline run today and in six months consumes the same order of magnitude of tokens, because the structure does not change. This is not an optimization, it is an architectural property.

Security

This is where the gap becomes qualitative, not quantitative. An autonomous agent gives the LLM control of actions, therefore the ability to act on the real world: call APIs, write to a database, send messages, run code. Its attack surface grows with every skill you add, because every skill is a new potentially abusable capability.

The documented incidents are not theoretical. Research published by Cisco on OpenClaw security surfaced prompt injection and data exfiltration vectors via third-party skills. A project maintainer himself said the tool was too dangerous for a user who cannot run a command line. The Chinese government banned OpenClaw from banks, state-owned enterprises and agencies in March 2026. None of these signals is anecdotal: they all point to the same cause, namely that an agent that decides its actions on its own is, by construction, an agent you cannot constrain a priori.

A supervised agent radically separates decision from action. The LLM produces content (a category, a summary, a draft), and that content goes through a deterministic layer before triggering anything. Risky actions are protected by human rules, not by a model judgment. You can add a guardrail without touching the prompt, because the guardrail lives in the code, not in the instruction. Prompt injection does not vanish, but its blast radius shrinks: the model can produce whatever it wants, the code around it decides what happens next.

Trust

A full-LLM agent is hard to audit because its behavior emerges from the interaction between a prompt, a model, a context and a series of probabilistic decisions. Two identical runs can produce two different results. When something goes wrong, the question “why did it do that?” has no deterministic answer, only a probabilistic explanation reconstructed after the fact.

A supervised agent produces, on every execution, a timestamped trace that records the input, output and metadata of every Step. Runs are replayable: you can resume a failed execution, inspect the faulty Step, fix it, relaunch. LLM Steps are marked as such in the trace, with their model, their tokens and their latency, which makes the probabilistic part visible and localized rather than diffuse. Trust does not rest on an intuition of reliability, it rests on the ability to find, understand and fix.

Compliance

For a business process that touches client data, automated decisions or external communications, reproducibility is not a comfort, it is a regulatory requirement. An audit can ask, for a decision taken on a given date, to retrace the inputs, the reasoning and the output. With a full-LLM agent, the original decision is not reproducible: the model has evolved, the context has changed, and the same input would not necessarily produce the same output. The run is a one-off event, not replayable.

The determinism of a supervised agent makes reproducibility possible, because the pipeline structure does not change between two executions and every Step is designed to be idempotent. For an auditor, the trace of a run is a file: timestamped inputs, ordered Steps, persisted outputs, localized decisions. The LLM part stays probabilistic, but it is circumscribed, identified and bounded, and its impact on the final decision is mechanically auditable.

argentic-mw as an incarnation

The platform I am building, argentic-mw, is an incarnation of that philosophy. It does not invent it, it applies it to three concrete business agents that share a common Core. The point is not to detail the implementation here, that is the subject of the third post, but to show how the four pillars materialize in a real system rather than in an abstract manifesto.

Three agents make up the current scope. The Watch Agent does technical watch: it pulls RSS and Atom feeds, deduplicates new articles, classifies them by theme, summarizes them and delivers them by mail with persistence. The Web Stats Agent collects statistics from Plausible and Google Search Console, aggregates, compares against reference sites, recommends improvements, suggests new references, and delivers in turn. The Zendesk Tickets Agent pulls new tickets, classifies each ticket, determines a response mode via a rule table, routes to support or presales, and either sends an automatic reply or produces a draft for human validation.

The three share the same Core, which runs the pipeline as a simple loop over a list of Steps. It is deliberately trivial: no orchestration framework, no workflow engine, no implicit graph. The readability of the Core is the condition for determinism, because an executor you do not understand cannot be audited.

Determinism is readable in every agent’s pipeline: the order of Steps is fixed by code, the LLM never picks the next step. In the Zendesk Agent, the decision to reply automatically or to produce a draft is never taken by the LLM: it classifies the ticket, and a human-edited rule table maps every category to a response mode. Adding a new auto-reply case means adding a row in a table and a template file, not editing a prompt. Precision comes from classification, which is where natural language needs to be understood; the decision comes from the rule, which is where determinism is required.

Control materializes through the guardrails around risky actions. Automatic reply to the client is the most dangerous action in the system, so the most guarded: a double signal (regex and LLM category), a global kill switch, rate caps per run and per agent, a confidence threshold below which you fall back to draft, an audit log, a dedup. Every one of these guardrails lives in the code, not in the instruction, and none depends on the model’s good will.

Auditability comes from per-Step tracing and the replay cache. Every Step traces its input, output and metadata; LLM Steps add a usage block with the model, tokens and latency. Runs are replayable because every Step is designed idempotent and the cache lets you skip already-executed Steps without doubling side effects.

Token efficiency comes from the fact that every LLM Step has its own configuration: a model, consumption limits, a prompt editable without redeployment. Ticket classification uses a cheap model, draft writing a stronger model, statistics comparison an intermediate model. The platform does not pay for an expensive model on a trivial task, and does not under-equip a hard task with a cheap model. The model choice is local to the Step, not global to the platform.

The scheduler, finally, is designed active-passive with leader election via Postgres: several instances run, only one is active, and handoff happens automatically when the lease expires. Workers are stateless, all state lives in the database, and capacity is added by adding a worker on a new node. This is classic platform engineering, not AI, and that is precisely the point.

What it is not

The argument would be incomplete without saying what it is not, because the line between taking a position and dogma is easy to cross.

This is not a critique of generative AI. The LLM is central in a supervised agent, and it does things deterministic code cannot do: understand a ticket written in natural language, summarize an article, draft a reply, compare statistical series and propose an interpretation. The question is not whether the LLM is useful, it is! The question is where it intervenes in the system, and that is where the choice plays out. An LLM in its place, constrained by an output schema and surrounded by code, is a reliable component. An LLM everywhere, in charge of the flow and the actions, is a component you lose control of.

This is not a rejection of autonomy in general. Autonomy has legitimate use cases, and I do not claim they disappear. Open research, exploration of a solution space, a personal agent that learns a user’s preferences, rapid prototyping where you accept non-determinism to move fast, are contexts where the LLM-driven loop makes sense. OpenClaw and Hermes Agent serve those uses, and they have their audience. My point concerns another class of needs: scheduled business pipelines, running in production, touching data and clients, for which audit, control and bounded cost are not optional. The selection criterion is not “autonomous or not”, it is “what are the consequences of a wrong decision, and who assumes them”.

It is also not a universal solution. argentic-mw answers a family of needs, not all of them. Supervised agents excel on linear pipelines with ordered Steps, where LLM extension points are identifiable in advance and where risky actions are named. They assume you can describe the process, that you accept writing it in code, and that you want to control it. For workflows where structure emerges at runtime, where possible actions cannot be enumerated in advance, or where the value is precisely in adaptation, the supervised model is a poor fit, and that is not a defect to fix, it is a boundary.

Conclusion

Determinism is not a renunciation, it is a choice of control. Giving up on the LLM deciding the flow on its own means accepting to write it in code, and that is precisely what makes the system auditable, replayable, bounded and defensible. The LLM keeps its full place, but in its place: producing content inside a Step, not deciding the sequence. That asymmetry is the point, and it declines into four concrete properties, determinism, control, auditability and token efficiency, which are not slogans but properties verifiable on a trace.

This post is the first of a three-part series. The second will compare approaches: should you adopt an all-in-one full-LLM platform like OpenClaw, build on a framework like LangGraph or Dify, or build a custom core? I will propose a six-criterion decision framework there, so the answer depends on context rather than bias (see When to choose an all-in-one LLM platform, when to build custom). The third will close the loop on implementation: how argentic-mw concretely runs its three agents, from the common Core to the business pipelines, with the detail of Steps, guardrails and the scheduler (see From manifesto to code: how argentic-mw runs its agents).