Aclif's deny-before-load gate trusts whatever the provider author declared

Binding a command at design time is the trade-off this design lives on. A person or an authoring tool discovers a provider, inspects a command, and embeds the resulting command string in the workflow ^[11]. At runtime that string executes without loading a tool definition and without asking a model to choose the operation again, and inference stays available for the steps that need judgment ^[12]. In my view that is the right trade for a workflow that runs the same way a thousand times a day, and the wrong one where a provider's schema moves between releases.

An agent runs `aclif discover --json`, then `aclif learn salesforce --json` for a provider briefing, and pulls the schema or examples for one operation only when it needs them ^[6]. Introspection costs the provider nothing: according to the project's documentation, none of those commands require credentials, execute an API request or consume the provider's quota ^[7]. The usual arrangement is a connector that publishes separate tool definitions for querying an account, updating a contact and inspecting metadata, with the model working through the collection ^[20].

An agent can refer to a `customer`, and an alias catalog maps that concept to `Account` in a particular Salesforce instance or `core_company` in ServiceNow ^[9]. The project says that keeps generated workflows stable when the same business concept carries different names across systems, and pushes provider quirks below the agent's working context ^[10]. The catalog can also absorb custom objects and fields captured from each deployment ^[9]. Somebody on your side keeps that file current.

The binary needs Node 22 or later, ships as the `@aclif/core` npm package, and includes a scaffold for building a narrower CLI with only the providers you want ^[8].

The agent can spawn the binary itself with credentials from flags, environment variables or a profile in `config.yaml`. Or a host application can import the runtime and supply credentials per invocation. The third of the three documented modes is a long-running gateway executing commands for many agents, resolving secrets from a vault, forwarding the acting user's identity, applying policy and recording audit events ^[13].

Every command declares mutability, reversibility, idempotency and blast radius, and a host can inspect those declarations and deny a command before loading its implementation ^[16]. Mutating commands accept `--dry-run`, operations marked as requiring approval demand `--confirm`, and results and errors follow a published JSON contract with distinct exit codes for API, usage and authentication failures ^[17]. The documentation says that metadata still depends on provider authors describing commands accurately ^[18]. Four native providers plus one contributed provider is five sets of declarations to take on trust ^[19], and aclif's public pages leave its founders and leadership unnamed ^[4].

The repository carries a 2026 copyright attribution to Prompt One Inc., and the corporate relationship is unexplained on aclif's site and on Prompt One's pages ^[5]. The documented technical link runs through the gateway: aclif's repository says Prompt One's service gateway runs the embedded runtime with vault-resolved credentials and a capability gate ^[14]. Prompt One describes its own product as a platform for compiled workflow agents generated from natural-language descriptions, with a Composer that codifies a description into a Motion compiling to deterministic code and inference reserved for steps needing judgment ^[15]. The commercial compile step and the open framework's design-time binding are the same idea at two layers. For a team taking the dependency, the question to settle first is who merges a provider's declaration of blast radius, because the host's check enforces the declaration and not the behaviour ^[16][18].