19aa50a429
build_session_agent_inner took an agent_id: &str parameter but
never threaded it into the Agent::builder() chain — a `let _ =
agent_id;` silenced the unused-variable warning. AgentBuilder::build()
fell back to the legacy "main" default at builder.rs:310-312, so
every session built via Agent::from_config_for_agent carried
agent_definition_name="main" regardless of the id the caller asked
for.
Only two ids reach this path in production: "orchestrator" (legacy
Agent::from_config wrapper, cron, local_ai, escalation) and
"welcome" (channels/providers/web.rs routing after #525/#526, and
welcome_proactive). Orchestrator is benign — "main" was already
an alias for orchestrator everywhere downstream (see debug_dump.rs:249).
Welcome is the visible bug — agent_definition_name feeds three
surfaces that are all silently wrong pre-fix:
1. Transcript filename — welcome sessions land as main_*.md
instead of welcome_*.md.
2. Transcript metadata — the <!-- session_transcript --> block
stamps `agent: main` instead of `agent: welcome`.
3. Transcript resume cross-contamination —
try_load_session_transcript calls
find_latest_transcript(workspace_dir, "main") which scans all
dated session dirs for the latest main_*.md. It finds the
last orchestrator session and resumes from it, loading its
system prompt + user messages + assistant tool-call history
into the welcome agent's `history` as a resume prefix before
run_single runs. The written transcript mixes yesterday's
orchestrator email thread with today's welcome message under
the same main_0.md filename. Reproduced live 2026-04-16: a
welcome_proactive session loaded 5 messages from yesterday's
15042026/main_0.md and wrote 6 messages back that included a
spawn_subagent(skills_agent, toolkit=gmail) tool-call the
welcome agent never made.
Prompt rendering is NOT affected. context/prompt.rs only reads
ctx.agent_id for the is_skill_executor branch at prompt.rs:655, so
welcome/main/orchestrator all fall through the same delegator path.
The welcome persona prompt is rendered by the stamped
SystemPromptBuilder::for_subagent(target_def.system_prompt) built
at session-build time, independent of agent_definition_name. The
pre-fix main_0.md on disk contains `# Welcome Agent\n\nYou are the
Welcome agent...` as its system prompt body — correct content,
wrong filename and metadata.
skills_agent and other typed sub-agents are unaffected — they go
through subagent_runner, which constructs its prompt directly and
writes transcripts under the explicit id it receives. The
pre-existing sessions/15042026/skills_agent_0.md on disk with
`agent: skills_agent` confirms this code path has always been
correct.
Changes:
* src/openhuman/agent/harness/session/builder.rs:
- Add .agent_definition_name(agent_id.to_string()) to the
builder chain in build_session_agent_inner.
- Delete the `let _ = agent_id;` suppression.
- Replace the misleading 8-line comment block at the call site
(which claimed event_channel was for transport identity and
therefore stamping agent_id wasn't needed — conflating two
unrelated fields) with an accurate description of the three
load-bearing surfaces.
- Expand the docstring on AgentBuilder::agent_definition_name
to document the surfaces and the latent prompt-section
foot-gun the fix closes for future code.
- New log::debug! call at the stamping site for grep-friendly
runtime traces ([agent::builder] stamping
agent_definition_name=<id> onto session agent).
* src/openhuman/agent/harness/session/runtime.rs:
- Add pub fn agent_definition_name(&self) -> &str accessor
on Agent so tests and runtime callers can introspect the
stamped id without reaching into the pub(super) field.
* src/openhuman/agent/harness/session/tests.rs:
- Add build_minimal_agent_with_definition_name helper.
- agent_builder_threads_agent_definition_name_when_set —
parameterised over welcome/skills_agent/orchestrator/
trigger_triage, asserts the setter threads the id through.
- agent_builder_falls_back_to_main_when_definition_name_unset
— pins the legacy fallback contract direct builder users rely
on.
Tests: 2 passed; 0 failed; 3477 filtered out; finished in 0.21s.
cargo check --lib clean; cargo fmt clean.
Verified live against G:/projects/vezures/.openhuman on 2026-04-16:
- Pre-fix welcome_proactive run wrote sessions/16042026/main_0.md
with `agent: main` in the metadata header.
- Post-fix welcome_proactive run wrote sessions/16042026/welcome_0.md
with `agent: welcome` in the metadata header.
- Post-fix web-chat dispatch to orchestrator wrote
sessions/16042026/orchestrator_0.md (moved off the historical
main_*.md alias — behaviorally unchanged for orchestrator).
- The new [agent::builder] stamping debug line fires on both
welcome and orchestrator paths.
Does not touch: subagent_runner, spawn_subagent / dispatch_subagent,
any agent/agents/*/agent.toml, any context::prompt code, or the
AgentBuilder::build() fallback itself.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
OpenHuman
The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.
Discord • Reddit • X/Twitter • Docs
"The Tet. What a brilliant machine" — Morgan Freeman as he reminisces about alien superintelligence in the movie Oblivion
Early Beta — Under active development. Expect rough edges.
To install or get started, either download from the website over at tinyhumans.ai/openhuman or run
# For MacOS/Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash
# For Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex
What is OpenHuman?
OpenHuman is an open-source agentic assistant that is designed to integrate with you in your daily life. Here's what makes OpenHuman special:
-
Simple, UI-first — A clean desktop experience and short onboarding paths so you can go from install to a working agent in a few clicks, without a config-first setup. You don't need a terminal to run OpenHuman.
-
One subscription, many providers — You only need one account to get access to many agentic APIs (AI Models, Search, Webhooks/Tunnels and other 3rd party APIs etc..), simplifying the experience to get a powerful agent going.
-
Rich Skills — Plug into Gmail, Slack, Notion, and the rest of your stack via rich, feature-backed skills. Connections are typically one click through setup wizards instead of wiring APIs by hand. Workflow data is kept on device, encrypted locally, and treated as yours: encryption and sensitive context stay on your machine. Webhooks give instant feedback into the agent when external systems or skills emit events, so the loop stays tight without constant polling.
-
Local knowledge base — Built from your data and your activity. How you work across tools, sessions, and connected services—so the agent gets rich, workflow-aware context, not a one-off chat transcript. Everything is stored on your machine and compounding over time without becoming a cloud dossier. Channels, skills and ongoing conversations feed the same loop so day-to-day context does not reset every session.
-
Local AI model — The Rust core exposes local AI paths (and the desktop bundle can ship local/bundled runners where applicable) for the workloads above—vision snippets, speech helpers, summarization, tooling—so sensitive steps can stay off the cloud when you choose.
-
Deep desktop integrations — OpenHuman is a native desktop assistant, not a web-only chat: memory-aware keyboard autocomplete, voice (STT listening and TTS replies), screen intelligence that understands what is on screen and feeds your local context, plus windowing and OS-level permissions—so the agent meets you on the machine, not trapped in a browser tab.
Architecture: docs/ARCHITECTURE.md. Contributor orientation: CONTRIBUTING.md.
OpenHuman vs other agents
High-level comparison (products evolve—verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and ship deep desktop features—not only chat.
| Claude Code/Cowork | OpenClaw | Hermes Agent | OpenHuman | |
|---|---|---|---|---|
| Open-source: Is the codebase open to review? | 🚫 Proprietary client | ✅ MIT License | ✅ MIT License | ✅ GNU License |
| Simple: Is it simple to get started? | ✅ Simple Desktop App + CLI | ⚠️ Terminal first and often complex | ⚠️ Terminal first and often complex | ✅ Simple, Clean UI/UX. Get started within minutes |
| Cost: How expensive is to run? | ⚠️ Subscription + add-on tool/API costs | ⚠️ Tied to models & hosting you choose | ⚠️ Tied to models & hosting you choose | ✅ Cost optimized with the option to run many things locally for free |
| Memory & Knowledge Base (KB): Does the agent know you and your world? | ✅ Built-in memory; mostly chat/session scoped | ⚠️ Has a local memory but often needs plugins for richer behavior | ✅ Self-learning / task loops (typical) | 🚀 Local KB + Self-learning from your activity & data (GMail, Notion etc... via skills) & prompts |
| API spagetti: How complex is it to hook mulitple features together? | 🚫 Claude bill + often extra keys for MCP/tools | 🚫 BYOK / multi-vendor common | 🚫 Multiple providers common | ✅ One account get access to many bundled platform APIs |
| Extensibility: Can you add rich features into it? | ✅ MCP (different model than sandboxed skills) | ✅ Plugin Architecture (SKILL.md) | ✅ Plugin Architecture (SKILL.md) | 🚀 Rich Skills with ability to have realtime updates, local DB & more |
| Desktop integrations: Can it integrate into your desktop completely? | ⚠️ Desktop app & access to folders | ⚠️ Often lighter native surface | ⚠️ Often lighter native surface | ✅ STT, TTS, screen intelligence, memory-aware autocomplete and a whole lot more |
Contributors Hall of Fame
Show some love and end up in the hall of fame