But the moment you build your own agent, you’re on your own. It’s tricky wiring up the right primitives just well enough to match that “it just worked” feeling."

Im sorry, but who is saying this? If you just throw this statement into agent of your choice- and ask what native integrations exist to cover this use: OAI and Anthropic both have a handful of options here. Claude Agent SDK, Claude managed agents, Codex exec, Codex sdk, Codex app server, openai agents sdk, openai agents api.

Hopefully this is easier as time goes on. Of course- also policy on the egress

Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.

This has been my conclusion as well, and I'm doing my best to try and back this up quantitatively. In a perfect world, I could smite all of the internal MCP servers in my Corp environment and replace them with REST/GraphQL. No one using any of these servers is hitting them with models that would perform worse orchestrating with bash- and some of these folks are running harnesses with awful MCP clients.

I would have to imagine, that Luna would very much fall into the camp of "bash capable". At which point- it seems to me that adding any tools beyond just Bash requires some rigorous testing and verification that value is being added.

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

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.

This gave me a chuckle, there's some subtle irony here- especially if the documentation of the GQL schema was work that needed to be done!

Looking forward to 0.1.0 release :)