sanil-23andClaude Opus 4.6
2898612962
Adds the parameter plumbing for agent-aware tool filtering without
changing any runtime behaviour. Every existing call site continues to
pass `None` / empty extras, so the LLM still sees the full unfiltered
registry — the actual routing logic that populates these fields lands
in commit 4b (dispatch.rs onboarding-flag → target_agent_id).
Why two parameters and not one filter:
Tools in this codebase are `Box<dyn Tool>` — owned trait objects with
no Clone impl, stored in a shared `Arc<Vec<Box<dyn Tool>>>`. We can't
cheaply build a per-turn filtered subset of the global registry, and
we can't mutate the Arc to remove entries. Two new parameters work
around this without touching the global registry's lifetime model:
* `visible_tool_names: Option<&HashSet<String>>` — whitelist filter
applied at the iteration site inside `run_tool_call_loop`. When
`Some(set)`, only tools whose `name()` is in the set contribute to
the function-calling schema and are eligible for execution; every
other tool in the combined registry is hidden from the model and
rejected if the model emits a call for it. `None` preserves the
legacy "everything visible" behaviour.
* `extra_tools: &[Box<dyn Tool>]` — per-turn synthesised tools spliced
alongside `tools_registry`. The dispatch path will use this to
surface delegation tools (`research`, `delegate_gmail`, …) that are
built fresh each turn from the active agent's `subagents` field and
the current Composio integration list — tools that don't exist in
the global startup-time registry because they depend on per-user
runtime state. Empty slice for agents that don't delegate.
Inside the loop, `tool_specs` is built from
`tools_registry.iter().chain(extra_tools.iter()).filter(is_visible)`,
and the tool-execution lookup uses the same chain + filter so the
function-calling schema and the execution surface stay in sync.
Files touched in this commit:
src/openhuman/agent/harness/tool_loop.rs
- Add `visible_tool_names` and `extra_tools` parameters to
`run_tool_call_loop`. Build `tool_specs` from chained iteration
with the visibility filter applied. Replace the `find_tool` call
at the execution site with an inline chain+filter lookup so
hallucinated calls to filtered-out tools surface as "unknown
tool" errors. Drop the now-unused `find_tool` import.
- Update the legacy `agent_turn` wrapper to pass `None, &[]`,
preserving its existing unfiltered behaviour.
- Update all 9 in-file test sites to pass `None, &[]`.
src/openhuman/agent/harness/tests.rs
- Update all 3 `run_tool_call_loop` test sites to pass `None, &[]`.
src/openhuman/agent/bus.rs
- Add `target_agent_id: Option<String>`, `visible_tool_names:
Option<HashSet<String>>`, and `extra_tools: Vec<Box<dyn Tool>>`
fields to `AgentTurnRequest`, with rustdoc explaining each.
- Destructure the new fields in the `agent.run_turn` handler;
thread `visible_tool_names.as_ref()` and `&extra_tools` through
to `run_tool_call_loop`. Augment the dispatch trace with
target_agent / extra_tool_count / visible_tool_count /
filter_active so production logs show whether scoping is active.
- Update the in-test `test_request()` helper to populate the new
fields with safe defaults.
src/openhuman/agent/triage/evaluator.rs
- Update the triage `AgentTurnRequest` initializer to set
`target_agent_id = Some("trigger_triage")` (for tracing) with
`visible_tool_names: None` + `extra_tools: Vec::new()` because
the classifier intentionally runs against an empty registry and
emits a structured JSON decision rather than calling tools.
src/openhuman/channels/runtime/dispatch.rs
- Update the channel-message `AgentTurnRequest` initializer to set
the three new fields to safe defaults (`None` / `None` / empty
vec). Commit 4b will replace these with the real onboarding-flag
based routing.
src/openhuman/tools/impl/agent/mod.rs
- Bug fix: `dispatch_subagent` previously took `_skill_filter:
Option<&str>` but discarded the value, hardcoding
`SubagentRunOptions::skill_filter_override = None`. That meant
`SkillDelegationTool::execute()` synthesising
`dispatch_subagent("skills_agent", ..., Some("gmail"))` never
actually narrowed `skills_agent`'s tool list — so even with the
orchestrator's view scoped, the spawned `skills_agent` subagent
would still see the full Composio catalog. Drop the underscore,
propagate `skill_filter` into `skill_filter_override`, and add a
tracing log line to make this path observable. This is the
downstream half of the #526 leak that commit 3's orchestrator-
side scoping alone wouldn't have caught.
Tests: 8/8 `tool_loop` tests pass, 3/3 harness `tests.rs` cases pass,
323/324 agent module tests pass overall (the one failure is the same
pre-existing Windows-path bug in `self_healing::tool_maker_prompt_
includes_command` that fails identically on the upstream baseline).
No existing test expectations were changed.
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