One-shot mode sounds like a small CLI feature. It is not. Once an AI coding agent can be called from a shell script, a GitHub workflow, a local task file, or another agent, it stops being only a chat interface and starts becoming part of your development pipeline.
That is where most agent tools get dangerous. They make the agent easier to call, but they quietly remove the friction that was protecting the user from bad writes.
The important part is not that mythos run accepts a prompt. The important part is that it uses the same verified SWD execution path as the interactive chat loop.
Scriptability Changes the Risk Profile
In a chat session, a human is usually watching. In a one-shot command, the prompt might come from a file, stdin, a release checklist, or another automated system. The command can be repeated. It can be chained. It can be added to scripts.
That is powerful, but it also means the output needs stricter boundaries. A model claiming "I updated the docs" is not enough. A useful CLI has to ask a harder question: did the file on disk actually change in the way the model claimed?
| Workflow | What It Enables | What Must Stay True |
|---|---|---|
| Interactive chat | Exploratory coding and refactors | Every write is verified |
| `mythos run "prompt"` | Fast one-off tasks | No shortcut around SWD |
| `mythos run --file TASK.md` | Reusable task specs | Same memory, budget, routing, receipts |
| stdin prompt | Composable shell usage | Same correction loop |
The Bad Version of One-Shot Agents
The bad version is a thin shortcut path. It takes a prompt, calls a model, writes whatever comes back, and exits. It feels fast in demos because nothing is being checked.
That design fails exactly where autonomous tools matter most. It can silently write stale content. It can say it changed a file that stayed identical. It can touch command-affecting files without making the risk visible.
The Better Rule
A one-shot command should be scriptable without becoming less honest.
mythos run "update the README install section"
mythos run --file TASK.md
cat TASK.md | mythos run --stdinThose entry points should feel different from chat, but they should not be different from a trust perspective. The model should still route through the same execution kernel. The filesystem should still be the source of truth. Budget tracking should still work. Receipts should still be available when files are changed.
Why This Matters for Teams
Most teams do not need another chatbot. They need an agent that can be placed next to real workflows without becoming a source of invisible drift.
That means the CLI needs boring properties: predictable inputs, clear exits, read-only checks, auditable writes, and failure modes that stop before they damage the repository.
The moment an AI agent becomes scriptable, "trust me bro" output becomes an operational risk. The shell needs proof, not just prose.
The Product Direction
This is why mythos-router v1.9.0 added mythos run as a first-class command instead of a separate shortcut. The command is useful because it is boring in the right places.
It accepts direct prompts, files, and stdin. It still uses the SWD/chat pipeline. It still keeps receipts, memory, budget tracking, skills, routing, and branch sandboxing in the path. It adds automation without removing accountability.
That is the difference between an agent demo and a tool you can actually put near a repository.