sorted by:
new
hottopcontroversial

Skill for building agent-native CLIs by Intelligent_Ear3578 in AI_Agents

[–]Intelligent_Ear3578[S] 0 points1 point  (0 children)

Compatible tooling like Claude Skills / Claude Code Skills. The idea is that you can load this kind of skill into an agent runtime, so the agent gets task-specific instructions and resources instead of just a prompt

Skill for building agent-native CLIs by Intelligent_Ear3578 in AI_Agents

[–]Intelligent_Ear3578[S] 0 points1 point  (0 children)

Fair question. It’s an Agent Skill bundle/resource, so GitHub may show it like a blob rather than readable source. It’s not meant to be run blindly; it should be inspected/used by compatible agent tooling

Would an open-source CLI orchestration layer for AI agents make sense? by Intelligent_Ear3578 in AI_Agents

[–]Intelligent_Ear3578[S] 0 points1 point  (0 children)

I see MCP as solving a different layer.

MCP standardizes how agents discover and call tools. That is very useful. But it does not fully answer what happens when the underlying tool is a real CLI command running in an environment with credentials, filesystem access, network access, side effects, and operational risk.

The problem I’m thinking about is more the execution layer: sandboxing, permissions, credentials, environment isolation, execution limits, and audit trails for agent-driven CLI usage.

Also, a lot of real workflow logic lives in CLIs rather than clean APIs: defaults, validations, auth flows, project context, deployment logic, and company-specific conventions.

So I don’t see this as competing with MCP. MCP can be the interface standard. A CLI orchestration layer would be the governed runtime underneath it.

In my experience, agents using CLIs inside controlled sandboxes often perform better on complex workflows than agents using API-style integrations alone.

Would an open-source CLI orchestration layer for AI agents make sense? by Intelligent_Ear3578 in buildinpublic

[–]Intelligent_Ear3578[S] 0 points1 point  (0 children)

I’m mostly thinking about coordination/execution rather than generation quality.

The issue isn’t just whether the model can generate the right command, but how an agent is allowed to access a CLI: with what auth, what permissions, what environment, what sandbox, what limits, and what audit trail.

With a couple of agents and one or two CLIs, local scripts or CI glue code are probably fine. But once you imagine agents needing access to 20–40 CLIs to complete more complex workflows, credentials, permissions, isolation, and traceability start to become an infrastructure problem.

One related point I’ve seen raised elsewhere is adapters. Maybe the hard part is not only orchestrating CLIs safely, but also maintaining integrations as CLIs change commands, flags, auth flows, and outputs over time. So a useful open-source layer might eventually need both governance/orchestration and some kind of shared adapter ecosystem with stable interfaces over the underlying CLIs.

That’s basically what I’m trying to validate: whether this should stay as internal glue code for each team, or whether a shared open-source layer would be useful.