I published a small Arslan plugin example: knowledge-graph memory, Brave Search and a structured research skill. It raises a question worth returning to: when someone connects a capability, what exactly have they agreed to?
An interface that only says “connected” may omit the part the user most needs to understand.
Separate the actions that mean different things
Discovering a tool, reading its configuration, starting a service and authorizing an agent to use it are different actions. They can belong to one smooth flow while retaining their distinct meanings.
The example manifest describes launch commands, required credential fields and skill locations. Users enter keys locally. Reading the configuration does not start the service; connecting it does. Specialist agents get access through a separate switch.
That distinction keeps curiosity about a tool from silently becoming permission for every agent to use it.
More controls can mean less understanding
Asking for confirmation at every step adds reading and decision work. Repetitive prompts can bury the decision that actually deserves attention.
I would not judge a permission interface by its number of buttons. I would ask whether a step introduces an unexpected change: what will be read, what might be altered and whether the effects can be undone.
Consider a hypothetical research workflow. Searching public pages, reading a personal knowledge base and sending the resulting report outside the system have different consequences. A single “allow tools” choice explains very little about those differences.
Boundaries need to survive delegation
A multi-agent system makes this concrete. If someone gives the host agent a capability, does that automatically let it pass the same capability to any specialist?
The plugin example makes that choice visible through a separate switch. It does not settle every question about delegation. A good interface should also help someone see who currently has access, why it is needed and where it can be stopped.
These are criteria I would use to assess the design. The existence of a switch does not establish that all of them have been met.
Successful connection is the beginning
Tools fail, credentials expire and people change their minds. If a product explains how to connect but leaves disconnection and its consequences unclear, the user still has limited control over their environment.
I would rather evaluate the experience by whether someone can anticipate the next action and recover when something goes wrong.
As a system gains capabilities, that understanding becomes more valuable. It gives people a reason to keep using the system, with boundaries they can understand.