Topics.md: A Better Way to Scope AI Agents

Actually, I know you dont.

I know because I did the stupid version first.

Topics.md is the topic-scoped registry I use to tell an AI agent which room it is in: what context to load, which memory applies, what tools are available, and what rules govern the work.

Before OpenClaw, I was already building with my own agent SDK from Vercel and my own harness. It was enough to prove the shape of what I wanted: agents with tools, memory, long-running sessions, and enough context to actually do useful work across a business.

Then OpenClaw became the test bed.

And once I had Telegram topics, CLI sessions, scheduled jobs, skills, memory files, and channel workflows all sitting there, the answer to every new problem started to look obvious:

Make another agent.

So I did.

I had agents for strategy, ops, research, content, memory, and whatever else felt different enough that day.

That sounds pretty cool until you have to maintain it.

It felt like building a team for about five minutes. Then it started feeling like I'm HR-ing markdown files.

One agent was answering in Telegram. Another was doing scheduled jobs. Another had its own memory rules. Another had a slightly different idea of what "platform work" meant. Then I would find myself staring at three instruction files trying to remember which one was allowed to touch cron.

That was the bit that made the system worse instead of better.

Every new agent needed its own identity file, bootstrap, tool boundary, memory surface, and operating rules. Every system change created another ownership question. Which agent owns this? Which memory is canonical? Why does this agent know half the story and that agent know the other half?

The embarrassing part is that I knew the system was getting messy, but every new problem still looked like it deserved a new agent.

That is when the distinction finally became obvious. A lot of the time, I did not need another agent.

I needed a better room.

New agent vs new room

I was treating agents like job titles. Strategy agent. Ops agent. Research agent. Content agent. Memory agent.

That sounds organised, but it hides what actually makes an agent useful.

Most of the value is not in the name. It is in the room the agent wakes up inside.

What did it read before replying? What instructions are active? What memory is relevant? What tools are available? What is it allowed to touch? What should it absolutely not do in here?

Once I looked at the system through that lens, the pattern got simpler.

Most of what I wanted from "more agents" was really four things:

• Different instructions

• Different context

• Different memory

• Different tools

That does not always need a new worker. Sometimes it just needs a new room.

What is Topics.md?

Topics.md is not another agent. It is the registry for the room the agent wakes up inside.

TOPICS.md is the registry I use in OpenClaw to tell an agent what room it is standing in.

In my case, the rooms are mostly Telegram topics.

One for platform work. One for advisory. One for content. One for CRM. One for blog drafts like this.

Same agent, different room.

Different memory. Different rules. Different skills. Different sense of what it is allowed to do.

OpenClaw is just where I tested the pattern properly. The implementation can be Telegram, Slack, a CLI session, a config file, a database row, or whatever your runtime gives you.

The point is the bootstrap.

If I ask about a failed cron in the platform topic, I do not want the agent dragging in advisory pipeline context. I want it to load the current platform state, check timeout streaks, remember the safe repair path, and avoid touching gateway config unless I explicitly ask.

If I ask about content in the blog topic, I do not want the agent thinking like a platform engineer. I want it loading the voice rules, the content workflow, the right draft, and the memory of what we already decided.

In OpenClaw, a topic can define the purpose of the work, the files to load, the memories to recall, the skills to make available, and the rules that only apply inside that context.

The rough shape is simple:

ops:
  purpose: platform reliability
  load:
    - current platform state
    - gateway runbooks
    - cron history
  memory:
    style: operational_watchlist
  skills:
    - exec
    - cron
    - gateway
  rules:
    - never restart gateway unless explicitly asked
    - always check last 3 cron runs before diagnosing

The exact syntax does not matter.

What matters is that the agent does not wake up blank, and it does not wake up with the whole world either.

It wakes up with the room.

Topics.md vs more agents

A new agent makes sense when the boundary is permissions, identity, model, owner, or risk.

A new topic makes sense when the boundary is context, memory, instructions, or tools.

The overhead is the point

The overhead of agent sprawl is easy to ignore in a demo. It is much harder to ignore when the system runs every day.

More agents means more instructions to maintain. More permission surfaces to think about. More memory boundaries to debug. More places for behaviour to drift. More chances that two agents each know half the truth.

That is fine while you are playing around. It gets expensive once agents become the operating layer for actual work.

And I mean expensive in the boring ways that actually kill systems.

Slower sessions. Bloated context. Stale memory. Duplicated files. Agents quietly loading research output as if it were identity instructions. Platform data leaking into advisory memory. Three agents echoing each other's notes instead of synthesising their own.

None of that is dramatic enough to show up in a launch video.

All of it compounds.

An agent with stale context makes worse calls. An agent with a bloated bootstrap wastes tokens every time it wakes up. An agent with unclear ownership creates more work than it saves because now you are debugging the task and the worker.

That is the part I think gets missed in the "multi-agent everything" conversation.

More agents can increase capability.

They also increase surface area.

Sometimes that trade is worth it. Often it is not.

The reason I care about TOPICS.md is not because it is elegant. I care because it reduces maintenance.

One well-scoped agent with good topic boundaries is easier to reason about than ten agents with overlapping responsibilities. Easier to update. Easier to audit. Easier to debug.

And once the rooms are clean, the memory graph starts to make sense.

That is the bit I am most interested in.

Topic-scoped memory gives each room its own local truth. Ops memory stays in ops. Release memory stays in release. Advisory memory stays in advisory. Content memory stays in content.

But the memories still sit in the same OpenClaw instance.

So when the work actually needs the bigger picture, the agent can reach across topics without pretending every topic is the same.

The graph only matters after the rooms are clean. Otherwise you are just connecting a bunch of polluted chat histories and pretending it is memory.

The balance I want is simple: Scoped by default. Global when needed.

Where Hermes Agent fits

My Vercel SDK and harness taught me how to wire agents together.

OpenClaw taught me what breaks when agents become the operating layer for actual work.

NousResearch's Hermes Agent is where I'm now productising the useful part of all my learnings.

The runtime works better for me right now. And the parts that I've learnt from OpenClaw have been phenomenal. I'm not hating on OpenClaw — it is where I found the pattern and I think steipete is doing a fantastic job — but Teknium and the community seem to be building something that works better for me right now. And the parts that I've learnt from OpenClaw have been phenomenal.

One of those parts is this: do not make people manage ten agents when one well-scoped agent can do the work.

Give the agent the right room. Give the room the right memory. Give the agent the right tools. Let the memory graph connect the rooms when the work actually needs it.

When you should still create another agent

I am not saying "never create more agents."

Separate agents make sense when there is a real boundary: different permissions, different model, different identity, different owner, different risk profile, or different operating rhythm.

My platform engineering agent should not be the same as my advisory operator agent. That separation is real. One can touch infrastructure. One carries relationship context. One can diagnose cron failures. The other should not be anywhere near gateway config unless I explicitly ask.

But "this thread needs different context" is not automatically a reason to create another agent.

Sometimes it is just a topic. Easy as!

The pattern is simple

If you are building agents, try this before multiplying them.

Before you create the next agent, ask whether you need a new worker or just a better room.

If the boundary is permissions, identity, model, owner, or risk, sure. Create the agent.

If the boundary is context, memory, instructions, or tools, I would try a topic first.

Mine is called TOPICS.md.

The point of all this

Agent sprawl feels good at the start because it feels like building a team.

But if every agent has overlapping instructions, half-shared memory, and unclear ownership, you have not built a team.

You have built a debugging problem with names.

If I was to do it all over again I would start smaller. Less is more. Fewer agents with better compartments. Scoped memory trumps a labyrinth of agents held together with paperclips.

Think in first principles and the one place to reach the broader picture when the work needs it.

Then build the memory graph on top.

And then the agent is not the hard part anymore. The hard part is making sure it wakes up in the right world.

Context is king.

In short: Topics.md is a way to give one AI agent many well-scoped rooms. Instead of multiplying agents for every workflow, each topic defines the context, memory, tools, and rules the agent should wake up with.

Originally published on X.