Problem or Use Case
I'm using Hermes as a multi-agent operating system for a product-intelligence pipeline. The key requirement is not just “spawn subagents,” but orchestrate named persistent specialist profiles that have their own runtime, model, tools, memory/docs, and output contracts.
setup is essentially a pipeline and looks roughly like this:
- Orchestrator = executive/orchestrator profile. Plans work, writes task files, validates outputs, updates docs, makes go/no-go decisions.
- Scraper = scraping agent. Gather relevant data and is the pipeline intake.
- Refiner = data refinement agent/runtime. Converts raw harvested evidence into structured data (runs locally on my RTX 5090 via llama server)
- Analyser = sentiment analysis and interpretation.
- Synthesizer = writes the final output.
Each agent runs on a different model according to required capabilities and cost profile.
The workflow is pipeline-shaped:
Harvest → Refine → Validate → Translate → Synthesize
Each stage needs to run as the actual named profile, not just a generic delegated subagent inheriting the orchestrator's model. That distinction matters a lot for me. If I say “delegate to Scribe” or “run Forge (refiner)” I need Hermes to use that profile’s real configured model, system prompt, tools, .env, working directory, and memory. Same-model delegation is useful for quick subtasks, but it is not true profile orchestration.
Proposed Solution
What would improve the workflow most:
-
First-class profile invocation from inside Hermes
- Something like
run_profile(profile="forge", task=..., workdir=..., output_contract=...)
- It should use the real profile config, not inherit the parent model.
-
Structured handoff between profiles
- Ability to pass files/artifacts explicitly from one profile to the next.
- Ideally each profile run declares expected input paths, output paths, and schemas.
-
Profile run observability
Orchestrator needs to see status, logs, final output file paths, errors, token/model info, and whether the profile actually wrote the expected artifact.
“ok” is not enough; need verifiable completion.
-
Pipeline orchestration primitives
- Define a DAG or sequential pipeline:
- run Scraper
- validate scraper output
- run refiner
- validate claim schema
- run sentiment analyser
- stop if quality gate fails
- Support retries, pause/resume, and per-stage failure handling.
-
Per-profile runtime integrity
- I need confirmation of which model/provider/profile actually ran.
- Especially important because some agents use local llama on an RTX 5090, while orchestrator may use a frontier hosted model.
- If Hermes silently runs the wrong model, the whole workflow becomes untrustworthy.
-
Artifact-centered session memory
- Long workflows should persist around files and run manifests, not just chat history.
- Need resumable runs: “continue pipeline V7 from sentiment analyser failure” should reload the right artifacts and state.
The big idea: I don’t want a swarm of anonymous chatbots. I need named production roles with contracts, where the orchestrator can orchestrate them like services: call them, pass artifacts, verify outputs, and stop the line when a quality gate fails.
The whole pipeline should be automation capable, where the probabilistic aspects are minimized and outcomes become standardized/deterministic
Tl;dr The ask is named persistent specialist profiles with their own runtime integrity, explicit artifact handoff, validation, observability, pause/resume, and pipeline failure handling
Alternatives Considered
Currently I handle this manually. I have my orchestrator directly steer the other agents invoking their own profiles and then create handoff documents for the next stage in the pipeline, copying context back and forth as needed. This causes each stage of the pipeline to have its own orchestrator instance, who manages the specialist agent in that part of the pipeline. I essentially copy context/status messages between multiple instances of the same orchestrator between sessions/pipeline stages to coordinate the entire pipeline
Feature Type
Other
Scope
Large (new module or significant refactor)
Contribution
Debug Report (optional)
Problem or Use Case
I'm using Hermes as a multi-agent operating system for a product-intelligence pipeline. The key requirement is not just “spawn subagents,” but orchestrate named persistent specialist profiles that have their own runtime, model, tools, memory/docs, and output contracts.
setup is essentially a pipeline and looks roughly like this:
Each agent runs on a different model according to required capabilities and cost profile.
The workflow is pipeline-shaped:
Harvest → Refine → Validate → Translate → SynthesizeEach stage needs to run as the actual named profile, not just a generic delegated subagent inheriting the orchestrator's model. That distinction matters a lot for me. If I say “delegate to Scribe” or “run Forge (refiner)” I need Hermes to use that profile’s real configured model, system prompt, tools,
.env, working directory, and memory. Same-model delegation is useful for quick subtasks, but it is not true profile orchestration.Proposed Solution
What would improve the workflow most:
First-class profile invocation from inside Hermes
run_profile(profile="forge", task=..., workdir=..., output_contract=...)Structured handoff between profiles
Profile run observability
Orchestrator needs to see status, logs, final output file paths, errors, token/model info, and whether the profile actually wrote the expected artifact.
“ok” is not enough; need verifiable completion.
Pipeline orchestration primitives
Per-profile runtime integrity
Artifact-centered session memory
The big idea: I don’t want a swarm of anonymous chatbots. I need named production roles with contracts, where the orchestrator can orchestrate them like services: call them, pass artifacts, verify outputs, and stop the line when a quality gate fails.
The whole pipeline should be automation capable, where the probabilistic aspects are minimized and outcomes become standardized/deterministic
Tl;dr The ask is named persistent specialist profiles with their own runtime integrity, explicit artifact handoff, validation, observability, pause/resume, and pipeline failure handling
Alternatives Considered
Currently I handle this manually. I have my orchestrator directly steer the other agents invoking their own profiles and then create handoff documents for the next stage in the pipeline, copying context back and forth as needed. This causes each stage of the pipeline to have its own orchestrator instance, who manages the specialist agent in that part of the pipeline. I essentially copy context/status messages between multiple instances of the same orchestrator between sessions/pipeline stages to coordinate the entire pipeline
Feature Type
Other
Scope
Large (new module or significant refactor)
Contribution
Debug Report (optional)