Skip to content

[Feature]: Multi-agent orchestration pipeline #18420

@D1rk-D1ggler

Description

@D1rk-D1ggler

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:

  1. 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.
  2. 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.
  3. 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.

  4. 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.
  5. 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.
  6. 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

  • I'd like to implement this myself and submit a PR

Debug Report (optional)

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havecomp/agentCore agent loop, run_agent.py, prompt buildertool/delegateSubagent delegationtype/featureNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions