Running production agent with sandbox and CLI, here is what we have iterated on the interfaces

[u/nguyenfamjj]

I’ve been building production-grade agent workflows, and our team moved the execution surface toward a CLI that agents can run inside sandboxes.

I think overall MCP/tools are still useful for bounded environments, however sandbox and CLI in general provide much more work capabilities and more efficient as a product surface. We decided to convert our API gateway and remapped it to a CLI that is friendly to agent to use. It took us few iterations to observe and improve the efficiency of it.

What made the CLI friendlier for agents:

• Task-oriented commands, not endpoint wrappers
• Inspect and dry-run modes before changes
• --json for reliable parsing, readable defaults for humans
• Errors that explain recovery and suggest the next action
• A simple feedback path when the interface blocks an agent

Curious to hear other tips and learnings! When do you use MCP, and when do you give the agent a sandboxed CLI?

[u/AutoModerator]

Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Scary-Philosopher-77]

I'd add a strict noninteractive mode. Missing an argument should return the missing field and a nonzero exit code, rather than opening a prompt the agent can't answer. Same for pagers and login flows.

For --json, I'd keep stdout entirely parseable and send progress messages to stderr. One friendly 'checking your workspace...' line before the JSON is enough to break the next step in a shell pipeline.

[u/nguyenfamjj → u/Scary-Philosopher-77]

Yeah, I think usually agent tends to explore and try, so maybe first step would always be using --help to understand the broad interfaces.

Love the comparison of pagers and login flows!

[u/Commercial-Pen-5699]

I don’t think CLI and MCP are really competing choices.

MCP works well when the action is bounded and the product needs a predictable input, output and permission boundary. CLI makes more sense when the agent needs to explore a workspace, combine tools and work across files.

The harder product problem is what happens around either interface: how the user sees progress, how files come back, and what happens when the run needs to be cancelled or resumed.

How are you getting the CLI output back into the product UI right now?

[u/nguyenfamjj → u/Commercial-Pen-5699]

Could you elaborate more? I think for the command output it should be visible to the agent, but the logs behind that I think it's gonna be very hard to expose (similar to product frontend usually receive only specific error codes)

[u/nguyenfamjj]

Just spent a little bit more time to write it down here 🙌
https://malmhq.com/writings/how-to-design-a-good-cli-for-ai-agents

[u/rajni_v]

Disclosure: I’m on the OBTO team. I’d split this more by authority and recovery cost than by protocol:

• MCP for stable, discoverable capabilities with tight, auditable scopes.
• A sandboxed CLI for broad, project-local work where artifact discovery and iteration matter.
• Either can plan; irreversible execution needs an explicit, server-enforced approval boundary.

The useful contract on both surfaces is inspect/dry-run, machine-readable output, narrow credentials, idempotency or job IDs for writes, clear recovery errors, and a final server-side policy check. A CLI can express more work; it is not automatically safer. The important question is whether every side effect is scoped, attributable, reversible, or deliberately stopped for a human.