chris_marino
Joined 15 years ago
Karma
96
Submissions
33
Member since
Apr 3
Recent submissions
Comment · 1 month ago
Comment · 1 month ago
My response was simplified because your question was basic. OpenClaw was one example that fit the pattern, not a claim that every deployment holds the credential in the sandbox. Injection proxies exist and I should have said so. As for showing the data for advantages, I'll refer you to Anthropic and Cloudflare's Code Mode
https://www.anthropic.com/engineering/code-execution-with-mc... https://blog.cloudflare.com/code-mode-mcp/
We have our own, but will defer to 3rd party evidence.
Reinventing progressive disclosure is definitely part of this, but that's only one element of the approach. To be clear, this is all based on what we use internally, deployed in a particular way within our platform. Will leave it up to others to determine how useful it may be for them.
As for authz, that's what the rest of our system does and is beyond the scope of the aclif effort.
Comment · 1 month 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.
Comment · 1 month ago
I thought I made it clear right up front. 'Why agents need their own CLI'
What's not clear about that?
Comment · 1 month 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
Comment · 1 month ago
LOL.
Comment · 1 month 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.
Comment · 1 month 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/...
https://github.com/agent-cli-framework/aclif/blob/main/.clau...
Comment · 1 month 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.
Comment · 1 month ago
Most agents that automate enterprise workflows run a defined process: on a schedule, or on every new record or update. Those agents should never choose their own tools. Unlike an ad-hoc or exploratory research agent, a workflow agent should have its commands chosen, validated, and fixed at design time.
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.