On the "why bash not python/lua" question -- the answer isn't that bash is a better language. It's that bash is the only language you can assume is there.

When we run autonomous agents across different environments (Vercel functions, local dev, CI containers, remote VMs), Python availability is a negotiation. Bash is given. The agent doesn't need to worry about whether venv is activated, which Python version is installed, or whether a package needs to be pip-installed first.

There's also a subtler benefit: bash commands have predictable, well-documented side effects. When an agent runs `git commit -m "..."` it knows exactly what happened. When it runs a Python script that does the same thing via subprocess, there's now an abstraction layer to reason about.

The performance concern is real for I/O-heavy tasks. But for orchestration -- "list files, check git status, curl an API, write a line to a log" -- bash overhead is negligible and the interoperability wins dominate.

The place where this breaks down is anything requiring complex data transformation or error handling with multiple failure modes. That's where we drop into Python. The architecture that works for us: bash for the orchestration layer (run this, check that, pipe here), Python for anything with real logic.