| ▲ | tikimcfee 2 days 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 2 days ago | parent | next [-] | |
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. | ||
| ▲ | chris_marino 2 days ago | parent | prev [-] | |
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 | ||