Hermes Advanced Use: Working with MultiProfile + Wiki Sharing Memory to Build Your OPC Agent Team (Previously)

recent OPC The concept is hot。

One-Person Company, one company。

Its core is not one single-handedness, but one single person who uses multiple Agents to perform one or more complex tasks, like managing a small team。

So the question is:

• How to build a reliable multi-Profile collaborative architecture

I'll show you the article today Hermes Core logic of multiProfile collaboration。

This is not simply a "a few more Agent" but a stable, clear, long-term Agent working system。

EVERYONE WHO WANTS TO DO OPC SHOULD THINK ABOUT IT。

I. WHY USE MORE PROFILE COORDINATION

An Agent can certainly do a lot of things。

It can search for information, write articles, write codes, make drawings, and make a flash drive。

But if all the tasks were given to an Agent, three problems would arise in the long run。

1. The problem of hallucinations

The biggest question for Agent is:

• Write yourself, judge yourself, think you're okay。

So we need to build a system of team operations, and we need to get different people to take on different tasks and look at the same issue from different angles。

for example:

• Researcher is responsible for the facts
• Writer is responsible for expression
• Builder is responsible for this
• Coordinator is in charge of integration。

This makes it easier for the system to detect loopholes and to get into single Agent self-identification。

2. Avoiding contamination of memory

An Agent simultaneously does all the projects, all the links, and memory is easily mixed。

For example, it also remembers:

• The article will tell stories
• The code needs to be operational in priority
• (B) MVPS FOR PRODUCTS
• The research should indicate the source。

These experiences are not wrong in themselves, but they are different mandates, different links, different projects。

if we all blend into one memory, it'll be polluting and contradictory。

The final results are:

• The code is written with content creation habits
• The article is written with the idea of engineering
• The study began earlier。

That's memory pollution。

3. Avoiding confusion about roles

One, Agent, is also responsible for research, planning, writing, implementation, review, replaying, and can easily be confused。

Typical manifestations are:

• When the study began, it began to draw conclusions
• When writing, it rechecks the data
• At the time of the review, it began to defend its own output
• When it comes to project management, it is obsessed with detailed execution。

So, the essence of multiProfile is not "more Agent," but a clearer role boundary。

II. UNDERSTANDING THE FOUR CONTEXTS: PROFILE, SUBAGENT, PROJECT, Wiki

Before we build a team, we have four different concepts:

• Profile
• Subagent
• Project
• Wiki

If the four concepts were mixed, the system behind them would be messy。

1. Profile: long-term staff

Profile can be understood as a permanent employee in the system。

Each Profile is an independent Agent with its own identity, memory, skills and operational configuration。

for example:

• Coordinator is the coordinator
• Researcher is a researcher
• Writer is a writer
• Builder is the builder。

They are not different chat windows for the same Agent, but long-term members of different roles, different duties, different memory boundaries。

So, there's a lot of Profile actually building up an Agent team。

Subagent: Temporary workers

Subagent is temporary Agent。

It's more like an ad hoc assistant who can handle local issues in complex missions。

For example, if you want to write an in-depth article, you can send a couple of sub-agents:

• A CHECK-UP OF TRADITION RAG
• A survey of Agenic RAG
• LLM Wiki
• A check for a logical loophole。

Subagent ends with no permanent personality or memory。

So it can simply be understood that:

• Profile is a permanent employee. Subagent is temporarily outsourced。

3. Project: Project space

Project is the project space for a long-term mission。

If you advance several long-term tasks at the same time, for example:

• Twitter Growth
• Vibe Coding
• Content growth systems
• Product Demo。

Each long-term mission should have its own project space。

Notice:

• When running multiple long-term missions, the key is not to build multi-Profile, but to divide project space first。

Do not copy a package for each item。

The correct approach is:

• The same set of Project Teams that serve multiple projects。

So as to avoid the explosion of the Profile number and long-term memory pollution。

Wiki: Shared memory layer

How does a complex task move forward

The answer is:

• Share Wiki。

Wiki is like a corporate shared document。

Different employees have different brains, but they can synchronize through shared documents:

• Project progress
• Mission status
• Decision-making records
• Knowledge sank。

In Hermes MultiProfile, Wiki is not an ordinary notebook, but an organized, maintenanceable, long-term, shared memory system。

It records:

• Project status
• Progress of the mandate
• Decision-making records
• Research materials
• Final outputs
• General methodology。

So, a stable Agent team is actually made up of multiple Profiles and shared Wikis。

III. The Four Role Model: Organizing like a real company

What about the division of labour

I recommend a four-player model:

• Cordinator
• Researcher
• Writer
• Builder

It's understandable:

• Project Manager
• researcher
• Writer
• engineer

Role 1: Coordinator

Cordinator is the project manager。

Its core functions are:

1. Definition of objectives: Clarify what is ultimately to be achieved。
2. Disaggregation of tasks: Distinction of targets into implementable tasks。
3. Route tasks: judge to whom each task should be entrusted。
4. Summarized results: integration of outputs from different actors into final results。
5. Checking borders: Avoiding memory pollution and document conflict。

Cordinator should not be obsessed with personal research, writing, writing。

Its most important functions are:

• Let the whole system run in order。

Role 2: Researcher

Researcher is a researcher。

Its core functions are:

1. Collection of evidence: information from multiple sources。
2. Source of comparison: Cross-check to ensure reliable information。
3. Marking Uncertainty: Specify which information has not been validated。
4. Refinement of facts: Distinguishing facts, views and assumptions。

A good Researcher can significantly reduce the illusion of the system。

It should not write the final draft or make the final decision。

What it needs to do is to provide reliable raw materials。

Role 3: Writer

Writer is responsible for translating raw materials into clear content。

Its core functions are:

1. Sets the structure of the article。
2. Optimizing expression。
3. Refining main lines and perspectives。
4. It's a good way to make content fit for the target audience。
5. Clarify the concept of complexity。

When Writer is no longer responsible for planning and checking information, its output quality will increase significantly。

Because it can focus on one thing:

• Make it clear。

Role 4: Builder Builder

Builder is more like an engineer。

Its core functions are:

1. Achieved: the plan is translated into a running code, page or system。
2. Debugging: Positioning and repairing problems。
3. Test: Ensure that the output is stable and reliable。
4. Delivery: Generate final available results。

When Builder is no longer responsible for telling stories, doing research, or setting directions, its achievement will also improve。

Because it can focus on landing。

IV. Full workflow

A typical set of multipleProfile streams:

1. Coordinator decomposition and mission planning
2. Researcher collects sources, validates claims
3. Writer translates research findings into clear content
4. Builder is responsible for final realization or delivery
5. Cordinator final check, summarize, archive。

This structure is strong because it reflects real work processes。

In reality, a stabilization team does not allow the same person to be project manager, researcher, writer, engineer and reviewer at the same time。

The same is true of the Agent team。

v. Starting construction of each file

When the role division is determined, you can start building each file。

EachProfile usually contains:

soul.mdUSER.mdmemory.mdconfig.yamlskills/.env

Seeing so many things, a lot of people will be big。

Next, I would like to take the example of Coordinator, who is responsible for each document。

1. soul.md: who is the coordinator

soul.md is the core identity document for Profile。

PROFILE:

• Who is it
• Responsible for what
• What borders are there
• Shouldn't do anything。

For example, Coordinator's soul.md needs clarification:

• It is the coordinator
• It is responsible for the separation of tasks, the planning of projects and the aggregation of results
• it maintains dashboard and angent-log
• It does not carry out research missions directly
• It does not write the final content directly
• It doesn't happen directly to the code。

Notice:

• if you have multiple projects at the same time, do not include specific items in soul.md。

Otherwise, it is highly susceptible to role pollution。

soul.md writes:

• This Agent is who。

No:

• What is this project doing now。

2. USER.md: Who is the user as understood by the Coordinator

USER.md records this Profile understanding of users。

for example:

• User preference for communication in Chinese
• Users like a clearly structured Markdown
• Users do not like generic concepts
• The user wants the output to be suitable for copying to Obsidian。

Notice:

The USER.md here is the "user image understood by the coordinator role" and is not the only user image of the system。

If all Profile shared user images are needed, they should be placed in Wiki:

system/user-profile.md

3. memoory.md: common lessons learned by coordinators

the memory.md records the generic experience that Profile has learned in the long term。

for example:

• Complex tasks should be dismantled
• Not to modify the same official document at the same time
• inbox
• final output re-enters outputs。

But there should be no project-specific experience here。

for example:

• Twitter wrote three tweets today
• Vibe Coding login page completed。

these elements do not belong to memory.md but should be placed in the project space。

i'm sorry.md recorded:

• Common experience, not project status。

4. skills: a pool of facilitators ' skills

skills is a reusable task process。

Cordinator's skills can include:

• Dismantling of tasks
• Project priority judgement
• (a) The production of hand-over orders
• dashboard update
• i'm sorry
• i'm sorry。

these skills specifically serve the role of coordinator。

if some skill is a common skill, like:

• project-content-loader
• i'm sorry。

You can add multiple files list each。

But don't put all the skills into all the Profile。

Otherwise, the role boundaries will be disrupted。

5. config.yaml: how the coordinator works

config.yaml is the running configuration for Profile。

It defines how this Profile works, for example:

• What models are used
• What is the default work directory
• Which documents are allowed to read and write
• whether to automatically load skills
• Which documents cannot be modified。

Notice:

• config.yaml is not the place to write about the mission。

It replied:

• How does this Profile run

No:

• What's this project gonna do

6. .env: coordinator ' s key

.env only put the key。

for example:

• API Key
• Token
• SMTP PASSWORD
• External service vouchers。

.env:

• Project status
• User preferences
• Mission statement
• Articles。

And don't write in:

• i'm sorry
• USER.md
• i'm sorry
• AGENTS.md
• Wiki

Because these files may enter the context of the model。

Previous Summary

Here, the basic setup of the multiple Profile is over。

We did three things:

1. To make it clear why an Agent can't have a full package
2. Distinguishing the concepts of Profile, Subagent, Project, Wiki
3. The role models of Coordinator, Researcher, Writer, Builder。

But it's just a team level。

It is not enough for a team to run on a permanent basis。

It also requires:

• Shared documents
• Project space
• Mission board
• Decision-making records
• Rewind mechanisms。

This is the point of the next issue:

• How to build your OPC shared memory system with Wiki.