We talked last time Hermes Advanced Use: Working with MultiProfile + Wiki Sharing Memory to Build Your OPC Agent Team (Previously).
The core view is:
- Don't let an Agent take on all roles at the same time。
A more stable way to organize Agent into a small team:
- Coordinator coordinates
- Researcher is in charge of research
- Writer is responsible for expression
- Builder builds。
But this raises a new problem:
- How do they work together in the long term
The answer is:
- Use Wiki as a shared memory layer。
I. Wiki, what is it
In this system, Wiki is not an ordinary notebook。
It's the whole thing OPC System:
- Sharing the knowledge base
- Project management
- Long-term memory layer。
It manages three types of things:
- Knowledge
- Information
- Outputs。
More specifically, Wiki is responsible for recording:
- Project background
- Mission status
- Advance logs
- Key decision-making
- Intermediate material
- Final outputs
- Cross-project methodology
- Source material。
It can be understood as a corporate shared document system。
In this system:
- Profile is an employee
- Project is the project office
- Wiki is the company database
- Cordinator is the master control。
So, multiple Profiles can work together through Wiki even if their memories are not connected。
II. Overall structure of Wiki
A complete Wiki, with eight parts:
op. cit.mdschema.mdsystem/projects/pages/raw/assets/archive/
Pasted image 202604282144948.png appears to have a large number of parts, but each layer has a clear role to play。
Together, they address a core issue:
- Where should I put the information
If you don't have layers, everything will mix。
for example:
- The status of the project will contaminate user images
- Ideas can contaminate long-term knowledge
- Role experience contaminates project rules
- The source information will be mixed with the final conclusions。
So the first principle of Wiki is:
- The layer, it's anti-pollution。
III.index.md: Wiki entrance
index.md is the front page of the entire Wiki。
It doesn't have specific content, it does navigation。
It tells people and Agent:
- Where is the system area
- What are the current projects
- Where is the general knowledge
- Where are the originals
- What's the point lately。
the role of index.md is to get any Profile into Wiki and know where to start reading。
It's a map, not a warehouse。
IV. SCHEma.Md: Wiki Norms
schema.md is Wiki's Constitution。
It provides that:
- How the document is named
- Where does it go
- Which documents are read-only
- Which documents could be modified
- What information cannot be fabricated
- How the page status is marked。
With the schema.md, the whole Wiki will be stable for the long term。
Otherwise, every Profile will write a document in its own sense, and it will soon be a mess。
for example, schema.md can provide that:
- Raw read-only
- Project documents only record information on corresponding items
- Pages records only cross-project reusable methodology
- System records only global management information
- uncertain information goes first inbox, not directly to pages。
That's the rule layer。
v. system: global management
system is the Wiki global management area。
It is not a specific project, but a system-wide management hub。
the system contains six core documents:
dashboard.mdagent-log.mdweekly-review.mdmemory-routing.mdskill-registry.mduser-profile.md
1. dashboard.md: master panel
dashboard.md records the current status of all items。
It replied:
- What are the projects
- How has each project progressed
- What's next
- Who's in charge
- Are there any obstacles
dashboard.md should normally only be updated by Cordinator。
Other Profile can read, but do not modify。
This would avoid conflict between multiple players and the general control panel。
2. Agent-log.md: Global Age Behaviour Log
agent-log.md records all Profile's done。
for example:
- What did Researcher check
- Writer wrote a draft
- What documents did Builder deliver
- Cordinator updated what status。
It's the role of making more Profile behavior traceable。
When the system is running long, you can look back:
- Who did what when
- Where are the outputs
- Mandate completed。
THIS IS CRITICAL FOR THE LONG-TERM OPC SYSTEM。
3. weekly-review.md: cycled
weekly-review.md is not just a record。
Its role is to translate a week of action into strategy。
It should summarize:
- What's done this week
- What's stuck
- What lessons can be reused
- Which decisions need to be adjusted
- What's the point next week。
A TRULY VALUABLE OPC SYSTEM IS NOT JUST A MISSION, BUT A WAY TO SINK FROM IT。
weekly-reviewed.md is where this is done。
4. memory-routing.md: memory writing rules
mine-routing.md is a core anti-pollution document。
It specifies where different information should be written。
for example:
- role identity written in soul.md
- Long-term user preference for writing USER.md or system/user-profile.md
- role common experience written in memory.md
- Project rules are written in AGENTS.md
- project background written in context.md
- project tasks are written in questions.md
- project process written log.md
- project decision-making is written into articles.md
- interim material written inbox/
- official outputs are written outputs/
- cross-project methodology writing pages/
- source written in raw/。
This set of rules determines whether the system can work in a stable manner over the long term。
5. skill-registry.md: skills inventory
skill-registry.md records what reusable skills are available throughout the system and to whom they should be allocated。
It can prevent a problem:
- All Profiles are equipped with a bunch of skills, and finally the role boundaries are confused again。
for example:
- dashboard-update should only be given to Coordinator
- you should give it to Researcher
- anticle-structure should be given to Writer
- code-builder should be given to Builder。
High-risk skills such as:
- delete-files
- dploy-project
- bulk-memoory-edit
It needs to be strictly limited。
skill-registry.md's role is to make the distribution of capacity manageable。
6. our-profile.md: unified user image
user-profile.md records long-term user preferences that all Profile should know about。
for example:
- User preference for communication in Chinese
- Users prefer straightforward, clear and critical explanations
- Users commonly use Obsidian
- Users like Markdown
- Long-term attention of users Hermes, LLM Wiki, OPC, MultiAgent。
It's not like every Profile's own USER.md。
The USER.md in Profile is the user's understanding of the individual role。
system/user-policy.md is a user image source shared throughout the system。
vi. projects: long-term project layer
system is responsible for global management。
projects are responsible for specific projects。
Each long-term project should have its own project space。
for example:
projects/twitter-rowth/projects/vibe-coding/
Each project space proposal includes:
AGENTS.mdcontext.mdtasks.mdlog.mddecisions.mdinbox/outputs/
AGENTS.md: Project Rules
AGENTS.md explains how Agent should collaborate under this project。
It records:
- Project objectives
- Project positioning
- Rules of procedure
- (a) The document is written to the boundary
- Prohibition。
For example, AGENTS.md, a Twitter Growth project, could provide for:
- The long-term positioning of accounts must be judged when pursuing hot spots
- Researcher's intermediate is written inbox/
- Writer's Structural Program is written inbox/
- Builder's official output is written outputs/
- Cordinator is in charge of updating questions.md and log.md。
AGENTS.md replied:
- What should this project do
2. contact.md: project background
contact.md is the project description。
It replied:
- What is this project
- Why
- What's the target
- What is the current stage
- What are the core constraints
Any Profile should read contact.md before entering the project。
Otherwise, it does not know what it is involved in。
3. task pool of the project
tasks.md records the current task status of the project。
It is usually divided into:
- Doing
- Todo
- Done
It would be best if each mission wrote clearly:
- (a) Mandate number
- Responsible persons
- Current status
- Dependency relationships
- Output path。
This way, Cordinator can manage the project's progress and will not allow tasks to be scattered in chat records。
4. log.md: project progress record
log.md is the advance log for a single project。
It records what happens every day or time on this project。
for example:
- Researcher completed the hotspot study
- Writer completed the article outline
- Builder completed the draft login page
- Cordinator updated the task。
Notice:
the project log is not the same as the item-log。
- project log to record the advance of a project
- angent-log records the overall behaviour of all Profiles。
5. projects.md: project decision-making
data.md records the orientation of the project。
Its role is to prevent the system from swinging。
for example:
- What is content positioning
- WHAT IS THE RANGE OF THE PRODUCT MVP
- What's the technology
- Which directions are clearly not done。
Long-term projects are most afraid of re-decision-making at every dialogue。
it's just to avoid the problem。
6. inbox: intermediate material
inbox/ semifinished, draft, research and unconfirmed conclusions。
for example:
- Hotspot research
- Competition notes
- Draft outline
- Rough thinking
- Subagent output。
these things haven't been identified so they can't go directly into pages/ or outputs/。
the effect of inbox/ is to absorb uncertainty。
7. outputs: official outputs
outputs/ releases elements that have been identified for delivery or use。
for example:
- Final articles
- Draft tweets
- Code results
- (a) Product documentation
- Demo file。
It is simply understood that:
- inbox is intermediate material. outputs are official。
vii. pages: a generic knowledge layer
pages/ inter-project reusable methodology。
for example:
research-methods.mdwringing-methods.mdbuilding-methods.mdcoorden-methods.mdcont-growth-system.mdproject-building-system.md
what's going on
Three conditions must be met:
- Cross-project reuse
- Not an interim conclusion
- Verified or abstracted。
for example:
- Content items should not only pursue hot spots, but also determine whether the hot spots fit in the long term。
this can go to pages/。
However:
- Some of the AI Agent topics today are so hot that you can write a tweet。
this can't go to pages/。
it should go into a specific project inbox/。
pages/ are knowledge layers, not temporary notes。
raw: source layer
raw/ put the source。
for example:
- Papers
- Articles
- Webshot
- Data tables
- Records of meetings。
raw/the principles are:
- Read without change。
It's a fact, not a process layer。
the research material can be extracted from the raw, but not directly altered。
Otherwise you'll lose the original evidence。
ix. assets: material attachment layer
assets/ put non-text material。
for example:
- Pictures
- (a) Structure maps
- (b) Screenshots
- Cover map
- chart。
If the article requires a reference to a picture, put it on:
assets/images/
If it's a schematic, put it on:
i don't know
If it's operational, put it on:
assets/screenshots/
x. archive: archival layer
inactive, obsolete or obsolete content。
for example:
- Old projects
- Old draft
- Abandonment programmes
- Overdue information。
Do not easily delete important elements。
Archive first。
Long-term systems do not maintain order by “cleaning” but by “stratification and archiving”。
XI. Boundary of the Profile Layer and the Wiki Layer
Here we can see clearly:
There is a clear boundary between the Profile and Wiki layers。
Profile is responsible for:
- Who's Agent
- How does Agent run
- What's Agent's experience
- Agent has some skills。
Wiki is responsible for:
- All Agent projects
- Sharing of knowledge
- Source material
- Mission status
- Decision-making records
- Final outputs。
One sentence:
- Profile is an employee. Wiki is the corporate system。
If you write the project in Profile, memory will pollute。
If you write role experiences into the project, knowledge will spread。
if you put the ad hoc material in the pages, long-term knowledge becomes dirty。
So stratification is not formalism。
- Layers are the source of system stability。
How does it work when it is actually used
Speaking of which, many people have a real question:
- It sounds good, but is it a problem to use it on a daily basis
There are two main issues:
- Is there a lot of manual switching
- Too much collaboration
First。
Many Profiles do need to switch, but they don't cut。
The test is simple:
- Change items, not necessarily Profile. Change the role, change the profile。
Researcher, for example, studies Twitter hot spots in the morning, Vibe Coding competitions in the afternoon, both of which are research missions, not necessarily Profile, just Project subject。
But if we move from "checking" to "writing the finals," we should cut it from Researcher to Writer。
So, the key to multi-Profile collaboration is not to cut windows frequently, but to know:
- What role should the current task be entrusted to。
And then the role of Web Ui was obvious。
Use costs would be higher if all terminals were to be cut。
And Web UI is more like a console in which you can easily switch:
- Cordinator
- Researcher
- Writer
- Builder
Terminals are more suitable for system set-up, configuration and debugging。
Web UI is better suited for daily collaboration, toggle Profile, continue sessions。
It is simply understood that:
- The terminal is the construction site. Web Ui is the office. Wiki is a company document。
The second question is the cost of Token。
Many Profile collaborations will be more expensive than single Agent Token。
Because each Profile needs to read its identity, context and Wiki。
The solution is not to give up multi-Profile, but to make layers:
- The main model is responsible for complex reasoning
- Submodels for summary, collation and archiving
- Simple tasks can be given to local models
- Wiki is responsible for the preservation of the long-term context and the avoidance of each repetition。
That means:
- Don't let the model remember everything. To get the model to read the right information on demand。
So, a lot of Profile + Wiki can really run up instead of becoming a high-cost toy。
XIII. CORE CONCLUDING REMARKS OF THE PART
Hermes' advanced use is not to open more Agents, but to use multiple Profiles to divide roles and share memories with Wiki。
The goal of the system is not to be complex, but to allow one person to manage a stable and collaborative team of Agent。
What do I do next
Follow-up, let's:
- Building a system
- Manage multiple applications with Web UI
- Token。