The mistake most builders make is treating the assistant like the system.
The assistant is not the system. The assistant is the operator moving work through the system.
Your AI brain needs four layers:
Hermes can sit across those layers, but each layer still needs a clear job. If every idea, decision, task, secret, and receipt stays in chat, the system will collapse back into repeated steering.
Outcome for this lesson
By the end, you should have a one-page operating model that answers:
- where new inputs enter;
- where durable context lives;
- when a note becomes a ticket;
- what the assistant is allowed to change;
- how finished work gets verified;
- how corrections become improvements.
The rule of layer responsibility
Use this as the first version:
This keeps your brain from becoming a junk drawer and keeps your issue tracker from becoming a pile of half-shaped ideas.
Step 1: define your command surface
Pick where the assistant receives normal work.
For most builders, this is one private Discord server or Slack workspace with a few lanes:
- project lane;
- operations lane;
- content lane;
- personal/admin lane;
- bot/status lane.
Do not start by making twenty channels. Start with the surfaces you already use, then add structure when repeated work appears.
Write down:
Step 2: define your durable brain
Obsidian is the durable context layer.
It should hold things that are useful after the chat scrolls away:
- project notes;
- decisions;
- active thread scratchpads;
- reusable workflows;
- templates;
- weekly reviews;
- sanitized indexes.
It should not hold secrets, raw tokens, live cookies, credential files, or noisy runtime logs.
Write down:
Step 3: define the execution handoff
GitHub Issues are the clean handoff object when work is ready to build, edit, research, or ship.
A good issue should include:
- goal;
- source thread or note;
- scope;
- out of scope;
- acceptance criteria;
- verification requirement;
- reporting destination.
Use the GitHub Agent Issue Template when the work is ready.
Write down:
Step 4: define verification
The operator should not call work done just because a file changed.
Pick the receipt types you expect:
- tests;
- build;
- lint;
- preview URL;
- production smoke;
- screenshot;
- source link;
- message ID;
- exported artifact path.
Write down:
Step 5: define self-healing
Every correction should have a destination.
Use this routing:
The key is not to save everything. The key is to save the thing that prevents the same failure from happening again.
Copy this operating model template
Lesson checkpoint
You are done when you have one short operating model file that another person could read and understand how your assistant should move work from chat to notes to issues to verified output.
Do not automate anything yet. The goal is to make the operating loop explicit before adding tools.