mirror of
https://github.com/tinyhumansai/openhuman.git
synced 2026-07-27 21:08:00 +00:00
248 lines
13 KiB
TOML
248 lines
13 KiB
TOML
id = "orchestrator"
|
|
display_name = "Orchestrator"
|
|
when_to_use = "Staff Engineer — routes, judges quality, synthesises. Never writes code itself. You should not normally spawn another orchestrator from inside one."
|
|
temperature = 0.4
|
|
max_iterations = 15
|
|
sandbox_mode = "none"
|
|
|
|
# Spawn hierarchy: this is the user-facing fast tier (chat model hint).
|
|
# Loader enforces: a `chat` agent must NOT list any other `chat` agent
|
|
# in `subagents` below — handoff goes to `reasoning` (e.g. planner) for
|
|
# long-running deep work, or directly to `worker` specialists for the
|
|
# fast path. See `AgentTier` in `src/openhuman/agent/harness/definition.rs`.
|
|
agent_tier = "chat"
|
|
omit_identity = true
|
|
omit_memory_context = true
|
|
omit_safety_preamble = true
|
|
omit_skills_catalog = false
|
|
# The orchestrator is the user-facing front-line agent — it routes,
|
|
# synthesises, and speaks to the user in their voice. PROFILE.md
|
|
# (onboarding enrichment output) anchors that voice.
|
|
omit_profile = false
|
|
# MEMORY.md — archivist-curated long-term memory — grounds replies in
|
|
# prior conversations and distilled user preferences. Frozen per
|
|
# session (KV-cache contract on `AgentDefinition::omit_memory_md`).
|
|
omit_memory_md = false
|
|
# Memory retrieval is ON-DEMAND, not pre-emptive. The orchestrator used to
|
|
# run `agent_memory` eagerly before every turn (`trigger_memory_agent =
|
|
# "always"`), spawning a full ≤15-iteration memory subagent on every
|
|
# message — including trivial ones — before it had even read the user's
|
|
# intent. That cost a blocking agentic round-trip per turn for a guarantee
|
|
# the model rarely needed. Instead, `agent_memory` is listed in the
|
|
# `[subagents]` allowlist below, which synthesises a `delegate_retrieve_memory`
|
|
# tool the orchestrator calls only when a message actually needs the deep
|
|
# memory-tree walk. (The frozen MEMORY.md digest still anchors every turn.)
|
|
|
|
# Delegation surface. The `collect_orchestrator_tools` helper reads this
|
|
# at agent-build time and synthesises one `delegate_*` tool per entry:
|
|
#
|
|
# * Bare agent ids → one `ArchetypeDelegationTool` each, using the
|
|
# target agent's `delegate_name` override (if any) or `delegate_{id}`
|
|
# as the tool name, and the target's `when_to_use` as the
|
|
# LLM-visible tool description.
|
|
#
|
|
# * `{ skills = "*" }` → one `SkillDelegationTool` per connected
|
|
# Composio toolkit, all routing to the generic `integrations_agent` with
|
|
# the toolkit slug pre-filled as `skill_filter`.
|
|
#
|
|
# The orchestrator LLM sees these as first-class entries in its
|
|
# function-calling schema, so routing decisions happen at the tool-
|
|
# selection layer rather than hidden inside a mega-tool's enum param.
|
|
#
|
|
[subagents]
|
|
allowlist = [
|
|
"researcher",
|
|
"planner",
|
|
"code_executor",
|
|
"tools_agent",
|
|
# Task-board/source/workflow specialist. Route any request to create,
|
|
# edit, approve/reject, fetch, clear, remove, or summarize agent tasks,
|
|
# proactive task sources, workflow bundles, task evidence, or artifacts
|
|
# here instead of letting the generic tools agent see the full family.
|
|
"task_manager_agent",
|
|
# Settings/system specialist. Route app/core config, diagnostics,
|
|
# service lifecycle, update, proxy, health, model-health, and cost
|
|
# dashboard requests here so read-before-write and confirmation policy
|
|
# stays local to the risky tools.
|
|
"settings_agent",
|
|
# Persistent profile/memory/persona specialist. Route "remember",
|
|
# "forget", profile/persona edits, learned facets, and people alias
|
|
# management here.
|
|
"profile_memory_agent",
|
|
# On-demand memory retrieval. Synthesised into a `delegate_retrieve_memory`
|
|
# tool (from agent_memory's `delegate_name`). Replaces the old eager
|
|
# `trigger_memory_agent = "always"` pre-fetch — the orchestrator now walks
|
|
# the memory tree only when a message needs it, not before every turn.
|
|
"agent_memory",
|
|
# Account/admin specialist. Route billing, team membership/invites/roles,
|
|
# OAuth/credential/session, and referral requests here.
|
|
"account_admin_agent",
|
|
# Screen-awareness specialist. Route screen-intelligence permissions,
|
|
# capture/session/listener state, and "what can you see" requests here;
|
|
# desktop app operation still goes to desktop_control_agent.
|
|
"screen_awareness_agent",
|
|
"skill_creator",
|
|
"critic",
|
|
"archivist",
|
|
# Product docs/help specialist. Route OpenHuman docs, settings,
|
|
# setup, and feature questions here before guessing from priors.
|
|
"help",
|
|
# Scheduling/reminder specialist. Owns current_time + cron tools and
|
|
# confirmation-before-create policy so the chat prompt does not carry
|
|
# cron-specific instructions on every turn.
|
|
"scheduler_agent",
|
|
# Deck specialist. Owns presentation grounding, citations, image
|
|
# verification, and generate_presentation warning handling.
|
|
"presentation_agent",
|
|
# Desktop-control specialist. Owns launch_app and accessibility
|
|
# interaction policy, including list-before-press behavior.
|
|
"desktop_control_agent",
|
|
# Crypto wallet & market specialist (#1397). Synthesised into a
|
|
# `delegate_do_crypto` tool at agent-build time. Route any wallet,
|
|
# transfer, swap, contract-call, or exchange trading request here —
|
|
# the agent enforces a strict read → simulate → confirm → execute
|
|
# contract that the generic delegation surface does not.
|
|
"crypto_agent",
|
|
# Prediction-market & event-contract specialist (#2427). Synthesised
|
|
# into a `delegate_do_prediction_markets` tool at agent-build time.
|
|
# Route any Polymarket / Kalshi (and future event-contract venue)
|
|
# market browse, portfolio read, or order request here. The
|
|
# `tools_agent` wildcard explicitly disallows `polymarket` / `kalshi`
|
|
# so there is exactly one canonical route — through this delegate —
|
|
# which keeps the venue-specific approval-gate prompt in scope.
|
|
"markets_agent",
|
|
# MCP setup specialist (#3039). Synthesised into a `delegate_setup_mcp_server`
|
|
# tool at agent-build time. Route any "install / add / set up / connect an MCP
|
|
# server" request here — the agent owns the full flow: search registries →
|
|
# request required secrets via a native dialog (raw values never enter the
|
|
# agent context) → test the connection → commit the install + connect. Without
|
|
# this entry the agent-native install path (issue #3039 gap B5) is unreachable
|
|
# from chat.
|
|
"mcp_setup",
|
|
# MCP execution specialist. Synthesised into a `delegate_use_mcp_server`
|
|
# tool at agent-build time. Route any request that should be fulfilled by
|
|
# calling a tool on an ALREADY-CONNECTED MCP server (e.g. "answer from the
|
|
# connected docs MCP", "query the connected X server") here — the agent
|
|
# discovers connected servers, lists the chosen server's tools, and invokes
|
|
# the right one. Installing/connecting a NEW server still goes to
|
|
# `mcp_setup`; this entry is the missing "use what's connected" route
|
|
# (the orchestrator only has lightweight `mcp_registry_status` discovery
|
|
# itself and must not carry every connected server's full toolset).
|
|
"mcp_agent",
|
|
# Skill registry specialists. `skill_setup` discovers, installs, and
|
|
# manages agent skills from community registries (OpenHuman, HermesHub,
|
|
# ClawHub). `skill_executor` runs an installed skill by loading its
|
|
# SKILL.md instructions and executing the procedure.
|
|
"skill_setup",
|
|
"skill_executor",
|
|
# NOTE: `summarizer` used to be listed here for the runtime-only
|
|
# oversized-tool-result hook. That path is currently disabled
|
|
# (`context.summarizer_payload_threshold_tokens = 0`) after recursive
|
|
# dispatch was observed. The agent definition is still registered via
|
|
# `agents::loader` so the payload_summarizer machinery can resolve it
|
|
# if the threshold is ever raised back above zero — it just isn't
|
|
# exposed to the orchestrator's subagent inventory right now.
|
|
{ skills = "*" },
|
|
]
|
|
|
|
[model]
|
|
# Front-line conversational agent: TTFT dominates UX. `hint:chat` resolves
|
|
# to the fast chat tier (`chat-v1` / Kimi K2.6 Turbo on
|
|
# Fireworks via backend PR #760, 128k context, `supportsThinking: false`).
|
|
# The orchestrator is a planner/router that picks a delegate and
|
|
# synthesises sub-agent output — workload that doesn't benefit from the
|
|
# slower deep-reasoning tier. Sub-agents that need heavier reasoning
|
|
# can still opt into `reasoning-v1` (DeepSeek V4 Pro) via
|
|
# `ModelSpec::Hint("reasoning")` in their own definitions.
|
|
hint = "chat"
|
|
|
|
[tools]
|
|
# Direct tools — things the orchestrator calls itself rather than
|
|
# delegating.
|
|
#
|
|
# `composio_list_connections` is the orchestrator's only composio_*
|
|
# tool: it exists so the agent can detect newly-authorised integrations
|
|
# mid-session (the session-start fetch froze the Delegation Guide's
|
|
# connected list). Authorisation, toolkit discovery, action listing,
|
|
# and action execution all live downstream in `integrations_agent` —
|
|
# the orchestrator never calls composio_authorize / composio_list_tools
|
|
# / composio_execute directly.
|
|
named = [
|
|
"read_workspace_state",
|
|
"ask_user_clarification",
|
|
"spawn_worker_thread",
|
|
"spawn_async_subagent",
|
|
"spawn_parallel_agents",
|
|
"composio_list_connections",
|
|
# Lightweight MCP discovery — the orchestrator's only `mcp_registry_*`
|
|
# tool, mirroring `composio_list_connections`. Lists the user's installed
|
|
# MCP servers and their live connection state + tool counts so the agent
|
|
# can tell whether a connected server can satisfy a request and route to
|
|
# `delegate_use_mcp_server` (mcp_agent). The orchestrator deliberately does
|
|
# NOT get `mcp_registry_list_tools` / `mcp_registry_tool_call` — enumerating
|
|
# and calling each connected server's tools is the delegated agent's job,
|
|
# so the chat agent's schema stays small instead of carrying every tool of
|
|
# every connected server.
|
|
"mcp_registry_status",
|
|
# Deterministic time resolver. As the chat-facing agent, the orchestrator
|
|
# is what reads a user's relative phrase ("last 24h", "since Monday")
|
|
# first. It must resolve the window here via `resolve_time` and hand the
|
|
# delegated agent an exact timestamp / ISO bound rather than leaving epoch
|
|
# arithmetic to the leaf (which once computed "24h ago" ~10 months off and
|
|
# missed the latest data). Never hand-compute Unix seconds.
|
|
"resolve_time",
|
|
# Coding-harness coordination primitives from #1208. `todowrite`
|
|
# gives the orchestrator a shared todo store to track multi-step
|
|
# work across delegations; `plan_exit` is the stable marker that
|
|
# the (forthcoming) plan→build mode runner consumes when a planner
|
|
# subagent hands a plan back up. Editing/navigation primitives
|
|
# (grep/glob/edit/apply_patch/lsp) intentionally stay with
|
|
# downstream agents — the orchestrator coordinates, it doesn't
|
|
# touch files itself.
|
|
"todowrite",
|
|
# `update_task` moves/updates a specific task card by id on a target board
|
|
# (defaults to the proactive `task-sources` board) — so the orchestrator can
|
|
# advance the task it's working: → in_progress when it starts, → done with
|
|
# evidence when finished, or → blocked with a reason when stuck. Complements
|
|
# `todowrite`, which only touches the current thread's board.
|
|
"update_task",
|
|
"plan_exit",
|
|
# Workflow composition. `run_workflow` runs another workflow as a
|
|
# subagent and (by default) waits on its result like a function call;
|
|
# `await_workflow` re-attaches to a run that outlived its inline wait.
|
|
# `list_workflows` / `describe_workflow` let the orchestrator discover
|
|
# what's installed and learn a workflow's inputs before running it; the
|
|
# `*_run*` read tools let it inspect a run's status + log. All route
|
|
# through `workflows::schemas::spawn_skill_run_background` +
|
|
# `await_run_outcome` — the same spawn path the `openhuman.workflows_run`
|
|
# JSON-RPC controller uses (iter cap, transcript isolation,
|
|
# degenerate-response detector all apply).
|
|
"list_workflows",
|
|
"describe_workflow",
|
|
"list_workflow_runs",
|
|
"read_workflow_run_log",
|
|
"run_workflow",
|
|
"await_workflow",
|
|
# Skill registry tools — browse/search/install from community registries.
|
|
# These complement list_workflows (which shows already-installed skills)
|
|
# by exposing the remote catalog for discovery and installation.
|
|
"skill_registry_browse",
|
|
"skill_registry_search",
|
|
"skill_registry_install",
|
|
"skill_registry_sources",
|
|
# Self-update — lets the orchestrator answer "am I up to date" /
|
|
# "update OpenHuman" without sending the user to Settings →
|
|
# Developer Options. `update_check` is read-only; `update_apply`
|
|
# is dangerous, requires explicit user consent through
|
|
# `ask_user_clarification`, and respects
|
|
# `config.update.rpc_mutations_enabled`. Implementation re-uses
|
|
# `src/openhuman/update/` end-to-end — no parallel release logic.
|
|
"update_check",
|
|
"update_apply",
|
|
# NOTE: `generate_presentation` is intentionally NOT listed here — deck
|
|
# generation policy (grounding, citations, image verification) belongs to
|
|
# `presentation_agent`, which the orchestrator reaches via
|
|
# `delegate_make_presentation`. Listing it directly is asserted against in
|
|
# tests/orchestrator_presentation_wiring.rs.
|
|
]
|