When I started laying out argentic-mw, I did what every engineer does before writing a line: look at what existed. I installed OpenClaw, I read Hermes Agent’s docs, I dug through repos, I ran scenarios by hand. Both projects are impressive and massively adopted, and I understand why: OpenClaw claims nearly 384,000 stars on GitHub, Hermes Agent sits around 218,000, and both promise a personal assistant that decides, acts and learns without intervention. It is seductive on paper and still seductive in use for a number of cases. For argentic-mw, it broke almost immediately, and not for reasons of model quality.

What broke was the philosophy of control. I needed to send a watch mail every morning at a precise time, to reply to a Zendesk ticket under editable business rules, to compare web statistics against reference sites. None of these tasks asked an LLM to pick the next action. They asked an LLM to classify, to summarize, to draft, all inside a plan fixed by code. The supervised philosophy, laid out in the first post’s manifesto, assumes precisely that the code drives and the LLM produces content at extension points. Full-LLM platforms assume the opposite, and that is a mismatch no amount of configuration fixes.

That said, “build or buy” is a fake binary. There are at least three axes: adopt an all-in-one full-LLM agent, build on an orchestration framework, or build a custom core. The point of this post is to give a framework to choose, not to plead for any of them.

The framework: six decision criteria

To compare approaches that do not share the same goal, you need common ground. I use six, chosen because they separate supervised agents from the others rather than because they flatter one approach. None is sufficient alone, and none ranks the options sharply: they draw a profile.

Determinism is the first, and the most structuring. The question is simple: who controls the execution flow, the code or the LLM? In a supervised agent, the order of Steps is written in code and does not depend on a model decision. In a full-LLM agent, the model picks the next action at every iteration. A framework like LangGraph leaves both open, since you can write a deterministic graph or delegate branches to the model. The criterion is not “deterministic or not”, it is “where does the flow decision live, and can you read it in the code?”.

Auditability is the second. Can you retrace and replay every decision of a run? A supervised agent traces every Step, timestamps its inputs and outputs, and persists those traces so a human can examine them months later. A full-LLM agent produces probabilistic decisions that do not replay identically, and whose path is reconstructed after the fact. The concrete question is: for a dated decision, can I find the inputs, the reasoning and the output, and re-execute the run? The answer cleanly separates the approaches.

Token cost is the third. A full-LLM agent runs in a loop: every iteration consumes input and output tokens, and the context length grows as you go. Consumption is not bounded by construction, it depends on the number of iterations and the model’s verbosity. A supervised agent calls the LLM at fixed extension points, with a bounded prompt and a strict output schema. The bill is computed per Step and capped per run. The criterion is: is consumption an architectural property or an uncontrolled parameter?

Multi-tenancy is the fourth, and often underestimated. Can several teams configure instances of the same agent with different parameters, prompts, models and recipients, without redeploying code? A supervised agent distinguishes an agent type (the pipeline definition) from an instance (its configuration), which lets you deploy a watch for the sales team and a watch for the engineering team without touching code. Full-LLM platforms generally reason in terms of personal agent, not configurable instance.

Prompt control is the fifth. Are prompts editable without redeployment, versioned, and separated from the code? In a supervised agent, every LLM Step carries its own configuration (model, consumption limits, system prompt) stored in the database, editable via the control plane. On the full-LLM side, the prompt is often tangled with the orchestration logic and the system instruction files, and editing it without breaking behavior assumes a fine understanding of the runtime.

Lock-in is the sixth. What is the dependency on a runtime, a license, an ecosystem? A full-LLM platform ties the agent to its runtime, its skills, its registry. A framework ties the code to its abstractions, but it is still code you own. A custom core ties you to your own code, which you maintain. The criterion is: if I want to leave tomorrow, what do I take with me, and what do I have to rewrite?

The table below projects the approaches onto two of the criteria, determinism and boot cost, because they suffice to visualize each family’s profile. The other criteria read in complement in the following sections.

quadrantChart
    title Determinism vs Boot cost
    x-axis "Low boot cost" --> "High boot cost"
    y-axis "Low determinism" --> "High determinism"
    "OpenClaw": [0.15, 0.1]
    "Hermes Agent": [0.2, 0.15]
    "Dify": [0.3, 0.4]
    "CrewAI": [0.45, 0.5]
    "LangGraph": [0.55, 0.7]
    "argentic-mw": [0.8, 0.9]

The quadrant reads simply: top left, you start fast but lose flow control; bottom right, you gain determinism but pay in boot cost. No approach occupies the top-right corner, and that is the observation that structures the rest: you do not gain determinism without investing in the core, and you do not start instantly with a complete core.

Axis A vs custom: full-LLM agent against deterministic core

Let us apply the framework to OpenClaw and Hermes Agent, which are the most visible incarnations of the “all-in-one full-LLM agent” axis. OpenClaw, born from a series of renamings in late 2025 and early 2026 (Clawdbot, then Moltbot, then OpenClaw), is a personal assistant whose main interface is a messenger and whose extension model relies on skills injected at runtime. Hermes Agent, backed by Nous Research, shares the same philosophical family: self-improvement, cross-session memory, parallel sub-agents, a multi-platform gateway. Both are MIT-licensed and active, but they do not embody the supervised philosophy.

On determinism, they fold on the first question. The execution flow is driven by the LLM, which picks the next action at every iteration. The code is at the margin, the LLM is at the center, and the order of actions is not readable in a file. For a personal agent that learns a user’s preferences, that is on point. For a scheduled business pipeline that must produce the same behavior every morning, it is a structural defect no prompt tuning fixes.

On auditability, the same gap shows up. An OpenClaw run produces a probabilistic trajectory whose path is reconstructed after the fact, but does not replay identically. For personal use, the approximation is fine. For a regulatory audit that asks, for a dated decision, to retrace the inputs and the reasoning, it does not hold.

On token cost, the open loop is an architectural fact, not a configuration defect. Every iteration consumes, the context grows, and the length of a run depends on a terminal state the model has to decide to reach. On an hourly cron, the bill becomes an uncontrolled parameter, unless you cap it artificially with external guardrails. argentic-mw, by contrast, calls the LLM at fixed extension points with per-Step consumption limits: the bill is predictable to the Step, and the same pipeline run today and in six months consumes the same order of magnitude of tokens.

On prompt control, OpenClaw and Hermes Agent rely on instruction files (SOUL.md, AGENTS.md, TOOLS.md) and injected skills, whose modification assumes a fine understanding of the runtime and the ecosystem. argentic-mw separates the configuration of an LLM Step (model, limits, prompt) from the pipeline code, and stores it in the database so it is editable via the control plane without redeployment. The difference is not cosmetic: it decides who can change behavior without touching code.

The documented security incidents are not theoretical and deserve to be cited. Research published by Cisco AI Security surfaced prompt injection and data exfiltration vectors via third-party skills on OpenClaw. 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, and all point to the same cause: an agent that decides its actions on its own is, by construction, an agent you cannot constrain a priori. The attack surface grows with every skill, because every skill is a potentially abusable capability, and no guardrail lives in the code around the model.

argentic-mw applied to the same framework does not win everywhere, and it is important to say so. On determinism, auditability, token cost and prompt control, the supervised philosophy holds, because it was designed for those properties. On multi-tenancy, the type-instance distinction lets you deploy several configurations of the same agent without redeployment, which is precisely the use case of a multi-team internal platform. On lock-in, the Core is code you own, which is both a freedom and a burden.

The burden is real and I am not hiding it. argentic-mw has a high boot cost, because you have to write the Core, the scheduler, the tracing, the replay cache, the control plane, the secret management. It has no instant start, no skill registry, no turnkey messaging gateway. The investment is paid in weeks of platform engineering, and it only makes sense if the targeted pipelines are recurrent, scheduled and subject to audit requirements.

Partial verdict, and that is the whole point of the framework: for supervised agents, axis A is a philosophical mismatch, not a quality defect. OpenClaw and Hermes Agent are not bad tools, they are tools built for another need, and the framework lets you read that without bias. For an autonomous personal agent or experimental use where you accept non-determinism, they remain a coherent choice. For a scheduled business pipeline in production, they answer the wrong question.

What about the middle path? Orchestration frameworks

There remains a third axis, which research calls “buy a core to build on”: frameworks and platforms on which you build your own agents. LangGraph, CrewAI, Dify, and the AutoGen pair that became Microsoft Agent Framework, are not autonomous end-user products, they are orchestration tools. The question is whether any of them delivers enough business core that you do not have to rebuild it on top.

LangGraph is the closest to the supervised philosophy. It is a low-level orchestrator that allows a deterministic graph, durable execution with crash recovery, human-in-the-loop, and observability via LangSmith. The graph is explicit, which answers the determinism question if you write it that way. The gap shows up on the rest of the framework: LangGraph does not provide a turnkey business core. Normalized traces, the replay cache, the human validation queue, the type-instance distinction, the rule table, all of that is to build on top. Observability is also biased toward LangSmith, which adds a dependency on the LangChain ecosystem. The boot cost is reduced on orchestration, but the supervised core remains to be written.

CrewAI offers two primitives. Crews are autonomous role-playing agents, which is an anti-pattern for supervised use, since the flow goes back to the model. Flows move closer to event-driven determinism, but without native audit or replay semantics, and without multi-tenancy configurable by construction. CrewAI AMP, the commercial layer, adds a control plane and telemetry, but stays oriented toward autonomy rather than scheduled pipelines. The distance with argentic-mw is measured on auditability and multi-tenancy, not on orchestration capacity.

Dify is the most “buy” of the lot, in the sense that it offers fast boot and a collaborative workflow UI, a Prompt IDE, RAG, Function Calling and ReAct agents, and an LLMOps layer. It is seductive for a prototype or an internal deployment that accepts partial determinism, since the “workflow” remains very LLM-centric. Two clarifications are in order. Dify is not under a pure Apache 2.0 license: it is the modified Dify OSS License, with commercial restrictions, which is not neutral for an enterprise deployment. And Dify has no native supervised agent model: no normalized timestamped traces, no replay, no human validation queue, no type-instance distinction. The platform lock-in is real.

AutoGen deserves an honest mention: it has been in maintenance mode since version 0.7.5 in September 2025, and its successor is Microsoft Agent Framework (MAF) 1.0, oriented toward enterprise multi-agent orchestration. Naming it as a forward-looking choice would be inaccurate, and MAF remains oriented toward autonomy and agent fleets rather than supervised pipelines. MAF’s maturity on the properties specific to supervised agents remains to be verified.

Verdict on the middle path: it reduces boot cost, sometimes significantly, but it does not deliver the native determinism and auditability of supervised agents. LangGraph’s graph is deterministic if you write it that way, but the business core remains to build, and you end up rebuilding on top what the supervised philosophy requires: traces, replay, validation, multi-instance. The framework only saves the orchestration layer, which is neither the most expensive nor the most discriminating. It is a viable choice to start fast, not a substitute for the core.

When to build, when to buy

The framework does not plead for a single answer, and that would be dishonest. Buy if your need is an autonomous personal agent that learns a user’s preferences, or a fast prototype where you accept non-determinism to move quickly. OpenClaw and Hermes Agent answer the first case, Dify the second, and they have their legitimate audience. Build if you have scheduled business pipelines with audit, control, bounded cost and configurable multi-instance requirements. argentic-mw is an answer to that family, not to all of them.

The framework is reusable: apply it to your context, your regulatory constraints, your volume, your team. The six criteria do not rank options in a universal order, they draw a profile to compare to yours. A team starting a prototype with no audit constraint does not need the supervised core, and building it would be a misplaced investment. A team touching client data, external communications and a cron in production does not have the luxury of non-determinism, and buying it would be a poorly measured risk.

The third post 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). The supervised philosophy laid out in the manifesto will meet the code that puts it into practice.