Mert

There is one thing worse than a codebase with no documentation: a codebase with documentation that used to be correct.

The README that explains how to set up the development environment, with three commands that no longer exist. The architecture diagram from 2022 that shows services your team has since deleted, alongside two that have been renamed. The API reference whose example payloads have the wrong field names. The onboarding doc whose first link is broken. All of these existed for a reason. All of them, having outlived the world they described, are now lying to anyone who reads them.

Stale documentation is not a small problem. It is worse, in specific and measurable ways, than no documentation at all. And agents make the situation more acute, because agents read documentation eagerly and trust it.

Why this is worse than nothing

A codebase with no documentation produces honest uncertainty. New contributors know they have to learn the system from the code. They ask questions. They read until they understand. The absence is visible and it sets the expectation correctly.

A codebase with stale documentation produces confident wrongness. New contributors read the doc and believe they understand. They proceed on assumptions that the doc made true at some point in the past. They write code that fits those assumptions. The wrong work ships before anybody notices that the doc was wrong.

The dynamic is the same with agents, except faster. An agent reading a doc that describes a function signature that no longer exists will produce calls to that signature. The build fails, sometimes. Or worse, the agent constructs plausible code based on the doc and produces something that compiles but does not work, because the actual function expects different arguments.

The “no docs” case is easier to navigate than the “stale docs” case, every time. Absence is honest; staleness is not.

Why docs go stale

Documentation goes stale because it lives separately from the code it describes, and because nothing forces the two to stay in sync.

A function changes. The developer updates the function. The doc that describes the function lives in a wiki, in a Notion page, in a separate markdown file in a docs/ directory, in a comment three layers of indirection away from the function itself. Updating it requires a separate action. The separate action is easy to skip. Most of the time, it is skipped.

The doc continues to describe the old version of the function. New readers, human and agent, pick up the wrong information. The drift compounds across releases until the doc and the code are different artifacts describing different systems.

The teams that have functional documentation have one of two properties: either the documentation is generated from the code (so it cannot drift), or the documentation is treated as part of the code (so changes to one require changes to the other).

What “generated” can do

The strongest documentation is documentation the team does not write by hand.

API references generated from OpenAPI specs or schema definitions. If the schema is correct, the doc is correct. The schema is correct because the running service uses it.

Type signatures rendered as docs. Languages with good type systems can produce reference documentation that reflects the actual code. The doc and the code cannot disagree because the doc is the code.

Examples extracted from tests. The test runs. The test demonstrates how the function is used. The example in the doc is the test. When the function changes in a breaking way, the test breaks, and the example is no longer in the doc.

The shift toward generated docs is the cheapest large win available for documentation accuracy. It does not cover everything: there is still hand-written prose explaining concepts, walkthroughs, decision records. But it removes the largest source of staleness, which is API reference material that drifts because nobody is paid to keep it in sync.

What “treated as code” means

For everything that cannot be generated, the practice is to treat documentation changes the same way you treat code changes.

Docs live in the repository, near the code they describe. A README per significant directory. Comments that explain non-obvious choices. Decision records in docs/decisions/. The PR that changes behavior is the same PR that updates the relevant docs. The reviewer’s job includes catching the case where the doc was not updated.

The mechanical version of this is to add a checklist item to the PR template: “Did this change require a doc update?” The author confirms or explicitly says “no.” A reviewer who suspects a doc update was needed can push back, just like they would on a missing test.

The deeper version is to delete docs aggressively. A document that nobody is willing to maintain is a document that is going to go stale. If the team will not commit to keeping it current, the document should not exist. It is better to have a one-paragraph note that links to the code than to have a long doc that nobody reads and nobody updates.

How the agent fits in

The agent’s relationship with documentation is asymmetric. The agent reads docs into context at the start of a session. The agent does not, by default, update docs as it goes.

The way to fix this is to make documentation updates part of the change. The same rule that goes into AGENTS.md for any other concern: “If you change a function’s behavior, signature, or location, update any documentation that references it.” The agent, given that rule, will produce diffs that touch both files. Without the rule, the agent will produce diffs that touch only the code, because the code is where the failing test will surface.

A related rule is worth adding: “If documentation in this repository contradicts the code, the code is the source of truth. Update the documentation to match, or flag the discrepancy in a comment for human resolution.” The agent encountering stale documentation should not pattern-match against it; it should treat the code as authoritative.

First steps

If you have an accumulation of stale docs and you want to start fixing it:

Audit your top-level README today. Walk through every command in it. Delete or fix every one that does not work. The README is the document most readers see first; making it accurate is the highest-leverage change.

Find your most-linked-to doc. One that gets referenced in onboarding, in PR comments, in Slack threads. Walk through it. For each claim, check whether the code still matches. Either fix the doc or delete the claim.

For your API reference, if you have one and it is hand-written, switch to generated. OpenAPI from your routes, type-generated docs, whatever fits. The work to switch is real; the work it saves over the next year is larger.

Add to your PR template: “Did this change require a doc update? If yes, which docs were updated?” The question forces a moment of thought. Some PRs will say “no” and be correct. Others will discover, on being asked, that the answer was actually yes.

Add one rule to AGENTS.md: “When you change behavior, signatures, or names, update any documentation that references them in the same change. If you find documentation that contradicts current code, flag it explicitly in the PR description.”

The most valuable documentation is the documentation you can trust. The work to make documentation trustworthy is small, ongoing, and almost never urgent. Doing it anyway is what separates teams whose docs are an asset from teams whose docs are a trap.

If your AI initiative has been ‘pending’ for 6 months, the bottleneck is probably not technology. I’ve seen this pattern repeatedly across companies in both Asia and the US. The tools are accessible, the talent is available, and the use cases are clear. Yet nothing moves. The real constraints are organizational, not technical.

The first structural bottleneck I encounter is unclear data ownership. Who owns the customer database? The sales pipeline? The production logs? Without clear ownership, data remains trapped in departmental silos. Engineering teams can’t access what they need, and business leaders won’t prioritize cleanup. The tactical fix: assign a data custodian for each critical dataset this week. This isn’t a full-time role—just a point person who can answer “Who can approve access to this data?” and “What’s the current state of this dataset?” Make it someone who uses the data daily, not a C-level executive.

The second bottleneck is the absence of an operations sponsor. Many AI initiatives die in the “pilot purgatory” because no one is accountable for production deployment. The data science team builds something, the business leaders express interest, but no one owns the operational handoff. The tactical fix: identify an operations sponsor who will attend weekly implementation meetings. This person should have budget authority and decision-making power, not just advisory influence. Their first task is to define what “done” looks like—specific milestones with clear completion criteria.

The third bottleneck is the lack of success metrics. Without measurable outcomes, AI initiatives become abstract exercises. Teams build models without knowing what constitutes success, leading to endless revisions and scope creep. The tactical fix: define a single, measurable success metric this week. Not “improve customer experience” but “reduce average handle time by 15% for Tier 1 support tickets.” Not “optimize inventory” but “reduce stockouts for top 10 SKUs by 20%.” The metric should be business-focused, not technical.

Technology is rarely the constraint. I’ve worked with companies using open-source tools to solve problems that others couldn’t address with enterprise solutions. The difference wasn’t the tools—it was the organizational clarity. When data ownership is clear, when someone owns operations, and when success is measured, AI initiatives move forward regardless of the technology stack.

The tactical fixes I’ve outlined—assigning data custodians, identifying operations sponsors, defining success metrics—can be implemented by any non-technical leader this week. They don’t require technical expertise or budget approval. They require clarity and accountability.

What’s the single organizational constraint holding back your AI initiative right now?

This piece is from our notes on helping SMBs (10-100 people) build their first in-house AI teams. If your team is exploring this — quick feedback and questions welcome in the comments.

Hermes Agent Is Not a Chatbot Framework. It’s Early Infrastructure

Subtitle:

Most agent projects optimize for the demo. Hermes Agent is optimized for what happens after the demo: persistence, coordination, retries, and operational survival.

Most AI agent projects still live in the age of the demo.

They can search, call tools, edit files, maybe even spawn another agent. For a few minutes, that feels like the future. Then the runtime starts to matter. Context swells. Tools fail in unglamorous ways. Memory becomes a vague promise instead of a state model. Multi-agent coordination turns into prompt theater. What looked like autonomy was often just a well-lit happy path.

Hermes Agent is interesting because it seems to understand that the real problem starts exactly where the demo ends.

After reading the docs and tracing the repository itself, I kept coming back to one conclusion: Hermes Agent is not trying to become a better chatbot framework. It is attempting to become infrastructure for operational autonomous AI systems.

That distinction matters. A chatbot framework is mostly about interaction quality. An autonomous runtime is about continuity: surviving retries, preserving state, routing across providers, controlling tools, and coordinating work that outlives a single exchange.

Halfway through tracing the runtime, I realized Hermes was not really optimizing for chatbot UX at all. It was optimizing for operational continuity.

That belief shows up everywhere:

• in how prompts are stabilized for cache reuse
• in how memory is bounded instead of mythologized
• in how tools are registered, filtered, and stitched back into the transcript
• in how background self-improvement produces files and skill patches instead of invisible “learning”
• in how “multi-agent” means both short-lived delegation and durable Kanban-backed coordination

Most projects avoid these tradeoffs because they make the system messier. Hermes leans into them because that mess is the actual work.

“Tool calling is easy. Operational durability is hard.”

[Insert screenshot: Hermes TUI showing active tool execution, status updates, and a running conversation]

The real problem Hermes Agent is trying to solve

The common failure mode in agent systems is not reasoning. It is orchestration.

Once an agent is allowed to act over time, the center of gravity shifts. The model becomes only one component. The real difficulty moves into runtime concerns:

• how turns are persisted
• how context is compressed
• how tool failures are retried
• how permissions are enforced
• how model transports differ
• how work is interrupted
• how state is handed off
• how multiple workers coordinate without hallucinating coordination

This is where many “agent frameworks” quietly collapse. They solve the first inference call and leave everything after that to application code, operator discipline, or luck.

Hermes takes a different stance. It treats long-running autonomy as an infrastructure problem. If you take that seriously, memory stops being a product flourish and becomes a state model. Tooling stops being a list of functions and becomes an execution layer. Multi-agent stops being a branching trick and becomes workflow coordination. Prompt construction stops being prompt engineering and becomes cache economics.

The deeper architectural signal here is simple: the runtime eventually becomes the real product.

That is why Hermes feels different. It is one of the few open-source projects in this space that consistently behaves as though the hardest part of agents is not getting them to act, but getting them to keep acting coherently.

What Hermes Agent actually is

At the surface, Hermes Agent is an open-source agent from Nous Research that runs in a terminal, over messaging platforms, through editor integrations, and in scheduled jobs.

At the systems level, it is better understood as four things at once:

1. An agent execution kernel
2. A tool orchestration runtime
3. A persistence and memory layer
4. A coordination layer for long-running autonomous work

The core object is AIAgent in run_agent.py, but the project has been steadily decomposing that runtime into subsystem modules for conversation flow, prompt assembly, provider resolution, tool execution, compression, memory, and background review.

That decomposition is not cosmetic. It is what happens when a project stops being a clever monolith and starts becoming a platform.

flowchart TD
    A["Entry Surfaces<br/>CLI / TUI / Gateway / ACP / Cron / API"] --> B["AIAgent Runtime"]
    B --> C["Prompt Assembly<br/>stable / context / volatile"]
    B --> D["Runtime Provider Resolver<br/>transport + auth + model"]
    B --> E["Tool Registry + Dispatch"]
    B --> F["Session State"]
    B --> G["Background Review"]
    B --> H["Kanban Coordination"]

    C --> I["SOUL.md / AGENTS.md / .hermes.md"]
    C --> J["MEMORY.md / USER.md"]

    E --> K["Terminal / Files / Browser / Web"]
    E --> L["MCP Servers"]
    E --> M["Delegation / Memory / Messaging Tools"]

    F --> N["SQLite state.db + FTS5"]
    H --> O["SQLite kanban.db"]
    G --> P["Skill Updates + Memory Writes"]

[Insert diagram: Full Hermes runtime architecture]

The interesting part is not the number of features. It is the shape. Hermes is designed as though the agent may need to keep working across interfaces, failures, sessions, and execution environments. That is infrastructure thinking.

Before the architecture gets interesting, the setup has to be boring

Good runtime design starts with a practical first-run path.

The shortest install is:

pip install hermes-agent
hermes

The docs also cover Linux, macOS, WSL2, Termux, and early-beta native Windows support. One date detail is worth being precise about: on May 19, 2026, the latest public GitHub release page I verified showed v0.13.0, while the repository main branch I inspected already contained version = "0.14.0" and a corresponding release note file. Hermes is moving quickly enough that release state and main-branch architecture briefly diverge.

Provider setup happens through:

hermes model

That command is doing more than picking a model. Hermes resolves a runtime shape:

• provider
• base URL
• auth source
• API mode
• transport path

Then the first useful run is:

hermes --tui

A grounded first prompt is still the best test:

Summarize this repository in 5 bullets and tell me what the main entrypoint is.

From there, a realistic workflow is:

hermes tools
hermes skills
hermes doctor
hermes gateway setup

I like this sequence because it reflects operational maturity in the docs themselves. Hermes does not encourage you to turn on everything at once. It encourages you to stabilize the runtime, then widen the surface area.

[Insert screenshot: hermes model or hermes --tui first-run view]

Once an agent persists across turns, runtime architecture becomes the story

The core runtime behavior lives across run_agent.py, agent/conversation_loop.py, agent/system_prompt.py, and related modules. The crucial point is that Hermes is not simply “asking the model what to do next.” It is supervising a controlled loop.

flowchart TD
    A["User Input"] --> B["Restore or Build Cached System Prompt"]
    B --> C["Resolve Provider Runtime"]
    C --> D["Call Model"]
    D --> E{"Tool Calls?"}
    E -- Yes --> F["Validate + Guardrail + Approve"]
    F --> G["Dispatch Tools"]
    G --> H["Collect and Stitch Results"]
    H --> D
    E -- No --> I["Finalize Output"]
    I --> J["Persist Session"]
    J --> K["Optional Background Review"]

[Insert diagram: Runtime execution lifecycle]

One runtime across many surfaces

Hermes tries hard to keep a single AIAgent core serving CLI, gateway, cron, ACP, and related flows. Platform differences are pushed outward into routing, delivery, and UX.

That matters because it prevents every surface from becoming its own slightly different ontology of the agent. A lot of systems fracture here. Hermes mostly resists that fracture.

The conversation loop is really a control loop

The deeper architectural signal in agent/conversation_loop.py is that it behaves more like a supervisor than a wrapper.

A turn includes:

• prompt restoration from persisted session state
• message sanitization
• provider resolution and transport selection
• retry and fallback logic
• compression triggers
• tool-call validation
• interrupt propagation
• session DB writes
• memory and skill review nudges

This is where Hermes stops feeling like a demo framework. A demo loop asks “what should the model do next?” Hermes also asks “what happens if the answer is malformed, interrupted, stale, rate-limited, context-broken, or partially completed?”

Prompt assembly is engineered for stability

Hermes’s prompt layering is one of its sharpest decisions.

agent/system_prompt.py splits the prompt into:

• stable
• context
• volatile

The stable layer includes identity, tool-use directives, model-family execution guidance, skills prompts, and environment hints. The context layer includes project-shaping files like AGENTS.md, .hermes.md, and SOUL.md. The volatile layer includes memory snapshots, user profile blocks, and timestamp/session/provider metadata.

What surprised me most was how aggressively Hermes optimizes prompt stability as a systems concern rather than a prompt-engineering trick. This is not just about better prompts. It is about preserving prefix-cache reuse, reducing cost, and keeping runtime behavior explainable.

flowchart LR
    A["Stable Layer<br/>identity + tool guidance + skill guidance"] --> D["Final System Prompt"]
    B["Context Layer<br/>AGENTS.md + .hermes.md + SOUL.md"] --> D
    C["Volatile Layer<br/>memory + user profile + session metadata"] --> D

[Insert diagram: Prompt layering system]

Provider abstraction is not fake abstraction

Many frameworks flatten providers into a lowest-common-denominator API and let the edge cases leak later. Hermes does something more honest.

hermes_cli/runtime_provider.py resolves not just a model and credential, but a transport family:

• chat_completions
• codex_responses
• anthropic_messages
• bedrock_converse
• optional Codex app-server runtime

That solves a real problem: the APIs are not actually interchangeable. Tool calls, streaming semantics, reasoning payloads, and multimodal behavior differ in ways that matter. Hermes absorbs that complexity into the runtime instead of pretending it does not exist.

Retries are a defining feature, not an accessory

If you want to know whether a project is serious about autonomy, inspect its retry paths.

Hermes has many of them.

The conversation loop handles malformed responses, empty content, truncated tool calls, JSON corruption, context errors, unsupported multimodal payloads, auth expiry, rate limiting, stream failures, and provider-specific oddities. It can also rotate through fallback models/providers when configured.

Most projects avoid this tradeoff entirely because retry logic is thankless and makes architectures uglier. But a long-running agent without recovery paths is just a failure demo with better branding.

“Most agent systems fail not at reasoning, but at orchestration.”

The codebase is large, but it isn’t confused

Hermes is broad, and sometimes sprawling, but the repository has a recognizable internal shape.

Two patterns stand out.

First, Hermes is clearly in the middle of a long modularization process. Large methods have been extracted into subsystem modules while compatibility wrappers stay in the top-level runtime. That is exactly the kind of unglamorous refactor a project undergoes when it is growing from a tool into a platform.

Second, Hermes leans heavily on registry-based extensibility. Tools self-register. Providers are registry-driven. Plugins and MCP servers join controlled discovery paths. Registries are one of the few ways a runtime can keep growing without turning every new capability into hand-maintained branching logic.

The tradeoff is obvious: power buys complexity. But the codebase’s shape suggests the maintainers know that and are paying the price consciously.

The moment memory becomes operational, infinite-context fantasies start to look unserious

Hermes’s memory design is one of the clearest examples of systems maturity in the project.

It does something many AI products still resist: it makes memory small.

The built-in model revolves around two files:

• MEMORY.md
• USER.md

MEMORY.md stores durable operational facts: environment quirks, stable conventions, useful learned constraints. USER.md stores user preferences and long-lived interaction norms.

This is not as flashy as “infinite adaptive memory.” It is better.

flowchart TD
    A["Session Start"] --> B["Load MEMORY.md"]
    A --> C["Load USER.md"]
    B --> D["Prompt Snapshot"]
    C --> D
    E["Conversation History"] --> F["SQLite state.db"]
    F --> G["FTS5 Session Search"]
    H["Background Review"] --> I["Memory Tool Writes"]
    I --> B
    I --> C

[Insert diagram: Memory architecture visualization]

Why bounded memory is more credible than infinite memory

Bounded memory forces a runtime to answer the right question: what is durable enough to deserve always-on context?

Infinite memory usually creates four pathologies:

• stale facts stay live too long
• prompt cost grows without discipline
• importance becomes harder to rank
• debugging behavior gets much harder because state is diffuse

Hermes separates memory from history.

• Memory is small, curated, and injected up front.
• History is persisted in SQLite and searchable via FTS5.

That separation is stronger than it first appears. Memory answers: what should always matter? Session search answers: what happened before? Those are different questions, and most systems blur them.

Frozen snapshots are a feature

Hermes loads memory into the prompt as a frozen snapshot at session start. If the agent writes new memory during the session, the change persists to disk but does not mutate the live prompt.

At first that can feel conservative. The longer I sat with it, the more correct it looked.

This preserves:

• prompt stability
• prefix-cache reuse
• explainability of current-turn behavior
• resistance to hidden state drift

Memory here is not mystical. It is bounded, inspectable, editable, and operational. That is probably much closer to what future autonomous systems will actually need.

Tooling is where the runtime starts to show its real shape

Tool orchestration is the point where most agents stop being “model products” and start being systems problems.

Hermes has a notably mature answer to that transition.

The registry is the center of the tool system

The tooling model is built around tools/registry.py and model_tools.py.

Tool modules self-register. Discovery imports them. Schemas are filtered by toolsets, availability checks, config, and runtime generation. Plugins and MCP tools enter the same broad control plane.

The interesting part is not the registry itself, but what it implies: Hermes treats tools as runtime citizens, not prompt accessories.

Runtime-aware exposure is more important than it sounds

Hermes does not expose every tool all the time.

Tool visibility can depend on:

• enabled or disabled toolsets
• platform configuration
• capability probes
• plugin discovery
• MCP server filtering
• runtime conditions

That matters because capability management is part of model performance. Overexpose the tool surface and the agent wastes turns, widens risk, and reasons against irrelevant options. Hermes seems to understand that tool selection is as much about subtraction as addition.

Concurrent dispatch is handled like a real subsystem

Hermes supports concurrent tool execution, but with more care than most comparable systems.

The executor in agent/tool_executor.py:

• checks whether a batch is safe to parallelize
• propagates approval callbacks into worker threads
• propagates interrupts
• preserves original tool-call ordering in the results stream
• keeps activity surfaces alive during longer work

That last point is underrated. Tool concurrency is not interesting because it is fast. It is interesting because it is easy to break transcript coherence. Hermes is one of the few projects here that seems visibly worried about that problem.

flowchart LR
    A["Model Tool Calls"] --> B["Argument Parse"]
    B --> C["Guardrails + Approval"]
    C --> D{"Parallel Safe?"}
    D -- Yes --> E["Concurrent Dispatch"]
    D -- No --> F["Sequential Dispatch"]
    E --> G["Ordered Result Collection"]
    F --> G
    G --> H["Transcript Stitching"]
    H --> I["Next Model Turn"]

[Insert diagram: Tool orchestration lifecycle]

[Insert screenshot: Hermes tool execution in progress, showing multiple tool calls or status indicators]

MCP is treated as a namespace problem, not a novelty feature

Hermes’s MCP integration supports:

• stdio and HTTP servers
• dynamic discovery
• per-server include/exclude filters
• capability-aware registration of resource and prompt utilities
• runtime refresh when tool lists change

What matters is not that Hermes “supports MCP.” It is that MCP capabilities join the same managed runtime namespace as native tools. That is what makes it infrastructural.

Safety is inside the dispatch path

Hermes layers safety through:

• dangerous command approvals
• tool guardrails
• environment-aware restrictions
• context-file injection scanning
• sanitization of tool errors before reinjection into prompt context

No agent runtime with terminal access is ever truly “safe” in the comforting marketing sense. But Hermes does reflect the right mindset: once the agent can act, the runtime’s job is partly to bound how that action proceeds.

A realistic workflow: where Hermes stops looking like an agent shell and starts looking like operations software

The clearest way to understand Hermes is to follow a real workflow instead of a staged prompt.

Consider a small security engineering team using Hermes for nightly supply-chain triage on monitored open-source packages.

1. Cron starts the run

   • Hermes launches from the scheduler with a self-contained prompt and configured toolsets.
   • The run starts without prior chat history, but with access to persistent memory, skills, and configured tools.

2. The agent gathers evidence

   • It uses web and file tools to inspect changelogs, manifests, release notes, and advisory sources.
   • It uses terminal tools in a sandboxed backend to diff dependencies or unpack suspicious artifacts.

3. A suspicious signal appears

   • A package adds a new postinstall script and an unexpected outbound network call.
   • Hermes records concrete findings instead of vague suspicion.

4. The work exceeds one clean pass

   • Instead of pretending one loop is enough, Hermes creates a durable Kanban task assigned to a specialist profile: reverse engineering, code review, or threat intel.

5. A worker claims the task

   • Another Hermes worker claims the task from kanban.db.
   • It inherits the task summary, prior evidence, workspace context, and comments.

6. The worker performs deeper analysis

   • It uses bounded delegation for short subproblems and board-backed coordination for the broader workflow.
   • If a human judgment call is needed, it blocks the task explicitly rather than improvising.

7. Retries and failure are normal

   • If a provider rate-limits, Hermes retries or falls back.
   • If a run stalls, the worker heartbeat keeps the board honest.
   • If a process exits, the task still exists.

8. Results become durable artifacts

   • The worker completes the task with a summary and metadata.
   • Background review extracts reusable techniques into a skill.
   • Memory updates capture durable facts, not transient case details.

flowchart TD
    A["Cron Trigger"] --> B["Hermes Investigation Run"]
    B --> C["Search + Diff + Sandbox Analysis"]
    C --> D{"Suspicious?"}
    D -- No --> E["Report and Exit"]
    D -- Yes --> F["Create Kanban Task"]
    F --> G["Specialist Worker Claims Task"]
    G --> H["Deep Analysis + Tool Use"]
    H --> I{"Need Human Decision?"}
    I -- Yes --> J["Block Task with Reason"]
    I -- No --> K["Complete Task with Summary + Metadata"]
    K --> L["Background Review Updates Skill or Memory"]

[Insert diagram: Realistic operational workflow]

[Insert screenshot: Kanban board or task coordination view]

The moment the Kanban subsystem clicked for me, Hermes stopped looking like an agent framework and started looking like workflow infrastructure.

The important thing is not that Hermes can automate part of an investigation. Plenty of systems can do that. The important thing is that Hermes has primitives for durability across the workflow:

• scheduled entry
• persistent history
• delegated and durable coordination
• retries and fallbacks
• explicit blocking
• stable artifacts after completion

That is the difference between an assistant and a runtime.

“Multi-agent” usually means too little. Hermes splits it into two separate problems.

A lot of agent discourse uses “multi-agent” to describe anything involving more than one model invocation. That is not precise enough.

Hermes implicitly distinguishes between two categories of multi-agent behavior.

1. Ephemeral delegation

delegate_task in tools/delegate_tool.py creates child agents with isolated context, restricted tools, and focused tasks.

This is useful for:

• bounded parallel research
• scoped implementation subtasks
• isolated reasoning branches

It is fast, local, and temporary.

2. Durable coordination

The Kanban system in hermes_cli/kanban.py and kanban_db.py is something else entirely.

It provides:

• SQLite-backed tasks
• atomic claims
• heartbeats
• retries
• comments
• status transitions
• worker workspaces
• reassignment and blocking

This is not a swarm. It is workflow infrastructure.

flowchart LR
    A["Parent Agent"] --> B["delegate_task"]
    A --> C["Kanban Task"]
    B --> D["Ephemeral Child Agent<br/>isolated context"]
    C --> E["Persistent Task Row"]
    E --> F["Claimed by Worker"]
    F --> G["Heartbeat / Retry / Block / Complete"]

[Insert diagram: Delegation vs durable coordination]

This is where Hermes feels most future-facing. Most frameworks stop at the left side of that diagram. Hermes is trying to build the right side too.

Comparing Hermes to other frameworks means comparing philosophies, not just features

The least interesting way to compare agent systems is by counting tools or integrations.

The better question is: what problem is each system really optimized to solve?

LangChain / LangGraph

LangChain and LangGraph are strongest as application-construction frameworks. They give developers structured ways to compose model calls, state, routing, and execution graphs.

Their strength is composability. Their tradeoff is that you own more of the runtime philosophy yourself.

Hermes is less of a framework for assembling arbitrary LLM applications and more of a pre-shaped environment for running a persistent agent.

CrewAI

CrewAI shines when you want role-oriented multi-agent workflow authoring. It makes “a crew of agents” legible and approachable.

Hermes feels less role-first and more runtime-first. It spends more attention on tool discipline, memory, persistence, transport abstraction, and operational recovery.

AutoGen

AutoGen is excellent when your center of gravity is agent-to-agent interaction or multi-agent experimentation.

Hermes is less elegant as a pure research substrate, but stronger as an environment for agents that must live across terminals, chats, boards, and scheduled runs.

OpenAI Agents SDK

The OpenAI Agents SDK is clean, modern, and impressive as a developer orchestration toolkit with tracing, handoffs, and strong core primitives.

Hermes is solving a neighboring but different problem. The OpenAI SDK is a strong developer toolkit. Hermes is trying to become a runtime habitat.

This is why fanboy comparisons are unhelpful. Hermes is not simply “better.” It is more committed to one thesis: that long-running autonomous systems need a runtime layer that is itself a serious software system.

The price of being infrastructural is complexity

This is the section that determines whether praise is credible.

What Hermes gets unusually right

• Prompt stability: the stable/context/volatile split is one of the best prompt architectures I have seen in an open-source agent runtime.
• Memory discipline: bounded files plus searchable session history is far more credible than most “infinite memory” stories.
• Runtime honesty: provider transport differences are absorbed into the resolver instead of wished away.
• Tool maturity: registry-driven tools, filtered exposure, guarded concurrency, and interrupt propagation all suggest real operational experience.
• Durable coordination: the Kanban subsystem is more serious than most so-called multi-agent systems.

Where the system pays for that ambition

• Repo sprawl: Hermes is broad, and broad systems accumulate complexity quickly.
• Operational burden: once you use gateway, cron, MCP, plugins, multiple providers, memory backends, and Kanban together, you are operating infrastructure.
• Uneven maturity: some subsystems feel deeply settled; others still feel like active frontier construction.
• Extensibility tension: registries are powerful, but every new toolset, provider, or plugin path expands the maintenance surface.
• Not minimalist: if your problem is embedding one tightly scoped agent in an app, Hermes may be more runtime than you need.

The interesting part is not that Hermes is complex. The interesting part is that this complexity may be unavoidable for the class of problem it is tackling.

Persistent autonomous systems are fundamentally an infrastructure problem. Infrastructure eventually becomes layered, failure-aware, and operationally heavy. Hermes is paying that price early.

That is both the source of its power and the source of its rough edges.

We may be watching the transition from chatbot interfaces to AI runtime infrastructure

The strongest reason to care about Hermes is not that it is finished. It is that it points in the right direction.

A lot of the industry still talks about agents as though the future will be won by better prompting, nicer wrappers, or more provider options. Those things matter. But they do not solve the deeper problem.

Long-running autonomous systems need:

• durable state
• bounded memory
• stable prompts
• reliable retries
• explicit orchestration
• interruptibility
• transport-aware model routing
• coordination that survives process boundaries
• learning mechanisms that produce visible artifacts

That starts to look less like “chat” and more like a new runtime layer.

A few years ago, most AI tooling revolved around prompts and interfaces. Hermes feels like part of a more important transition: the center of gravity is shifting toward runtimes, orchestration, memory discipline, and operational continuity. That shift matters because the next generation of useful AI systems will be defined less by how well they chat and more by how well they persist, recover, coordinate, and keep working once the novelty wears off.

Hermes is one of the clearer open-source examples of that shift. It treats learning as files, skills, and memory mutations rather than hidden latent state. It treats multi-agent work as durable coordination rather than theatrical swarms. It treats prompt stability as an economic and architectural concern. It treats the runtime as the product.

That is why this project feels important.

Not because it is small. Not because it is tidy. Not because it is polished in every corner.

But because it behaves as if the next era of agents will not be defined by who can generate the slickest demo, but by who can build systems that keep working after the demo is over.

And if that is true, Hermes Agent is not another wrapper.

It is an early piece of the runtime layer for autonomous AI infrastructure.

“The future of agents may depend less on better models than on better runtime architecture.”

I First Heard About This in Class

Expert systems came up twice in my curriculum.Once in Management Information Systems.Once in Artificial Intelligence.

Both times I thought “this sounds incredibly intelligent and incredibly complicated.”

Turns out it’s both.
But also something any curious developer can understand and even build.

Let me explain everything.

What Is an Expert System?

An expert system is a computer program that mimics the decision-making ability of a human expert in a specific domain.

Not a general AI that knows everything.A focused system that knows one thing extremely well.

Think of it like this instead of asking a doctor every time you have a symptom,you ask a system that has been trained with a doctor’s knowledge.

It asks you questions.It reasons through your answers.It gives you a diagnosis or recommendation.

That’s an expert system.

How Is It Different From Modern AI?

This is the question everyone asks.

Expert systems are not better or worse than modern AI.
They are different tools for different problems.

Where explainability matters medical diagnosis, legal decisions, financial advice
expert systems are still relevant today.

How Does an Expert System Actually Work?

Every expert system has three core components:

1. Knowledge Base
This is where the expert’s knowledge lives.
Rules written in IF-THEN format.

Example:
IF patient has fever AND cough
THEN possible diagnosis is flu

IF patient has fever AND rash
THEN possible diagnosis is measles

The more rules the more intelligent the system appears.

2. Inference Engine
This is the brain of the system.
It takes your input,matches it against rules in the knowledge base,and draws conclusions.

Two ways it reasons:

• Forward chaining — starts from facts, works toward conclusion
• Backward chaining — starts from conclusion, works backward to verify facts

3. User Interface
How the user interacts with the system.Usually a question and answer format.

Famous Expert Systems You Should Know

MYCIN — 1970s, Stanford University
Medical expert system for diagnosing bacterial infections and recommending antibiotics.

Built by Edward Shortliffe as part of his PhD research.
Yes one person started this.

MYCIN performed as well as human specialists in controlled tests.
It was never used clinically due to legal and ethical concerns
but it proved expert systems worked.

DENDRAL — 1965, Stanford University
First ever expert system.
Used to identify chemical compounds from mass spectrometry data.Built by a team including Edward Feigenbaum and Nobel Prize winner Joshua Lederberg.

XCON — 1980s, Digital Equipment Corporation Configured computer systems for customers.Saved DEC millions of dollars annually.
Built by a team but maintained and expanded by knowledge engineers over time.

Deep Blue — IBM
Chess playing expert system that defeated world champion Garry Kasparov in 1997.Not pure machine learning rules, evaluations, and chess expertise encoded by human grandmasters.

Can One Person Build an Expert System?

Yes. Absolutely.

MYCIN started as one person’s research.Many academic expert of systems are built by individual students.

What one person needs:

Domain knowledge
Either you are the expert or you interview experts and encode their knowledge into rules.

A knowledge representation method
IF-THEN rules are the simplest.
Decision trees work too.Prolog is a programming language specifically designed for this.

An inference engine
You can build a simple one in Python.Or use existing tools like:

• CLIPS — free, specifically for expert systems
• Prolog — logic programming language
• Jess — Java based rule engine
• Experta — Python library for expert systems

A user interface
Even a simple command line Q&A works.Web interface makes it more presentable.

How to Build a Simple Expert System

Step 1 — Choose a specific domain
Not “medical diagnosis in general.”
Something specific like
“diagnosing common plant diseases”or “recommending a career path for students”

Step 2 — Gather knowledge
Interview an expert OR research thoroughly.Write down every rule you can find.

Step 3 — Structure your rules
IF [condition] THEN [conclusion]
IF [condition1] AND [condition2] THEN [conclusion]

Step 4 — Choose your tool
For beginners Python with Experta library
For academic projects CLIPS
For logic focused approach Prolog

Step 5 — Build the inference engine
Match user input against your rules.Return the conclusion with confidence level.

Step 6 — Build the interface
Simple input/output to start.
Web interface to make it presentable.

Project and Research Paper Ideas

Projects:

• Plant disease diagnosis expert system
• Career guidance system for students
• Loan eligibility assessment system
• Crop recommendation system for farmers
• Troubleshooting system for common
  software errors

Research Paper Topics:

• Expert systems vs machine learning for medical diagnosis accuracy
• Knowledge acquisition bottleneck in expert system development
• Hybrid expert systems combining
  rule based and ML approaches
• Expert systems for financial fraud detection
• Implementing expert systems in
  resource limited environments

Final Thoughts

Expert systems existed before neural networks.
Before deep learning. Before ChatGPT.

They solved real problems with human knowledge encoded into rules and they worked remarkably well.

Understanding expert systems gives you a foundation for understanding how AI reasoning works at its core.

Before AI learned from data humans had to teach it everything manually.

That process capturing human expertise and encoding it into a systemis still one of the most fascinating challenges in computer science.

And yes one curious student with
a laptop and Python can absolutely build one. 😊

Have you studied expert systems in your curriculum?
Or have you built one for a project?

Drop it in the comments 👇
Would love to see what domains
students are exploring!