Stop fixing your AI agents in chat

The first mistake we made with internal agents: fixing them in chat.

You correct the agent, it does better, and then the next session forgets. A teammate's agent never knew about the correction in the first place. A week later someone fixes the same thing again, slightly differently.

The fix was boring. Every rule now lives in a file the agents read. A correction is a small edit, and every agent follows it on the next run.

Here's how that works in practice, and the three habits that kept it usable as it grew.

A correction in chat lives in one conversation. When that session ends, so does the rule. Assistants with memory keep it per person, so it still doesn't reach the colleague who asks the same question tomorrow.

Nobody can review it either. You can't see which rules the agent follows, who added them or whether two of them disagree.

When the agent gets something wrong, ask one question: which file should have said this?

Then change that file. Say the agent reported gross sales when the team means net:

## Net sales -Revenue for the period. +Revenue for the period after returns and discounts. +Use the finance export, not the CRM total. The CRM includes cancelled orders. Enter fullscreen mode Exit fullscreen mode Commit it like any other change. The next run, in your session or a teammate's, uses the new rule.

You get three things chat never gave you:

Our shared setup started with one big instructions file. It grew until the agent was loading pages of rules it didn't need for the job in front of it.

What fixed it was a short top file that is only a map of which file to read for which job:

# Team agent Read only the files the task needs. | Job | Read | | --- | --- | | Sales numbers | knowledge/definitions.md, knowledge/sources.md | | Weekly stock review | skills/weekly-stock-review/SKILL.md | | Anything sent outside the team | knowledge/approvals.md | Enter fullscreen mode Exit fullscreen mode Agents now load two or three files instead of the whole repo, and people can find a rule without scrolling.

We keep the agents' knowledge as plain Markdown files and let the agent search them, instead of running them through an embedding index first.

There's no index to drift out of sync with the files, because there's no index. People can read and fix the same files the agent reads. And when the data gets larger, grep still works wonderfully well.

The Claude Code team has described a similar path: they started with a vector database and moved to the agent searching the files itself.

team-hub/ ├── AGENTS.md # the map ├── knowledge/ │ ├── definitions.md # what "net sales" means here │ ├── sources.md # which export is current │ └── approvals.md # what needs a person's sign-off └── skills/ └── weekly-stock-review/ └── SKILL.md # the steps for one recurring job Enter fullscreen mode Exit fullscreen mode Definitions and sources go in knowledge/. Repeatable procedures go in skills/. Every correction has an obvious home, which is most of the point.

Committing your setup to a repo works for people who work in that repo with the same coding assistant. The rules usually need to reach people who don't: someone in ops asking in chat, or a report that runs at 7am.

That's what we built Hubzoid for. A Hub is a folder like the one above. The same files serve a team web chat, scheduled workflows and assistants such as Claude Code and Codex through MCP, so one correction reaches all of them. It's open source (Apache-2.0) and self-hosted: github.com/hubzoid/hubzoid.

Whatever you use, the habit is the same: when the agent is wrong, fix the file, not the chat.