Skip to content

[Feature] First-class agent taxonomy on Agent/AgentBuilder; colocate plan, orchestrator, and prompt factories under agent/agent #478

Closed

Description

@senamakel

Summary

Define a first-class taxonomy of agents (core, research, communication, automation, planner/orchestrator, etc.) that all build on the existing Agent / AgentBuilder types in src/openhuman/agent/agent/types.rs. Planning, orchestration, and system-prompt construction for these agents should live alongside that type under src/openhuman/agent/agent/ (with clear submodules), instead of spreading orchestration-only logic across unrelated trees.

User-visible outcome: predictable agent roles, easier testing, and a single place for contributors to see how each agent is built and which prompts it uses.

Problem

Today the runtime Agent struct is well-factored (types, builder, turn, runtime per agent/mod.rs), but multi-agent behavior (archetypes, orchestrator DAG, sub-agent runs) largely lives under src/openhuman/agent/harness/, while prompt assembly is split across prompt.rs (e.g. SystemPromptBuilder, archetype sections) and markdown under agent/prompts/.

That split makes it hard to answer:

  • “What agents exist, and how do they differ?”
  • “Where is the orchestrator’s plan defined relative to the main Agent?”
  • “How do we create prompts per agent kind in one coherent pipeline?”

New roles (e.g. planner-only, evaluator, handoff targets) risk ad hoc wiring instead of extending the same Agent/AgentBuilder foundation.

Solution (optional)

  1. Agent kinds / registry — Introduce an enum or registry (e.g. AgentKind) that maps each product role to:

    • AgentBuilder defaults (tools subset, temperature caps, iteration limits where applicable)
    • Prompt recipe (which SystemPromptBuilder sections / archetype markdown files)
    • Optional orchestration profile (participant in DAG vs single-turn primary)
  2. Colocate under agent/agent/ — Add focused modules, for example:

    • agent/agent/plan.rs — planning steps / structured plan output types consumed by orchestration
    • agent/agent/orchestrator.rs — topology and handoff rules (migrate or thin-wrap today’s harness/executor + config)
    • agent/agent/prompts.rs (or prompt_factory.rs) — factory that builds SystemPromptBuilder (or equivalent) per AgentKind, reusing existing prompt.rs primitives

    Keep types.rs as the single structural definition of Agent / AgentBuilder; behavior stays in sibling files per existing pattern.

  3. Inheritance / composition — Prefer composition: specialized agents are Agent instances built via shared AgentBuilder helpers, not parallel structs, unless a trait boundary is needed for testing (e.g. trait RunnableAgent implemented only by Agent).

  4. Migration — Incrementally move orchestrator entrypoints and archetype resolution so openhuman::agent::agent is the public conceptual home; harness can become a thin compatibility layer or be merged.

  5. Docs — Update agent/mod.rs file-layout table and docs/ or AGENTS.md to describe agent kinds and prompt wiring.

Acceptance criteria

  • Types — All specialized agents remain instances of (or thin wrappers around) Agent / AgentBuilder defined in types.rs; no duplicate “second agent struct” without justification.
  • Registry — Documented list of agent kinds with stable names, mapped to prompt sources and tool/memory policies.
  • Colocation — Plan and orchestrator logic (or facades) live under src/openhuman/agent/agent/ with module-level docs explaining call graph from turn / RPC entrypoints.
  • Prompt creation — A single documented path for “build system prompt for agent kind X” (factory or builder extension), aligned with packaged + optional overlay prompts.
  • Tests — Unit or integration tests that at least one secondary kind builds, runs a minimal turn (or dry-run), and loads the expected prompt sections.
  • No silent behavior drift — Orchestrator enablement and defaults remain explicit in config; migration notes if RPC or CLI surface changes.

Related

Activity

  1. senamakel commented on Apr 10, 2026

    @senamakel
    MemberAuthor

    Follow-up: agent roles (for #478 / future taxonomy)
    For the first-class agent work on Agent / AgentBuilder (see #478), we can model several focused agents, for example:

    Skills agent — Invoked with a skill id plus a concrete instruction (e.g. send an email, run a specific tool path). Narrow surface, predictable I/O.
    Global search agent — Retrieves information from the open web via search engines (and similar retrieval), for facts and sources outside the workspace.
    Local search agent — Searches inside the product/workspace: files, indexed content, app state—not the semantic memory layer by default (unless we define it that way).
    Memory agent — Owns Neocortex / recall / queryMemory flows: ingest, sufficiency checks, semantic retrieval, and applying memory context to replies.
    …and so on — Same pattern: small agents with clear inputs, each built from the shared Agent type and a dedicated prompt + tool allowlist.
    This keeps orchestration explicit: a planner/orchestrator can route to these agents without bloating a single system prompt.

  2. moved this from Todo to Done in Team Openhumanon Apr 14, 2026
  3. closed this as completedby moving to Done in Team Openhumanon Apr 14, 2026
  4. added theissue type on Aug 9, 2026
  5. added a commit that references this issue on Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions