The Orchestrator

The question an orchestrator has to answer is: how dynamic is the system under orchestration? How much learning do you encourage and enable, where does the system get to update itself, and where must it wait for a person? The answer differs by system and even by component within a system. A delegated intelligence might be allowed to learn new skills and forbidden to change its own directives, or permitted to add to memory and prohibited from modifying its permission envelope.

3.10.1 Fixed disposition

There is a name for choosing to limit independent learning, and I call it a fixed disposition. A system with a fixed disposition operates inside a set of skills, directives, and permissions that do not change unless a person changes them. It can still be intelligent, still exercise judgment, still chain tools together in ways nobody anticipated. What it does not do is rewrite its own instructions or expand its own authority. The disposition is fixed, the intelligence is delegated, and the authority stays with the person who drew the boundary.

3.10.2 Dynamic disposition

The opposite is a dynamic disposition — a system that can update its skills, refine its directives, and extend its understanding over time. Dynamic systems are more powerful and more dangerous in the same motion. They can improve, and they can also drift, develop habits nobody intended, optimize for the wrong thing, and slowly become something other than what was designed.

Most production systems end up mixed, fixed in some places and dynamic in others, and the orchestrator’s job is to decide where the line falls, make that decision explicit, and make sure the organization understands what was decided and why.

In my own deployments this is a daily decision. In development, I may let a Hermes agent revise a skill as it discovers a better way to work. In my production deployments, the model’s judgment remains dynamic, but the skill is fixed: the agent can use it but is instructed not to rewrite it automatically. Hermes can update skills — its own documentation describes creating, updating, and deleting them, with an optional approval gate for writes — so this is my configuration and instruction, not a default of the platform.⁴ Good orchestrators change a system’s disposition as it matures. Exploration allows more adaptation; production fixes more of the operating method in place.

We already tune service-account permissions this way. A team may begin with enough access to discover what a workload actually needs, observe its real behavior, and then narrow the permissions as the system stabilizes — the maturity path AWS itself describes toward least privilege.⁵ An orchestrator applies the same maturity judgment to an agent’s freedom to change itself.

3.10.3 Learning sources

A second decision follows immediately from the first: if the system is allowed to learn, where is it allowed to learn from?

The question is not trivial. A system that can learn from anything — the open internet, every conversation it observes, every document it touches — is a system being shaped by sources you do not control, and some of those sources are wrong, some are biased, and some are adversarial. A system that learns from uncontrolled sources will eventually come to reflect them, and you will be the one answering for the result.

The alternative is to specify the learning sources explicitly, which means saying something like: this system may learn, but only from feedback provided by me, or by these named individuals, or by people holding a specific role and authority. You are not granting permission to learn. You are granting permission to learn from authoritative sources you have named.

Disposition decides who applies the learning. A fixed system has learning sources too; they simply run through a person. The feedback arrives, the orchestrator reads it, and the update to skills or memory is made by hand — slower, and fully accounted for. A dynamic system applies its learning itself, which is exactly why the sources have to be named in advance: nobody is in the loop to intercept a bad source before it becomes permanent.

I think this is going to be one of the most important standards the industry has to work out. The analogy to people is exact enough to be worth stating. When you delegate work to a person, you do not only tell them what to do; you also tell them who to listen to. A new employee does not learn the company’s approach by asking strangers on the street. They learn from a manager, from teammates, from documentation, from a training program, and from the feedback they receive. Delegated intelligence needs the same thing: not just what to learn, but who it is permitted to learn from.

That is a standard most systems do not currently have. Today learning is essentially binary — the system either updates its memory from everything it sees or it does not update at all — where what is needed is a learning policy specifying which sources are authoritative, what kinds of updates each source can trigger, and what requires human review before it becomes permanent knowledge. The orchestrator writes that policy, the organization owns it, and the system operates inside it.

3.10.4 Learning, then freezing

Neither disposition is a life sentence, and one of the most practical patterns in this book is changing a system’s disposition on purpose.

Run a system dynamic first. Let it learn through several iterations — from your corrections, from the reviewers you have named, from the runs that worked and the runs that did not. Guide it. Each iteration is a chance to catch a habit while it is forming, to correct an approach that is close but wrong, to supply the example that makes the next run better than the last.

Then freeze it. Switch the system to a fixed disposition — skills locked, memory curated, directives settled — and let it run as a system whose operating method no longer changes under it. What the dynamic phase learned is now baked in; what you have given up is the drift, the habits nobody intended, the slow optimization for the wrong thing. The learning is captured. The drift risk is retired — not all variance, because model sampling, tool results, and external data can still change any given run, but the method itself stops moving.

When to make the switch is a judgment call, and the honest trigger is this: freeze when you would rather have predictability than further improvement. While the approach is still being discovered, the dynamic system’s risk pays for itself. Once the approach is known — once the outputs are good enough that you would sign your name to them — the risk stops paying, and the same behavior that looked like learning starts to look like exposure. Production work, compliance work, anything with a customer or a regulator on the other end: fixed-disposition territory. Exploration, drafting, internal tooling, one-off analysis: let it run dynamic and keep watching.

The pattern scales down to a component and up to a fleet. A single skill can be learned dynamically and then locked. A whole system can spend a quarter learning and then ship fixed. What matters is that the transition is deliberate — a decision made by a person, recorded, and reversible by that same person — not something the system drifts into on its own.

---

4. Hermes Agent documentation: “Skills System,” https://hermes-agent.nousresearch.com/docs/user-guide/features/skills (the skill_manage tool can create, update, and delete skills); “Working with Skills,” https://hermes-agent.nousresearch.com/docs/guides/work-with-skills; and the configuration reference, including the optional skill-write approval setting, https://hermes-agent.nousresearch.com/docs/user-guide/configuration. The dev-dynamic/production-fixed arrangement described here is the author’s deployment configuration and instruction, not a Hermes default.↩︎

5. AWS, “Security Best Practices in IAM,” https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html, describing the maturity pattern of granting broader permissions while a workload is being understood and narrowing toward least privilege as the use case matures.↩︎