Buffaly can use a growing set of skills, services, actions, and tools. Action loading is the way it turns a plain-language request into a concrete capability it can safely call.
Instead of guessing from a fixed tool list, Buffaly searches for likely actions, resolves the target entity when one is involved, loads the selected action if needed, and then takes the smallest useful next step. This keeps the experience flexible without making the system careless.
Users should not have to know every internal tool name before asking for work. You can ask for an outcome, such as "summarize this file," "deploy the site," or "remember this workflow," and Buffaly can search for the right capability.
Tools are callable capabilities
A tool is a capability Buffaly can call with structured inputs and a defined result, such as reading a file, searching session history, creating an artifact, or calling a service method.
Ask for the outcome first, then let Buffaly choose the tool boundary. If the job involves files, providers, sessions, services, or credentials, include the target and safety constraints so Buffaly can select the most specific available action. For the built-in capability families, see Buffaly default tools.
Discovery before execution
Discovery is the step where Buffaly maps a natural-language request to candidate actions and, when needed, candidate entities.
Good requests name the goal, relevant system, and expected evidence. Buffaly should search or inspect before acting when several tools could apply, and should prefer domain-native actions over generic shell or script execution. Services with multiple related methods are explained in Buffaly services.
Typical discovery flow
- Infer the user's goal and likely target.
- Search for candidate actions with broad wording.
- Search again with more specific wording.
- Resolve candidate entities when the task involves a known object, service, environment, account, or session.
- Load the selected action only when it is not already available.
- Execute one useful step and inspect the result before continuing.
Ask for discovery when it matters
- "Find the right tool for this before doing it."
- "Show me which action you would load for this request."
- "Check whether there is a typed action before using PowerShell."
- "Resolve the target environment first, then deploy."
Loaded action state
Some actions are already available in a session, while others must be loaded after discovery before Buffaly can call them.
If Buffaly says an action is unavailable, the next step is usually to verify the discovered action, load it, or refresh the runtime after a capability change. Users should not need to memorize tool names, but reports should name the action used when that matters for auditability.
When fallback tools are appropriate
Generic command execution is still useful for local diagnostics, repository inspection, validation commands, and one-off work that has no typed capability. Buffaly should prefer typed actions when they exist, but should change approach rather than repeat a stale or unavailable route.
Validation after tool use
Tool output is evidence, not the final proof by itself. Validate important work against the user goal before calling it done.
For read-only work, validation may be citing the inspected file or session result. For edits, it should include a build, test, diff, or other direct check. For external services, validate the account, operation, and failure path before relying on the result.
Verification checklist
- Confirm the selected action matches the user's goal.
- Confirm the target entity, file, account, service, or environment is the intended one.
- Confirm whether the action was already loaded, newly loaded, or unavailable.
- If discovery gives weak matches, refine the wording or list the relevant skill actions before proceeding.