5 ms·

Show HN: Aclif – Agent CLI framework: one grammar, canonical names across SaaS

32 points by chris_marino 18d ago

Simple discovery of the provider's default schemas is possible without any credentials (since they are built into the binary). If you want it to fetch customizations of your specific instance, give it credentials to your org. The repo has more details. https://github.com/agent-cli-framework/aclif https://github.com/agent-cli-framework/aclif

chris_marino 18d ago
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.
- tikimcfee 18d ago
  Absolutely in love. I'll be testing this after the daily grind. I've had nothing but success with converting daily work into "notes" that then translate into runnable, deterministic application CLIs to completely sidestep "what do I need to say to you to make you do the thing??" I'm interested in how this spreads across enterprise flows, because the issue is always discovery and usability. How deep do you usually go with CLI composition and layering? Do you tend to find a flat list of commands and sub command help works most? Have you experimented with connecting CLIs Linux-pipe-style as if it was a dynamic application in the OS?
  - chris_marino 18d ago
    The objectives are to reduce/eliminate as much inference variability as possible. A side benefit is that inference costs collapse as well. It is used internally for what we call 'compiled workflow agents' where no inference is necessary. An agent composer determines the exact command at design time. That is part of a discovery loop that can introspect the service to construct the command. More here. https://www.promptone.ai/resources/downloads/ https://www.promptone.ai/resources/downloads/
  - chris_marino 18d ago
    The command structure is provider/topic/command. Taken literally from the oclif framework, with the provider simply being a topic namespace. Haven't needed to pipe anything since in our deployments, the agent makes a call to the gateway via a command API so a pipe wouldn't be possible between commands
- agentdev001 18d ago
  "The agent holds the credential" Huh? It shouldn't. Am I misunderstanding, or is this referencing poor practices? "Using the same tool every time prevents this" What does this mean? I looked at the project, im not sure what this means.
  - chris_marino 18d ago
    In many cases, the agent does hold the credential. When you authorize OpenClaw to read your gMail, OpenClaw has the credential. This is absolutely a poor practice, but common, nevertheless. As for using the 'same tool', what I meant was that you the agent doesn't have to pick the tool at all. There is just one: the aclif CLI. Not separate tools for Salesforce, Docusign, Workday, etc that the agent needs to learn (and possibly mess up). Just the one aclif tool. Same grammar for all external services. Less agent inference the better. Finally, alif CLIs support individual auth so a request can use SSO identities and fetch a token from a secrets value. The CLI holds the secret. If you deploy the CLI on a host or gateway, the agent never sees it.
    - agentdev001 18d ago
      Some really broad assumptions here, and youre being unclear. "When you authorize OpenClaw to read your gMail, OpenClaw has the credential." I can only assume you are implying that the execution environment accessible by the model via the harness here, had access to the credential. This is not even broadly true, as there are many single click solutions for deploying gateways that will allow operators to tls inspect and replace secrets in flight, outside of the agent execution environment. Sure, not doing that is poor practice- but your phrasing is unfair. "the agent doesn't have to pick the tool at all. There is just one: the aclif CLI" Okay, so- if thats the only tool, then why are we even talking about credentials? Why are we talking about openclaw? The whole conversation regarding creds being in bad places is predicated on agents having native control over a sandbox- generally through shell. If your use case lets you bake whatever resource access is needed into a single tool- then many other security layers bubble up in value, being that you no longer need to authn/z arbitrary networked calls. Also, yea sure- there is "one tool", all you've done is abstracted the tools into arguments. "Less agent inference the better." Show me the data, then. Show me how this performs better than the alternatives. This sounds like all you've done here is reinvent progressive disclosure? "The CLI holds the secret. If you deploy the CLI on a host or gateway, the agent never sees it." Okay, so- brokering, again. How are you solving authz then?
chris_marino 18d ago
[dead]
charlie_martin9 18d ago
I have to build a cli for every provider? Seems like a lot of effort.
- chris_marino 18d ago
  Yes. But any coding agent can do this in a matter of minutes. There is an example prompt and corresponding Skill.md in the repo. https://github.com/agent-cli-framework/aclif/blob/main/docs/PROVIDER_AUTHORING.md#a-sample-generation-prompt https://github.com/agent-cli-framework/aclif/blob/main/docs/... https://github.com/agent-cli-framework/aclif/blob/main/.claude/skills/add-provider/SKILL.md https://github.com/agent-cli-framework/aclif/blob/main/.clau...
- pixl97 18d ago
  Tell your providers to stop building workspaces with conflicting identifiers and namespaces.
  - chris_marino 18d ago
    LOL.
rvz 18d ago
This does not make any sense whatsoever.
- chris_marino 18d ago
  I thought I made it clear right up front. 'Why agents need their own CLI' What's not clear about that?
  - sunir 18d ago
    Here's a good set of questions for any write up: Who are we talking about? What's their role? (What agent? What is the job to be done?) What is the status quo? What's the problem with the status quo? What else has been tried? What's the consequence of not solving the problem? What more important problem do you need to work on that you're blocked because of this problem? What's the ideal solution? What's the current offer? Why would someone say no to any given solution? How have you addressed those problems?
Cameri 18d ago
How does this differ from the printing press?
- Cameri 17d ago
  This is a legitimate question so I don't understand why it would get downvoted. The Printing Press _already exists_ (https://github.com/mvanhorn/cli-printing-press https://github.com/mvanhorn/cli-printing-press) and it's not limited to SaaS providers like Aclif seems to be.
  - chris_marino 14d ago
    I downvoted it because I thought it was a bot response. Did not realize you were referring to cli-printing-press. The main difference is that printing press caches a local copy of data heavy sites like Discord channels, ESPN, etc. and creates a CLI for that API. aclif produces a single CLI with a unified grammar for all APIs, plus support for canonical names (fed by external semantic data layers) and unified auth. It targets enterprise SaaS APIs.
- deleted 15d ago
  [deleted]
dhanizael 18d ago
[dead]
devnanu0 17d ago
[dead]

32 points by chris_marino 18d ago

chris_marino 18d ago

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.

tikimcfee 18d ago
Absolutely in love. I'll be testing this after the daily grind. I've had nothing but success with converting daily work into "notes" that then translate into runnable, deterministic application CLIs to completely sidestep "what do I need to say to you to make you do the thing??" I'm interested in how this spreads across enterprise flows, because the issue is always discovery and usability. How deep do you usually go with CLI composition and layering? Do you tend to find a flat list of commands and sub command help works most? Have you experimented with connecting CLIs Linux-pipe-style as if it was a dynamic application in the OS?
- chris_marino 18d ago
  The objectives are to reduce/eliminate as much inference variability as possible. A side benefit is that inference costs collapse as well. It is used internally for what we call 'compiled workflow agents' where no inference is necessary. An agent composer determines the exact command at design time. That is part of a discovery loop that can introspect the service to construct the command. More here. https://www.promptone.ai/resources/downloads/ https://www.promptone.ai/resources/downloads/
- chris_marino 18d ago
  The command structure is provider/topic/command. Taken literally from the oclif framework, with the provider simply being a topic namespace. Haven't needed to pipe anything since in our deployments, the agent makes a call to the gateway via a command API so a pipe wouldn't be possible between commands
agentdev001 18d ago
"The agent holds the credential" Huh? It shouldn't. Am I misunderstanding, or is this referencing poor practices? "Using the same tool every time prevents this" What does this mean? I looked at the project, im not sure what this means.
- chris_marino 18d ago
  In many cases, the agent does hold the credential. When you authorize OpenClaw to read your gMail, OpenClaw has the credential. This is absolutely a poor practice, but common, nevertheless. As for using the 'same tool', what I meant was that you the agent doesn't have to pick the tool at all. There is just one: the aclif CLI. Not separate tools for Salesforce, Docusign, Workday, etc that the agent needs to learn (and possibly mess up). Just the one aclif tool. Same grammar for all external services. Less agent inference the better. Finally, alif CLIs support individual auth so a request can use SSO identities and fetch a token from a secrets value. The CLI holds the secret. If you deploy the CLI on a host or gateway, the agent never sees it.
  - agentdev001 18d ago
    Some really broad assumptions here, and youre being unclear. "When you authorize OpenClaw to read your gMail, OpenClaw has the credential." I can only assume you are implying that the execution environment accessible by the model via the harness here, had access to the credential. This is not even broadly true, as there are many single click solutions for deploying gateways that will allow operators to tls inspect and replace secrets in flight, outside of the agent execution environment. Sure, not doing that is poor practice- but your phrasing is unfair. "the agent doesn't have to pick the tool at all. There is just one: the aclif CLI" Okay, so- if thats the only tool, then why are we even talking about credentials? Why are we talking about openclaw? The whole conversation regarding creds being in bad places is predicated on agents having native control over a sandbox- generally through shell. If your use case lets you bake whatever resource access is needed into a single tool- then many other security layers bubble up in value, being that you no longer need to authn/z arbitrary networked calls. Also, yea sure- there is "one tool", all you've done is abstracted the tools into arguments. "Less agent inference the better." Show me the data, then. Show me how this performs better than the alternatives. This sounds like all you've done here is reinvent progressive disclosure? "The CLI holds the secret. If you deploy the CLI on a host or gateway, the agent never sees it." Okay, so- brokering, again. How are you solving authz then?

chris_marino 18d ago

[dead]

charlie_martin9 18d ago

I have to build a cli for every provider? Seems like a lot of effort.

chris_marino 18d ago
Yes. But any coding agent can do this in a matter of minutes. There is an example prompt and corresponding Skill.md in the repo. https://github.com/agent-cli-framework/aclif/blob/main/docs/PROVIDER_AUTHORING.md#a-sample-generation-prompt https://github.com/agent-cli-framework/aclif/blob/main/docs/... https://github.com/agent-cli-framework/aclif/blob/main/.claude/skills/add-provider/SKILL.md https://github.com/agent-cli-framework/aclif/blob/main/.clau...
pixl97 18d ago
Tell your providers to stop building workspaces with conflicting identifiers and namespaces.
- chris_marino 18d ago
  LOL.

rvz 18d ago

This does not make any sense whatsoever.

chris_marino 18d ago
I thought I made it clear right up front. 'Why agents need their own CLI' What's not clear about that?
- sunir 18d ago
  Here's a good set of questions for any write up: Who are we talking about? What's their role? (What agent? What is the job to be done?) What is the status quo? What's the problem with the status quo? What else has been tried? What's the consequence of not solving the problem? What more important problem do you need to work on that you're blocked because of this problem? What's the ideal solution? What's the current offer? Why would someone say no to any given solution? How have you addressed those problems?

Cameri 18d ago

How does this differ from the printing press?

Cameri 17d ago
This is a legitimate question so I don't understand why it would get downvoted. The Printing Press _already exists_ (https://github.com/mvanhorn/cli-printing-press https://github.com/mvanhorn/cli-printing-press) and it's not limited to SaaS providers like Aclif seems to be.
- chris_marino 14d ago
  I downvoted it because I thought it was a bot response. Did not realize you were referring to cli-printing-press. The main difference is that printing press caches a local copy of data heavy sites like Discord channels, ESPN, etc. and creates a CLI for that API. aclif produces a single CLI with a unified grammar for all APIs, plus support for canonical names (fed by external semantic data layers) and unified auth. It targets enterprise SaaS APIs.
deleted 15d ago
[deleted]

dhanizael 18d ago

[dead]

devnanu0 17d ago

[dead]