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.
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.
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?
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.
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
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?
The repo has more details. https://github.com/agent-cli-framework/aclif
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.
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?
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/
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
"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.
I have to build a cli for every provider? Seems like a lot of effort.
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...
Tell your providers to stop building workspaces with conflicting identifiers and namespaces.
LOL.
This does not make any sense whatsoever.
I thought I made it clear right up front. 'Why agents need their own CLI'
What's not clear about that?
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?
How does this differ from the printing press?