June 28, 2026 · Michael Rodriguez
The Bash Script That Closes More Loops in My Business Than My LLMs Do
The most useful AI agent I built doesn't use AI. Two hundred lines of bash, no language model, more leverage per dollar than anything else in my stack. An operator's case for telemetry over intelligence.
The most useful AI agent I built does not use AI.
It is 196 lines of bash. No language model. No tokens. No prompt. It closes work flags across the eight AI chats that run my four businesses, and I have not manually closed a flag in over a month.
I sell cars for a living. Twenty years in automotive retail. No tech background, no computer science degree. I have built 22 production AI agents on evenings and lunch breaks. Of all of them, this one is the most useful per dollar, per minute of build time, and per ounce of operator attention. This post is the case for why, and why you should look hard at where in your business a script will beat an AI agent.
Why would a bash script be more useful than an AI agent?
Because most operator workflows are structural, not conversational.
Closing a ticket. Moving a record from one column to another. Pulling last night's revenue. Committing a status update to a shared log. None of these need a language model to understand the request, because the request is the same every time. A small script with five clear inputs does the work faster, costs nothing to run, and leaves an audit trail you control.
A language-model agent for the same task adds latency (the model has to think), adds cost (every call has a price), adds variance (the model might do the work slightly differently each time), and adds a dependency on the model provider. None of those are free.
For a class of operator workflows the right answer is not "use AI." The right answer is "use a script." Knowing the difference is the operator skill.
Related reading
The broader pattern of when to reach for a script and when to reach for an AI agent is covered in How to evaluate an AI agent for your sales floor.
What does the script in this post actually do?
It closes a work flag in a shared telemetry repository.
The way my four businesses are coordinated is through eight AI chats, each one responsible for a slice of the work. The chats hand work to each other through "flags" written in a specific format into a shared GitHub repository. When the receiving chat completes the work, the flag needs to come out of the source file and a "recently closed" entry needs to land in the receiving chat's own file. Then the changes commit, get pushed, and every chat sees the new state on the next read.
Before this script existed, every flag closure had to go through me. I had to open the source file, find the flag block, delete it, open the receiving chat's file, append a "recently closed" entry, commit both changes, and push. Across dozens of flags a week, this was a real chunk of my attention.
The script automates the whole pattern.
The interface is five arguments. Source file, target name, posted timestamp, closer name, and a short note about what was done. The script handles everything else.
The implementation choices that mattered. The script pulls with git pull --rebase --autostash so it is safe to run concurrently with other chats editing other files. It uses a case statement instead of an associative array because the target shell is bash 3.2 on macOS, which does not support associative arrays. It validates the source file against an allow-list so a typo cannot accidentally close a flag in the wrong file. It writes its audit trail into the same git commit that closes the flag, so the history is self-documenting.
196 lines. No external dependencies past git itself.
How do I know when an operator should pick a script over an AI agent?
Three signals.
One. The workflow is deterministic. The inputs always map to the same outputs. There is no judgment call in the middle. If you can write the rules on a single page and the rules cover every real case, the work is deterministic. Closing a flag is deterministic. Drafting a customer reply is not.
Two. The work happens often. The build pays back quickly because the work repeats. If you do this thing five times a week, even a few hours of build pays back in a month. If you do it twice a year, building a script is probably not the right investment.
Three. You want a permanent audit trail you control. Scripts leave a clean trail. Every action is in your repository. Every commit is signed. Every change is reversible. AI agents leave a trail too, but the trail goes through the model provider's logs, which you do not control and which may not be retained the way you need.
Most routine operator bookkeeping fits all three signals. Most cross-tool integrations do not (because the integration code is not under your control past the script boundary). Most copy production does not (because the inputs are unstructured language). The skill is sorting the workflows you are about to automate into the script bucket and the AI bucket before you start.
The most useful agent I built does not use AI. Telemetry beats intelligence for a large class of operator work. Know which class your workflow is in before you reach for a model.
What is the minimum a script-style automation needs?
Four things.
Inputs that are obvious. A small set of clear arguments. The person running the script (or the agent calling it) should know exactly what to pass without reading documentation. The flag-closing script takes five arguments; each one's purpose is named in the argument name.
Failure modes that are loud. When the script fails, the failure should be readable from the output without digging through logs. If git fails to pull, the script should say so. If the flag block cannot be found, the script should print the file it looked in and the fingerprint it tried to match.
Concurrency safety if multiple operators will run it. If two chats can run the script at the same time, the script must not corrupt the shared state. For mine, this meant using git pull --rebase --autostash and writing the audit log as part of the commit, not a separate file.
An audit trail in a place you own. The output of the script should land somewhere you can read it later without permission from a vendor. For mine, the audit trail lives in the same private GitHub repository the script edits.
Past those four, every feature is an upgrade. Most of the time you do not need the upgrade.
What is the operator lesson?
When you are looking at the next workflow you want to automate, ask three questions in this order.
Is the workflow deterministic? If yes, lean toward a script.
Does it happen often? If yes, the script pays back.
Do you want the audit trail under your control? If yes, the script is usually the right shape.
If all three answers are yes and you reach for an AI agent anyway, you are paying for cognition you do not need. The model will work. It will also cost you per call, run slower than a script, and add a dependency you cannot remove.
If even one of the three is no, the AI agent may be the right shape. A workflow that requires judgment, runs rarely, or needs to summarize unstructured input belongs in the model layer. The skill is sorting the work before you build it.
The development tools that make small scripts easy keep improving. The GitHub Actions documentation is a useful reference for the next step past a local script if you want the same work to run automatically on a schedule. The Anthropic developer docs are useful for the cases where a model genuinely is the right answer. Both have a place in an operator stack; neither replaces the operator skill of sorting the workflow into the right bucket.
If you want to see the full stack, including all 22 production agents and where the bash scripts sit alongside the language-model agents, the 10 agents lead magnet walks through it. The community where we ship this work in public is at skool.com/agent-empire-4291. Free.
While I sell cars for a living.
Michael
FAQ
Why would a bash script be more useful than an AI agent?
For a wide range of operator workflows, the work is structural, not conversational. Closing a ticket. Moving a record from one column to another. Pulling last night's revenue. Committing a status update to a shared log. None of these need a language model to understand the request, because the request is the same every time. A small script with five clear inputs does the work faster, costs nothing to run, and leaves an audit trail you control.
What does the script in this post actually do?
It closes a work flag in a shared telemetry repository. It takes five arguments (source file, target chat, posted timestamp, closer chat, what was done), pulls the latest version of the shared repository, removes the matching flag block from the source file, appends a 'recently closed' entry to the closer's owned file, commits the changes, and pushes. It is safe to run concurrently from multiple chats because it uses git's rebase-and-autostash flow. It is 196 lines of bash.
When should an operator pick a script over an AI agent?
Three signals. One, the workflow is deterministic; the inputs always map to the same outputs. Two, the work happens often enough that the build pays back quickly. Three, you want a permanent audit trail you control. Most routine operator bookkeeping fits all three signals, which is why scripts often beat AI for that class of work. Reserve language-model agents for tasks where the input is unstructured language and the output needs judgment.
Michael Rodriguez
Michael Rodriguez has spent 20 years on a dealership floor. With no tech background, he built and runs 22 production AI agents across four businesses on less than $50 a month, in evenings and lunch breaks. Agent Empire is where he ships it in public.
Building agents around a day job? Agent Empire is where operators ship it in public, together. Come build with us.