Repository navigation
[Feature] First-class agent taxonomy on Agent/AgentBuilder; colocate plan, orchestrator, and prompt factories under agent/agent #478
Description
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)
-
Agent kinds / registry — Introduce an enum or registry (e.g.
AgentKind) that maps each product role to:AgentBuilderdefaults (tools subset, temperature caps, iteration limits where applicable)- Prompt recipe (which
SystemPromptBuildersections / archetype markdown files) - Optional orchestration profile (participant in DAG vs single-turn primary)
-
Colocate under
agent/agent/— Add focused modules, for example:agent/agent/plan.rs— planning steps / structured plan output types consumed by orchestrationagent/agent/orchestrator.rs— topology and handoff rules (migrate or thin-wrap today’sharness/executor+ config)agent/agent/prompts.rs(orprompt_factory.rs) — factory that buildsSystemPromptBuilder(or equivalent) perAgentKind, reusing existingprompt.rsprimitives
Keep
types.rsas the single structural definition ofAgent/AgentBuilder; behavior stays in sibling files per existing pattern. -
Inheritance / composition — Prefer composition: specialized agents are
Agentinstances built via sharedAgentBuilderhelpers, not parallel structs, unless a trait boundary is needed for testing (e.g.trait RunnableAgentimplemented only byAgent). -
Migration — Incrementally move orchestrator entrypoints and archetype resolution so
openhuman::agent::agentis the public conceptual home;harnesscan become a thin compatibility layer or be merged. -
Docs — Update
agent/mod.rsfile-layout table anddocs/orAGENTS.mdto describe agent kinds and prompt wiring.
Acceptance criteria
- Types — All specialized agents remain instances of (or thin wrappers around)
Agent/AgentBuilderdefined intypes.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 fromturn/ 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
src/openhuman/agent/agent/types.rs—Agent,AgentBuildersrc/openhuman/agent/agent/mod.rs— module layoutsrc/openhuman/agent/harness/— current orchestrator / archetypes / subagent runner- Prompt markdown:
src/openhuman/agent/prompts/,SystemPromptBuilderinprompt.rs - Optional overlap: multi-agent / self-reflection issues if planner agents are added later
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
senamakel commentedon Apr 10, 2026
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.
feat(agent): pure orchestrator pattern with per-skill delegation tools (
feat(agent): pure orchestrator pattern with per-skill delegation tools (
feat(agent): pure orchestrator pattern with per-skill delegation tools (
feat(agent): pure orchestrator pattern with per-skill delegation tools (
Merge pull request #478 from senamakel/epic-8000-host-94-backfill-import