{"slug": "show-hn-aclif-agent-cli-framework-one-grammar-canonical-names-across-saas", "title": "Show HN: Aclif – Agent CLI Framework. One grammar, canonical names across SaaS", "summary": "Aclif released an open-source Agent CLI Framework that gives AI agents a single command-line tool with one grammar and canonical names spanning multiple SaaS providers, installable via `npm install -g @aclif/core`. The framework loads a command's definition only when the agent requests it, so aclif claims the full API of every provider stays reachable with no standing context cost, unlike MCP servers whose fixed tool lists consume tokens on every turn. Aclif also supports design-time command strings that run as ordinary code with no tool definition loaded and no inference, plus `--schema`, `--examples`, and `--shape` introspection flags that return before execution, need no credentials, and count against no API quota.", "body_md": "# The Agent CLI Framework\n\naclif builds command-line tools for AI agents. An agent gets a single tool that provides a unified abstraction across every SaaS provider: one grammar, and canonical names that reach the same record by the same name on any platform.\n\n## Try it now\n\nInstall the binary, list the providers, and read a command's schema, examples, and safety metadata.\n\n```\nnpm install -g @aclif/core\n\naclif discover --json\naclif learn salesforce --json\naclif learn servicenow --json\naclif salesforce data query --schema\naclif salesforce data query --examples\naclif salesforce data query --query \"SELECT Id FROM Account LIMIT 3\" --dry-run\naclif servicenow data query --table incident --query \"active=true^priority=1\" --dry-run\n```\n\n## Why agents need their own CLI\n\nAn MCP server publishes a fixed list of tools, and every tool on the list occupies the agent's context on every turn. The server's author trades coverage for cost when the server is built. Publishing every operation (a typical API has hundreds of definitions) keeps the whole API reachable and consumes tokens for all of it on every turn. Publishing a handful of broad operations keeps the token count small, and any operation the author left off the list is out of the agent's reach. An agent that spans several platforms needs a server, a login, a grammar, an error format, and a set of names for each.\n\naclif loads a command's definition only when the agent asks for it, so the whole API of every provider is reachable at no standing cost in context. One grammar, one envelope, and one error vocabulary cover every provider, so the agent's context stays about the same size whether it reaches one platform or five.\n\nAn agent that runs a defined workflow can leave the model out of the call altogether. A person or an authoring tool works out the exact command at design time and embeds it in the workflow as a string. At run time the agent executes that string as ordinary code, with no tool definition loaded and no inference. The command is chosen at design time, and the authority to run it, the credential, the acting identity, and the policy, is supplied at run time by whatever runs it. Neither side ever holds both.\n\n## What every command gives you\n\n### One grammar\n\nOne command structure, one JSON envelope, and one error vocabulary across every provider. An agent learns the tool once, and a new platform adds commands without adding grammar. A JSON manifest adds a command over one HTTP endpoint in the same grammar, with no code.\n\n### Canonical names\n\nAlias sets map `customer` to\n    `Account` in one Salesforce instance and\n    `core_company` in ServiceNow. A tenant\n    catalog, captured from each instance at deploy time,\n    teaches the CLI each instance's custom objects and\n    fields with no change to the provider.\n\n### Errors an agent can act on\n\nAn agent recovers in one turn. Every error names the failure, the command that fixes it, and, where the provider's classifier has a rewrite rule for the mistake, the corrected input ready to resend. The classifier is plain code with no model behind it. A command validated in a shell at design time returns the same error at run time under any host, because the same command classes run in both.\n\n### Introspection without execution\n\n`--schema`, `--examples`,\n    `--shape`, and four more flags return before\n    the command runs, need no credentials, and count against\n    no API quota. An agent can discover, learn, introspect,\n    and preview against a rate-limited instance and spend\n    nothing.\n\n### An embeddable runtime\n\nThe same command classes run in-process inside a host that supplies credentials, identity, and policy per request, keeps connections warm, and caches expensive logins per instance. A gateway built on it works with the enterprise's own identity provider and secrets vault.\n\n### Declared safety\n\nMutability, blast radius, reversibility, and\n    idempotency are declared on every command. A policy\n    check\n    can refuse it before its code loads. Every mutation\n    accepts `--dry-run`, demands\n    `--confirm` where its metadata says so, and\n    writes an audit line after every run.\n\n## The introspection-first workflow\n\nAn agent needs no documentation beyond the binary, and nothing before the last step touches the API.\n\n```\naclif discover --json                          # every provider, its tier, whether credentials are configured\naclif learn salesforce --json                  # a briefing: topics, key fields, query syntax, auth paths\naclif salesforce data query --schema           # flags, args, safety metadata, no execution\naclif salesforce data query --examples         # runnable examples with the responses they produce\naclif salesforce data query --query \"SELECT Id, Name FROM Account LIMIT 5\" --dry-run\naclif salesforce data query --query \"SELECT Id, Name FROM Account LIMIT 5\" --json\n```\n\nThe envelope's `_context` block holds\npagination with the exact next command, the fields\navailable, and related commands worth running. Exit codes\nare 0, 1 (API), 2 (usage), 3 (authentication). The contract\nand its JSON Schemas are in\n[CONTRACT.md](https://github.com/agent-cli-framework/aclif/blob/main/docs/CONTRACT.md).\n\n## Three ways to run it\n\nA vendor CLI is built for one deployment: installed on a machine, logged in by the person at the keyboard, one process per command. Behind a gateway that fails. Every call spawns a process and logs in again, the acting user's identity cannot be forwarded, nothing declares what a command will do, and nothing is uniform to audit. aclif's command classes run unchanged in three places, and whoever runs them decides who supplies credentials, enforces policy, and keeps the audit trail.\n\n- **Run by the agent.** The agent process\n  spawns the binary, executes the command, and reads the\n  JSON it returns. Credentials come from flags, environment\n  variables, or a profile in the agent's own environment.\n  Use this when one agent, one operator, and one set of\n  credentials share a trust boundary.\n- **Run by a host application, the design-time\n  case.** An application sits between the model and\n  aclif and holds the credentials. The model calls a tool\n  the application defines, and the application executes the\n  command, in-process or by passing a command string to the\n  CLI. A person or an authoring tool uses this to let a\n  model discover providers, introspect commands, and\n  validate the exact command it will write into an agent.\n  Use this when the\n  model must never hold credentials and tool definitions\n  must stay out of its context.\n- **Run by a gateway, the runtime case.** A\n  deployed agent submits commands, and one long-lived\n  process serves many such agents. The gateway resolves\n  credentials from the enterprise vault per request, checks\n  policy against the acting user, records every call, and\n  keeps connections warm. The agents hold no provider\n  credentials and cannot widen their own scope. Use this\n  when many agents share providers and one place must hold\n  policy and audit.\n\n|  | Run by the agent | Run by a host application | Run by a gateway | \n|---|---|---|---|\n| Credentials | flags, env, `config.yaml` | host-supplied resolver | vault-backed resolver, per request | \n| Policy | `config.yaml` | `capabilityGate` hook | `capabilityGate` plus the host's middleware | \n| Identity | `--identity-token` or env | the acting user on the invocation | the acting user and SSO claims from the request | \n| Audit | stderr line per run | reporter events | reporter events, recorded by the host | \n| Connections | file session cache | runtime pool | runtime pool, keyed per instance and identity | \n\nDetails on the [Embedding](embedding.html)\npage.\n\n## Gateway deployments\n\nLong-lived, embeddable deployment enables a gateway topology where additional security policy can be applied. One process the enterprise operates executes every command for every agent, and the arrangement provides:\n\n- **Credentials in one place.** Resolved\n  inside the gateway, per request, from the enterprise's\n  vault. Agents hold none.\n- **Enterprise-wide canonical names.** Tenant catalogs and alias sets are held by the gateway, so\n  every agent uses the same names for the same records\n  across every provider and instance.\n- **Every call attributed to a person.** The acting user's identity travels with each call into the\n  policy check and the audit record, even through a shared\n  service account.\n- **Policy enforced once.** Every command\n  declares what it will do, and the gateway checks that\n  declaration before the command's code loads. Agents cannot\n  widen their own scope.\n- **One audit trail.** The same event for\n  every command from every agent, naming the user, the\n  command, and the outcome.\n\n## Install, or build your own\n\n```\nnpm install -g @aclif/core\n\n# Your org's My Domain URL, no trailing slash\nexport SF_INSTANCE_URL=https://example.my.salesforce.com\n\n# A session token from the Salesforce CLI (sf org login web first if needed)\nexport SF_ACCESS_TOKEN=$(sf org auth show-access-token -o me@example.com --json | jq -r .result.accessToken)\n\naclif salesforce data query --query \"SELECT Id, Name FROM Account LIMIT 3\" --json\n```\n\nWithout the Salesforce CLI, use an API user. Salesforce emails the security token when the password is set or reset:\n\n```\nexport SF_INSTANCE_URL=https://example.my.salesforce.com SF_USERNAME=me@example.com SF_PASSWORD=... SF_SECURITY_TOKEN=...\naclif salesforce data query --query \"SELECT Id, Name FROM Account LIMIT 3\" --json\n```\n\nThe `aclif` binary ships with every built-in\nprovider and needs Node 22 or later. The binary you ship is\nyours: one scaffold command produces a CLI with its own\nname, its own config directory, its own environment\nvariables, and only the providers it chose. See\n[Getting started](getting-started.html) and\n[Build a CLI](build-a-cli.html).\n\n## Providers\n\nSalesforce, ServiceNow, DocuSign, and Agentforce are\nnative and are included in every release. Google Workspace\n(Gmail, Calendar) is contributed. A private tier holds\nproviders a fork keeps to itself, under a path upstream\nnever commits to. Writing a provider takes little effort: it\nis a direct translation of the platform's API specification\nonto the command surface, a coding agent does it from a\nsample prompt in the repository, and the conformance suite\nchecks the result. See [Providers](providers.html).\n\naclif is MIT licensed. Contributions follow\n[CONTRIBUTING.md](https://github.com/agent-cli-framework/aclif/blob/main/CONTRIBUTING.md);\nthe guide for people and coding agents changing the\nframework is\n[AGENTS.md](https://github.com/agent-cli-framework/aclif/blob/main/AGENTS.md).", "url": "https://wpnews.pro/news/show-hn-aclif-agent-cli-framework-one-grammar-canonical-names-across-saas", "canonical_source": "https://www.aclif.ai/", "published_at": "2026-09-17 16:48:17+00:00", "updated_at": "2026-09-17 16:56:05.942680+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "agent-protocols", "developer-tools", "ai-products"], "entities": ["Aclif", "Salesforce", "ServiceNow", "MCP", "@aclif/core"], "alternates": {"html": "https://wpnews.pro/news/show-hn-aclif-agent-cli-framework-one-grammar-canonical-names-across-saas", "markdown": "https://wpnews.pro/news/show-hn-aclif-agent-cli-framework-one-grammar-canonical-names-across-saas.md", "text": "https://wpnews.pro/news/show-hn-aclif-agent-cli-framework-one-grammar-canonical-names-across-saas.txt", "jsonld": "https://wpnews.pro/news/show-hn-aclif-agent-cli-framework-one-grammar-canonical-names-across-saas.jsonld"}}