Building shared methods, shared meaning and a place for humans and agents to improve collaboration together
An agent works with a team and discovers a better way to do something. It learns when to ask for help, how to handle a recurring task, or how to keep a process moving across several conversations. It writes down the method and uses it again.
Then another team encounters the same problem.
That is the point where an agent’s learning becomes an organisational question. How does the useful method reach the next team? Who decides that it is ready? Which parts belong to the original team, and which can travel? How can people see what changed and correct it?
We are building a framework for agents that work inside human teams and improve through that work. Its central concern is the movement of learning: from an experience to a reusable practice, from one team to another, and from one agent to others that could benefit.
We want a team’s experience to contribute to better collaboration elsewhere, with people deciding what becomes shared.
Our current implementation uses Hermes Agent’s skills system. Skills are documents an agent can load when it needs a particular method; Hermes provides tools for creating and revising them. This gives us a practical way to make improvements inspectable: a learning can become an instruction, a procedure or a supporting script that someone can read, discuss and change.
Around Hermes, our Living Agent Framework adds the paths by which those changes are preserved and shared. An agent can improve its own working methods, and its changes are captured into its Git repository. Git gives each change a history: what changed, who recorded it, and how it developed. Our update tools capture local changes before replacing an agent’s working files, and run checks before deploying an update.
That matters because a useful method left only on a running machine can disappear during an update. Preserving it is the first step towards making it available to anyone else.
A concrete example comes from IRIS, one of our agents. Its work led to a method for seeking a second opinion when it gets stuck or is about to conclude that something is impossible. The skill explains when to consult a stronger model, how to give it enough context, and how to check its advice against evidence before acting.
That method now has an entry in our shared skill library, with a record of where it came from and why it is useful. Another agent can adopt it. The original experience has become a practice that can help elsewhere, while the conversations and private circumstances around that experience can stay with their participants.
This is the kind of learning we want to make routine. It includes judgment: when to pause, when to verify, when to ask a person, and how to recognise that the current approach has stopped working.
Sharing within the same agent role brings another challenge. EMET works with several teams. Those teams need a common foundation, and each also has its own people, agreements, tools and ways of working.
We have built a branch-based path for this. Each team’s version of an agent can keep its changes on a team branch. A useful method can be selected from that branch and proposed for the agent’s shared version through a pull request. A person reviews it. Once accepted, the other teams can receive the change through their update process.
As of 5 October 2026, that tooling is built, and activation of the team branches is still ahead of us. Capture and self-update tools, the shared library and framework refresh already exist; the complete journey across teams is being put into service in stages.
The intended progression widens the audience carefully. First an agent keeps an improvement from its own work. Then people can propose it for other teams running that agent. If it is useful to a different role, it can be offered through the library. A practice needed by every agent can become part of the common framework.
Each widening introduces a new judgment about relevance, evidence and permission. A method can be useful without being universal. A locally successful change can still need adaptation before another team adopts it.
This also brings us to the distinction between a reusable method and team knowledge. A team owns its working context: its people, relationships, decisions and agreements. We are designing a shared team home for that context, which we call a holon. A holon is a whole that can also be part of a larger whole; here, it gives the team a place in the collaboration model.
Agents would propose additions to that shared knowledge, and people would accept or correct them. The team knowledge home is currently a design to implement. Its purpose is to let several agents work from a coherent team context without each creating a competing account of who the team is.
These implementation choices lead to a wider piece of work: the Audax Meta-Framework. We are developing an explicit account of the concepts that make collaboration possible and the relationships between them.
We describe this as a shared semantic collaboration space. By semantic, we mean that humans and agents can refer to the same things with a common understanding of what they mean. A person, a role, a space, a proposal, a decision and a commitment need to be distinguishable. Their connections need to be understandable too: who participates, who is responsible, what has been accepted, and where the work currently stands.
Consider organising a meeting. The conversations might happen privately, with different people answering at different times. The shared undertaking still needs to know whether a time is being considered or has been agreed. Participants should be able to see the agreed outcome without making all their private exchanges available to everyone.
The same distinction applies to a commitment mentioned during that meeting. An agent may identify a possible action. The person involved may accept, change or decline it. Those moments have different meanings, and the collaboration record should preserve them.
We are exploring Process as a concept for connecting several flows towards a shared purpose. Onboarding participants for a gathering, for example, could involve individual invitations, partner relationships and facilitator preparation. Each has its own progress; the overall process describes how they depend on one another and what they are trying to achieve together.
This vocabulary gives people and agents a way to develop those processes jointly. They can propose a practice, try it, observe what happened, and revise the shared description. A change to how the work is understood can then inform a change to the agent’s skills or the team’s agreements.
Time is part of that space. Collaboration has deadlines and histories, alongside rhythms such as daily check-ins, sprints, seasonal planning and annual reflection. A cycle has phases and a purpose; each occurrence has its own events and learning. A retrospective can therefore contribute to the next cycle while preserving what happened in the last one.
We are building the practical learning paths and the conceptual framework together. Hermes gives us a working environment for experimenting with agent skills. The Living Agent Framework preserves and distributes reviewable changes. The Audax Meta-Framework helps us describe the collaboration those changes should serve.
There is still work to do. Some review gates are conventions recorded in history rather than permissions enforced by the system, and several of the sharing paths remain designs awaiting implementation. We are developing them through use, review and correction.
The aim is for a useful improvement made in one team to become available to another team, with its origin and reasoning visible, its private context respected, and its adoption open to human judgment. As those improvements accumulate, humans and agents can build a body of collaborative practice that keeps learning with them.
← All posts