DEV Community: Forrest Zhang

Human in the loop for AI agents: which actions need approval and which don't

Forrest Zhang — Wed, 07 Oct 2026 15:36:18 +0000

Human in the loop for AI agents means a person approves, reviews or is notified about specific actions the agent takes, instead of trusting it end to end. It works best as a decision made per action rather than per agent: which actions the agent runs on its own, which it reports, which wait for approval and which it never takes.

Most vendor conversations treat it as a checkbox: yes, there is a human in the loop. That answer hides the two ways oversight fails. If a person reviews everything, the agent becomes a suggestion engine feeding a queue nobody clears. If nobody reviews anything, you learn what the agent misunderstood only after it has caused a problem. This article gives you a method for placing each action, and then covers the part that usually gets skipped, which is designing the review so the person stays a real check instead of approving by reflex.

Human in the loop is a decision you make per action

An AI agent in a business workflow takes a series of distinct actions. It reads a message, classifies it, updates a record, drafts a reply, sends it, closes a ticket or moves money. Those actions carry different levels of risk, so they need different levels of oversight. Each action can sit in one of four modes.

Mode	What the agent does	What the person does	Fits when
Act and log	Completes the action and records what it did and why	Reviews a sample of the log on a schedule	The action is easy to reverse, stays internal, and happens often
Act and notify	Completes the action and tells a named person	Reads the notice and can reverse it inside a short window	The action is reversible but someone should know it happened
Approve before	Prepares the action with its evidence and stops	Approves, edits, or rejects, usually with one click	The action is hard to undo or reaches customers, money, access, or people
Never	Cannot perform the action, because the permission was not granted	Does the action themselves, with the agent's preparation	The action is irreversible and consequential, or outside the agent's job

Most of the agent's value comes from the first two modes. Approve before is where the agent builds trust with the people who depend on it, and the never list is what keeps the worst week survivable.

OpenAI's practical guide to building agents names two triggers that warrant human intervention: exceeding a failure threshold, such as too many retries, and high-risk actions that are "sensitive, irreversible, or have high stakes," which it says should trigger human oversight "until confidence in the agent's reliability grows." That last clause matters, because it makes approve before a starting position for an action rather than a permanent one.

You can see the same structure in the tools engineers use to let agents work on code. Anthropic's Claude Code permission system is tiered. Reads inside the working directory need no approval, while shell commands, file edits and most web fetches ask first, and an approval can be saved as a standing rule. Its documentation reserves the mode that skips prompts for "isolated environments" where the agent cannot cause damage. Per action oversight already ships there as a product default.

How to decide which mode an action gets

Placing an action does not require understanding the model. It takes two answers that a business can give in a meeting.

The first is reversibility. Can the action be undone, by whom, at what cost and inside what window? Relabeling an email can be undone in a second, and a sent email cannot be undone at all.

The second is blast radius. Who and what does the action reach? A note on an internal record touches one row, and a message to a customer touches your reputation. A changed payment detail touches money, a change to someone's access touches security, and a decision about a person's employment touches their life.

OpenAI's guide suggests rating each tool an agent can use as low, medium or high risk on exactly these kinds of factors, including "read-only vs. write access, reversibility, required account permissions, and financial impact," and using the rating to pause or escalate. The placement matrix below applies the same idea for the person who owns the workflow.

Reversibility	Small radius: internal, one record	Medium radius: a team's work, a vendor, an internal message	Large radius: customers, money, access, employment, legal
Undone in seconds by anyone	Act and log	Act and notify	Approve before
Undone with effort, or only inside a window	Act and notify	Approve before	Approve before
Cannot be undone	Approve before	Approve before, or never	Never at launch

Here is where some common actions land. Classifying an inbound message and assigning an owner in the CRM are act and log. Posting a daily status summary to an internal channel is act and notify. Drafting a reply to a customer needs no gate, because a draft changes nothing, but sending that reply is approve before, since the send is the action. Issuing a refund or changing a vendor's bank details is never at launch: the agent prepares the case and a person does it.

Which systems the agent can reach at all is a separate decision, covered in what access an AI agent should have to your business systems. This article assumes access is settled and looks at what happens inside it.

The actions that stay behind a person, whatever the matrix says

Anything that commits money, changes access or permissions, deletes records, sends something a customer or vendor will treat as a promise, or affects someone's employment or legal position belongs on the human side of the line at launch. That is the default in our discovery sessions, and it matches the approval line in the rollout guide.

The agent can still help with these actions. It gathers the evidence and drafts the action, and a person commits it. In most workflows, the preparation is where the hours were going in the first place.

Design the review so it stays real

Vendor pages usually skip this half of human in the loop, and it decides whether the design keeps working or slowly stops meaning anything.

Name a person as the approver

An approver has to be a person, so "operations approves" does not count. Name the approver and a backup, and record both. If nobody can be named, the action is not ready for approve before and belongs in never.

Use the channel the approver already works in

Approval requests go to the tool the approver already uses, whether that is a chat channel or an inbox. They arrive complete, with the proposed action, the evidence the agent used, its reasoning in one or two lines and the options to approve, edit or reject. If checking an approval means opening four systems, it will be approved without checking.

A deadline and a default

Every approve before action needs a response window and a stated outcome if the window closes with no response. The safe default is almost always "do nothing and escalate to the backup." A default of "proceed if nobody objects" turns the approval gate into a timer, which provides no oversight at all. Who approves, in what tool and by when is one of the seven inputs the implementation guide asks you to bring to a first working session.

A review load a person can actually carry

Most designs ignore this constraint, and human factors research on people supervising automation is direct about it. In their review of the empirical studies, Parasuraman and Manzey found that automation complacency occurs when the supervised task competes with other work for attention, that it shows up in novices and experts alike, and that it "cannot be overcome with simple practice." Automation bias, acting on the machine's suggestion when it is wrong, "cannot be prevented by training or instructions." (Human Factors, 2010)

In practice, if you route hundreds of low-stakes approvals a day to one busy person, you get hundreds of clicks and very few real reviews. A more diligent person will not fix that, but a shorter approve before list will. Put the reversible, internal, high-volume actions in act and log, keep approve before for the actions that need it, and treat the daily approval count as a design number you check every week.

Sample the autonomous tier

Act and log still means somebody looks. A person checks a sample on a schedule instead of every instance in real time. Pull a fixed number of logged actions each week, check them against what a person would have done and record the miss rate. That miss rate tells you whether the action belongs in its current mode.

Enforce approval in the system instead of the prompt

An instruction in the agent's prompt such as "never send an email without approval" is only a request. OWASP's guidance on excessive agency names excessive autonomy as one of three root causes of damaging agent actions, and its mitigation is explicit. It calls for human approval of high-impact actions, implemented either in the downstream system or in the tool that performs the action, and for complete mediation, so that the systems the agent calls enforce authorization instead of the model deciding whether it is allowed. In plain terms, the send button should wait for a person because the integration is built that way, whatever the agent has been told.

Log everything and cap the rate

OWASP lists two measures that limit the damage of a bad action without preventing it: log and monitor what the agent's tools do, and rate limit them so monitoring catches an undesirable pattern before significant damage occurs. Anthropic's guidance on building effective agents makes the same point from the other side, noting that autonomy brings "the potential for compounding errors." Every action in every mode should get a record of the input, the decision, the evidence and the approver if there was one, and every action type should have a ceiling per hour. If an agent starts doing the wrong thing two hundred times, the limit should stop it at ten.

Move actions between modes on evidence, in both directions

For most actions, approve before is meant to be temporary, so you need a rule for what earns a move.

Use the evidence from the review design above. For an action in approve before, track how often the approver changed or rejected what the agent proposed. For an action in act and log, track the sampled miss rate. When both the edit rate and the miss rate have stayed low across enough consecutive cycles to mean something for that workflow, move the action one step: approve before to act and notify, or act and notify to act and log. For illustration only, and not as a benchmark, here is the kind of rule to write down: an internal action graduates after a full month of cycles with no approver edits and no sampled misses. Set your own numbers and put them in writing before launch.

Moves go the other way too. If the workflow's rules change, an integration changes, the underlying model changes or the edit rate climbs, the action goes back a step until the evidence recovers. Customer-facing sends and anything touching money do not graduate on schedule alone. They graduate when a named person signs off on the evidence, and some of them never do.

Anthropic's guidance describes agents that "pause for human feedback at checkpoints or when encountering blockers." Graduation is how you decide, deliberately and with a record, where those checkpoints sit this quarter.

A worked example: an inbox triage AI employee

Take a common role family: an AI employee that monitors a shared inbound inbox, keeps it organized and prepares replies. Here is one reasonable launch configuration. Your numbers and owners will differ.

Action	Mode at launch	Why
Read new messages and classify them by type	Act and log	Internal, reversible in seconds, high volume
Assign an owner in the helpdesk or CRM	Act and log	Internal, reversible, the owner sees it immediately
Post a morning summary of open items to the team channel	Act and notify	Internal message, useful for everyone to see, easy to correct
Draft a reply to a customer	No gate needed	Drafting changes nothing until someone sends it
Send a reply to a customer	Approve before	Reaches a customer, cannot be unsent
Close a ticket as resolved	Act and notify	Reversible, and the owner should know
Issue a refund or credit	Never at launch	Money, and the case is prepared for a person

The review design that goes with it has the support lead approving customer sends, with the operations manager as backup. Requests arrive in the team's chat tool with the customer's message, the draft and the reason for the proposed reply. The window is the same business day, and if it closes, the item escalates to the backup and nothing is sent. Each week the lead reviews a fixed sample of classifications and assignments and records the miss rate. After a month of cycles with no approver edits on a narrow class of replies, such as order status confirmations that quote the record exactly, that class becomes a candidate to move to act and notify, and the lead decides.

The review design worksheet

Fill in one row per action before launch. If a row cannot be completed, the action is not ready for any mode except never.

Action	Mode at launch	Approver and backup	Channel	Deadline and default	What is logged	Evidence to move it	Next review date
Send customer reply	Approve before	Support lead, ops manager	Team chat	Same business day, then escalate and hold	Message, draft, evidence, decision, approver	No edits across a full month of cycles, lead signs off	First of next month

This worksheet is the human side of the scorecard in the AI agent use cases guide. A provider should ask you for it rather than write it for you.

Frequently asked questions

Does human in the loop make an AI agent slower than doing the work ourselves?

Only if you gate the wrong actions. Approve before on a customer send costs one click on a draft that is already written and already checked against the record. Approve before on every classification costs a person their afternoon and produces reflex approvals. If you gate by reversibility and blast radius, most of the workflow runs without waiting.

Can the agent decide for itself when to ask a person?

An agent can be instructed to escalate when it is unsure, and it should be, but that instruction is a request inside a prompt rather than a control. The actions that must wait for a person should wait because the system enforces it, following the complete mediation principle OWASP describes. Use the agent's own judgment as a second safety net and never as the only one.

What is the difference between human in the loop and human on the loop?

People use the terms loosely. Broadly, in the loop means a person approves an action before it happens, and on the loop means the action happens while a person supervises the results and can intervene. In the four mode model, that is approve before versus act and notify, or act and log with sampling. Most real workflows use both, for different actions.

When can we remove an approval step?

When the evidence supports it: a low edit rate on the approvals and a low miss rate on the samples, sustained across enough cycles for that workflow, with a named person signing off. Write the rule down before launch, move one step at a time and keep the ability to move back.

Is approve before enough on its own?

No. It is one of three layers. The agent's access has to be scoped so it cannot reach what it should not, every action has to be logged and rate limited, and the approval gates sit on top of both. An approval gate does little if the agent behind it has unrestricted access.

Decide the gates before the tools

Whether to have a human in the loop is rarely the open question. What you need to settle is which actions get which kind of oversight, who checks them and what evidence would change that. Answer it per action, write down the review design and revisit it monthly. Your agent will do more on its own over time, and every expansion will have a record behind it.

If you buy a managed service or build your own, the approval rules are still yours to own. Nobody outside your business can decide what your customers should hear from a machine, or who signs off on a refund. The BankrBot incident shows what happens when nobody makes that decision.

Originally published at vantasoft.com.

What is Hermes Agent? The open-source AI agent, explained for business

Forrest Zhang — Wed, 07 Oct 2026 04:47:01 +0000

Hermes Agent is an open-source AI agent built by Nous Research and released under the MIT license. It runs as a long-lived assistant on a small server or your own infrastructure, connects to whichever language model you choose, and talks to you through Slack, Telegram, Discord, WhatsApp, a terminal or the Hermes Desktop app. What sets it apart is a built-in learning loop: it turns experience into reusable skills, keeps notes on what it learns and builds a model of the person it works for across sessions.

VantaSoft runs its own operations on Hermes Agent and deploys it for customers as a managed service, so this explainer draws on daily use as well as the documentation. Facts about the software below come from the official documentation and the public repository as of September 2026.

What Hermes Agent actually is

Most AI tools a business comes across are chat windows: you type, it answers, and the conversation ends. Hermes Agent works differently. It is a process that stays running, holds tools it can use (a terminal, files, web access and any integrations you grant), remembers across conversations, and can be reached from the messaging apps your team already uses.

Three properties from the documentation matter most for a business reader:

Self-improving. It creates skills from experience, improves them during use and prompts itself to save what it learns, so a task it did last month is easier this month.
Model-agnostic. It works with Nous Portal, OpenRouter, OpenAI or your own model endpoint, and switching models is a configuration change rather than a rebuild.
Runs anywhere. The project describes running it on a $5 VPS, a GPU cluster, or serverless infrastructure that costs almost nothing when idle, so it does not depend on anyone's laptop being switched on.

Hermes Agent vs the alternatives you have probably heard of

Option	What it is	Where it runs	Learning across sessions	License and cost
Hermes Agent	Open-source agent runtime with tools, memory, skills, and messaging integrations	Your VPS, cloud, or serverless; also a desktop app	Built-in loop: skills, memory, user model	MIT license, free software; you pay for the model and hosting
Claude Code and similar coding agents	Developer-focused agents for working in a codebase	Developer's machine or CI	Project context, mainly	Vendor-priced, tied to one model provider
n8n and workflow builders with agent nodes	Visual automation platform that can call a model inside a workflow	Cloud or self-hosted	No; each run starts from the workflow definition	Open-core, paid cloud tiers
Hosted agent platforms	Vendor-run agent builders with a web UI	Vendor's cloud	Varies by vendor	Monthly subscription per seat or per agent

In practice, workflow tools are strongest when the steps are known in advance and rarely change. An agent runtime like Hermes is strongest when the work involves judgment, tools and conversation, and when you want the assistant to get better at your specific business over time.

What Hermes Agent costs

The software is free under the MIT license. You pay for what it consumes:

Hosting. The documentation's own example is a $5 per month VPS for a single agent. Heavier workloads or many agents cost more.
Model usage. Whichever provider you choose bills you per token. A moderate workflow running a thousand times a month on a mid-tier model costs on the order of tens of dollars; see our AI agent development cost guide for worked numbers.
Setup and upkeep. Someone has to install it, connect the tools and channels, grant access safely and keep an eye on it. That costs either your team's time or a managed service fee.

When a business should run Hermes Agent

Good fit:

You want an assistant reachable from Slack or Telegram that can actually do things: read a mailbox, update a board, run a report, draft a document, check a system.
You want the assistant to get better at your business instead of starting from zero every session.
You care about choosing your own model provider and keeping the option to switch.
You want to own the runtime rather than rent a vendor's builder.

Poor fit:

Your need is a single, fixed, high-volume pipeline with no judgment in it. A workflow tool is simpler and cheaper.
Nobody on your side will own access, testing and review. An agent with tools needs deliberate access boundaries.

How to get started

For a technical team, the installation guide covers a one-line install for Linux, macOS and WSL2, a native PowerShell install for Windows, the Hermes Desktop app and a package for Android through Termux. A realistic first project is one workflow on one channel, run for a month, with a named person reviewing what the agent does. How to implement an AI agent in your business walks through that rollout.

For a business without a technical team, the managed route is to have someone build, host and maintain the agents for you. That is what VantaSoft does. We design the workflows, host Hermes Agent on managed infrastructure, connect it to your systems and keep it up to date.

We run our own company on it as well. What each of our eleven agents does on Hermes Agent is the closest thing to a reference deployment we can show you, down to the jobs they run on a schedule.

Frequently asked questions

Is Hermes Agent free?

Yes. It is open source under the MIT license. You pay for the language model usage, the server it runs on, and the time or service needed to set it up and keep it running.

What models does Hermes Agent use?

Any provider you configure: Nous Portal, OpenRouter, OpenAI or your own endpoint. Switching models takes a command rather than a rebuild.

Does Hermes Agent run locally?

It can run on your own hardware or a private server. The project's own examples range from a $5 VPS to a GPU cluster, and there is a desktop application for Windows and macOS.

Is Hermes Agent secure enough for business data?

You host the runtime yourself, so the data stays on infrastructure you control. The rest of the security work is in how you grant tool access, manage credentials and review what the agent does.

Originally published at vantasoft.com.

I didn’t know what my agents knew

Forrest Zhang — Sun, 04 Oct 2026 23:20:33 +0000

My agents run on a Mac mini and keep an LLM wiki: markdown pages they write and read so they remember things between conversations. I had no good way to look at it. That's the whole reason I built Dexio.

Part of it was curiosity. Part of it was a need to check that the wiki was accurate, because my agents make decisions from it. Better context, better decisions.

I built an LLM wiki visualizer during a trip to Guatemala. When I got back, I loaded the wiki my agents had been maintaining for six months without my eyes on it.

I was shocked. There was no page on me. No page on any of my businesses. No pages on any of my clients. Six months in, and the wiki had huge gaps where the most important context should have been.

The first thing I did was fill them. I asked my chief of staff agent to search my email and our transcripts and write the missing pages.

Since then, my agents work with a better understanding of who I am and what we do.

I also told them to write to the wiki as they go. Now they tell me whenever they create a page or update one.

I wish I had looked at my wiki sooner. I'm glad I started. Next I want one knowledge base for everything: me, my businesses, and my personal finances.

Dexio is open source: github.com/dexio-wiki/dexio. If you'd rather not run your own infrastructure, use the hosted version at dexio.wiki.

Originally published at forrestzhang.com.

Karpathy's LLM wiki: what it is and how to set one up

Forrest Zhang — Thu, 01 Oct 2026 17:00:12 +0000

An LLM wiki is a set of linked markdown pages that an AI agent writes and keeps
up to date from the sources you give it. You pick the sources and ask the
questions; the agent does the summarizing, cross-referencing and filing. Andrej
Karpathy described the pattern in April 2026.

What is Karpathy's LLM wiki?

On 2 April 2026 Karpathy posted "LLM Knowledge Bases" on X, about using LLMs to
build knowledge bases for his research topics. By late September X counted about
21.9 million views and 108,600 bookmarks on that post. On 4 April he followed up
with a gist, llm-wiki.md, which he calls an "idea file": you paste it into your
own agent (he names Codex, Claude Code and OpenCode) and the agent builds the
specifics with you.

The gist describes three layers:

Raw sources. Articles, papers, images and data files. They are immutable: the LLM reads them and never changes them.
The wiki. A directory of markdown files the LLM writes: summaries, entity pages, concept pages, comparisons, an overview. The LLM owns this layer; you read it.
The schema. A file such as CLAUDE.md or AGENTS.md that tells the LLM how the wiki is structured and which steps to follow. You and the LLM revise it over time. Our guides to CLAUDE.md and AGENTS.md cover what goes in each.

And three operations:

Ingest. You add a source and tell the LLM to process it. It writes a summary page, updates the index and the related entity and concept pages, and appends to the log. One source might touch 10 to 15 pages.
Query. You ask a question. The LLM finds the relevant pages and answers with citations. Good answers get filed back into the wiki as new pages.
Lint. Now and then you ask the LLM to check the wiki for contradictions, stale claims, orphan pages, concepts with no page of their own, and missing cross-references.

Two files help it find its way. index.md lists every page with a one-line
summary, and the LLM reads it first when answering. Karpathy says this works at
about 100 sources and hundreds of pages without embedding-based search.
log.md is an append-only record of ingests, queries and lint passes.

He keeps the agent open on one side and Obsidian on the other, and browses the
pages and the graph view as the agent edits. In his words: "Obsidian is the IDE;
the LLM is the programmer; the wiki is the codebase." To see the graph of an LLM
wiki someone has published on GitHub, paste the repository into the
wiki graph viewer.

LLM wiki vs RAG: why it compounds

Most people use LLMs with documents through retrieval (RAG). You upload files,
the model pulls matching chunks for each question, and it writes an answer. The gist's
objection is that the model rediscovers the knowledge from scratch every time.
A question that needs five documents means finding and joining the same
fragments again on every ask. Nothing builds up.

In an LLM wiki the synthesis happens when a source comes in. The knowledge is
"compiled once and then kept current, not re-derived on every query." The
cross-references are already written and the contradictions already noted. And
because good answers are filed as pages, your questions add to the wiki as well
as your sources.

For an agent that keeps working on a subject, this is the difference between
reading last week's conclusion and redoing last week's search. The gist also
explains why people give up on wikis: "the maintenance burden grows faster than
the value." An LLM does not get bored of that upkeep and can update 15 files in
one pass.

How to set up an LLM wiki

The gist is deliberately abstract. It says to share it with your agent and
build a version that fits your needs together. A layout that follows it:

my-wiki/
  AGENTS.md          # the schema (CLAUDE.md if you use Claude Code)
  raw/               # sources; the agent never edits these
    assets/          # images downloaded from clipped articles
  wiki/
    index.md         # every page, one line each
    log.md           # append-only history
    sources/
    entities/
    concepts/

A short schema to start from:

# Wiki schema

## Layout
- raw/ holds sources. Read them. Never edit them.
- wiki/ holds the pages you write, one topic per page.
- Link pages with [[page-name]].

## Ingest
1. Read the new file in raw/ and tell me the key points.
2. Write a summary page in wiki/sources/.
3. Update the entity and concept pages it affects. Note any claim it contradicts.
4. Add new pages to wiki/index.md with a one-line summary.
5. Append to wiki/log.md: ## [YYYY-MM-DD] ingest | Source title

## Query
Read wiki/index.md first, then the pages it points to. Cite the pages you used.
If an answer is worth keeping, file it as a new page.

## Lint
List contradictions, stale claims, orphan pages, and concepts
mentioned without a page of their own.

Then tell the agent what to do. Paste in the gist and ask it to set up the wiki
in this folder with you. After that, drop one source into raw/ and say
"Ingest raw/that-file.md and follow AGENTS.md." Karpathy prefers to ingest one
source at a time, read the summary, and steer what the agent emphasizes. When
you find a rule you keep repeating, add it to the schema so the next session
follows it too.

Where a local LLM wiki breaks down

The reference setup is one person, one agent and one folder. The gist does list
a team use, an internal wiki fed by Slack threads, meeting transcripts and
customer calls, and notes that a git repo gives you history and collaboration.
Once more than one agent or machine writes to the wiki, four problems show up:

Two writers edit the same files. Every ingest rewrites index.md, log.md and up to 10 to 15 other pages. Two ingests at once, from two agents or two laptops, touch the same files. A synced folder can drop one of the saves or leave a conflicted copy; git gives you merge conflicts in prose.
Pages go stale. Lint only happens when someone asks for it. Between passes, a page can keep a claim that a newer source replaced, and every agent that reads it repeats the old claim.
Nobody knows which agent wrote what. A folder without git keeps no history. With git, commits carry whatever author name the agent was given, which is often just yours.

How to share an LLM wiki between agents

There are three ways to do it.

A git repo. Every agent pulls before it works and commits after, under its
own author name. You get history and diffs. You also get conflicts in shared
files like index.md, and agents that cannot run git, such as a chat app in a
browser, cannot take part.

A synced folder. Easy for one person on two machines. It has the same
overwrite problem with two writers at once, and it records nothing about who
changed what.

A hosted wiki that agents reach over MCP. One copy, so nothing to sync or
merge. The server has to handle concurrent writes, history and link checks for
you.

Running an LLM wiki on Dexio

Dexio is a hosted wiki for AI agents, and it takes the
third option. Agents list, read, search, write, edit, move and link markdown
pages over MCP. Hermes, OpenClaw, Claude Code, Codex, Cursor, Claude and ChatGPT
can all write to the same wiki. Against the failure modes above:

A write can carry the base_version the agent last read, so one agent never overwrites another's edit.
Pages are plain markdown with [[wikilinks]]. Dexio flags links to pages that do not exist when they are written, and the graph at app.dexio.wiki shows them.
Pages unchanged for 90 days while the pages they link to have changed are marked as possibly stale.
Every change is kept in page_history, with the agent's name from the agent field on every change.
Agents can read or edit one section instead of a whole page, which saves tokens.

To connect an agent that runs commands, tell it "Look at dexio.wiki and log me
in." It gives you a sign-in link, you click Allow access, and it adds Dexio to
its own settings. Or add the MCP server yourself: https://app.dexio.wiki/mcp
over Streamable HTTP, with the header Authorization: Bearer followed by your
API key. Your other agents can use the same key; each names itself on every
change. Dexio is free for one person, and agents never count as members. You can
download any wiki as a zip of markdown files whenever you like.

Setup for each agent, step by step: Hermes,
OpenClaw, Claude Code,
Codex, Cursor and the rest in
Guides.

Start with one folder

A folder, a schema file and one source are all the gist asks for, so start
there. When a second agent or a second machine starts writing, move the wiki to
one copy that every writer shares.

Originally published at dexio.wiki.