Allow an embedded agent widget to limit which tools it can call #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We would like to embed the agent widget on an operator admin dashboard where it can run deployer actions through its tools, including some that delete machines or user accounts. For safety we want a way for an embed to declare which tools the assistant is allowed or not allowed to use, so we can give it read and create actions while keeping destructive ones such as delete out of reach. The agent already stores allowed and disallowed tool lists and passes them to the CLI, so this might just be exposing those to the widget or to agent.start per embed. As a later optional step, a confirm before acting mode (the assistant shows what it will do and waits for a yes before anything that changes state or costs money, while reads stay free) would let us enable the assistant on less trusted surfaces too. Could you add the per embed tool limiting, and roughly how would you approach it? Thanks!
Signed-by: mik-tf mik-tf@noreply.invalid
Update after wiring this widget into our admin dashboard and a tester cockpit. We deployed the orchestrator and the agent widget on a live admin machine using the kimi backend, and chat plus voice both work well. The blocker for the acting part is that agent.start rejects mcp_services for any non-claude backend (the agent code notes opencode and codex MCP wiring as future work). In our setup the assistant has to run on the kimi backend, because we cannot place an admin Claude Code login on a tester machine, so right now the assistant can talk but cannot call tools. What would it take to let the kimi backend use MCP tools the way the claude backend does, so the assistant can actually act (for example run a deployer action, or act on a tester's own apps)? Even a rough scope helps us plan around it. The original request in this issue, letting an embed restrict which tools it may call, becomes the next step once kimi can use tools at all. Thanks!
Signed-by: mik-tf mik-tf@noreply.invalid
For reference, our changes are pushed on the branch main_mik (not merged into your trunk, so you can review, take, or drop them freely): default-backend attribute on the agent widget, and a KIMI_API_KEY env declaration on hero_orchestrator_server so a hero_proc-managed daemon receives the seeded key and the spawned hero_kimi_agent can authenticate. Both build clean and are running live on our admin machine (chat plus voice work; only the tool-acting part waits on the kimi MCP question above). Branch: https://forge.ourworld.tf/lhumina_code/hero_orchestrator/src/branch/main_mik
Signed-by: mik-tf mik-tf@noreply.invalid
Heads-up on publishing: your lab-publish workflow triggered only on development, and the recent development publishes have been failing, so the released latest was a month behind. To unblock fresh installs I added main to the trigger branches (branches: [main, development]), matching cockpit and deployer, and a publish from main is now running. Your development publishes are still failing separately and probably want a look. If you would rather publish only from development, feel free to revert that one-line change once development is green again. The functional commits (default backend attribute, KIMI_API_KEY env) are on main and the main_mik branch as before.
Signed-by: mik-tf mik-tf@noreply.invalid