Aclif Agent CLI Framework Overview

Aclif provides a unified abstraction for AI agents to interact with SaaS providers

Aclif is an Agent CLI framework designed to solve the "tool sprawl" problem in AI agents. Instead of requiring an agent to manage multiple distinct APIs, login methods, and grammars for every SaaS provider, Aclif provides a single tool with a unified grammar and canonical names. This allows an agent to reach the same record across different platforms using the same name, significantly reducing the complexity of cross-platform operations.

Solving the LLM context window problem

Traditional Model Context Protocol (MCP) servers publish a fixed list of tools that occupy the agent's context window on every turn. This creates a trade-off between coverage (providing all API operations) and cost (token consumption).

"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."

Aclif resolves this by loading command definitions only when the agent specifically requests them. This ensures that the entire API of every provider remains reachable without incurring a standing cost in the context window, keeping the token count stable regardless of whether the agent is interacting with one platform or five.

Core technical capabilities

Unified Grammar and Canonical Naming

Aclif implements a single command structure, JSON envelope, and error vocabulary across all providers. It uses alias sets to map canonical names to provider-specific terms (e.g., mapping customer to Account in Salesforce and core_company in ServiceNow). A tenant catalog captured at deploy time allows the CLI to handle custom objects and fields without changing the provider code.

Introspection-First Workflow

Agents can discover and learn about available tools without executing them or consuming API quotas. Using flags like --schema, --examples, and --shape, an agent can introspect a command's requirements and preview responses before making a live API call.

Actionable Error Recovery

Errors in Aclif are designed for agent recovery. Every error identifies the failure, suggests the command to fix it, and provides a corrected input if a rewrite rule exists. This classification is handled by plain code rather than a model, ensuring consistent behavior between design-time shell validation and run-time execution.

Declared Safety and Auditability

Every command in Aclif declares its mutability, blast radius, reversibility, and idempotency. This allows policy checks to refuse a command before the code even loads. Furthermore, all mutations support --dry-run and can require --confirm based on metadata, with every run generating an audit line.

Deployment and Execution Models

Aclif supports three distinct execution modes to balance trust and security:

  1. Run by the Agent: The agent spawns the binary directly. Credentials are managed via flags, environment variables, or local config files. This is suitable for single-operator environments where the agent and operator share a trust boundary.
  2. Run by a Host Application: A host application sits between the model and Aclif, holding the credentials and executing commands in-process or via the CLI. This prevents the model from ever holding credentials and keeps tool definitions out of the context window.
  3. Run by a Gateway: A long-lived process serves multiple agents. The gateway resolves credentials from an enterprise vault per request, enforces centralized policy, and maintains a single audit trail. This ensures agents cannot widen their own scope and that every call is attributed to a specific human user.

Supported Providers and Extensibility

Aclif includes native support for Salesforce, ServiceNow, DocuSign, and Agentforce, with contributed support for Google Workspace (Gmail, Calendar). The framework is MIT licensed and allows users to build their own CLIs using a scaffold command to include only specific providers. New providers can be added by translating a platform's API specification onto the Aclif command surface.

Developer Insights

Regarding the reliability of tool selection, the author notes that allowing models to choose tools dynamically at runtime can lead to errors and security risks:

"We found after deploying many enterprise agents that letting the model choose tools at run time can cause problems. The agent holds the credential and sometimes chooses the wrong tool. Using the same tool every time prevents this."

This insight drives Aclif's approach of allowing a person or authoring tool to define the exact command string at design time, which the agent then executes as ordinary code at runtime without requiring further inference.

Sources

Related

  • Project
  • Project
  • Project
  • Dispatch
  • Project