u/js402

AI Agents are hard. But when was "hard" ever a reason to stop? (Why I built a CLI state-machine for LLMs)

Over a year ago, I started exploring what LLMs could actually be used for. Back then, things weren't so clear-cut — Copilot in VSCode, maybe Zed, and the AI tab in the browser. Lots of folks were already betting hard on letting AI run tools autonomously. I wasn't. Some still aren't.

But then it started creeping into my daily workflows, and it was incredibly cumbersome. I had to remember to feed it data and prompts in the right order and at the right pace. I'd let it generate some code I could validate against the existing implementation, tweak 5 or 6 knobs, and finally feed it the actual task. Then the next day, I'd repeat the exact same pattern. Again and again.

Today, there is Claude and claude.md where you can steer the model via text. That approach alone won out a bit against LangChain, agents, and whatever else you want to call these things we now refer to as "AI workflows" or "skills."

Despite this, I continued to explore an alternative path: What if the manual routine I was forcing myself through every morning was just a state machine configuration?

Because while plain-text instructions like claude.md solve the context problem, they don't solve the execution problem. And while frameworks like LangChain solve execution, they force the developer to decide exactly what belongs in the execution loop using imperative code.

My vision was simple: I wanted the reproducible automation of a shell script or GitHub Actions, but for an LLM. And I didn't want to bet my ability to work on whichever AI vendor wins the coding platform race. It turns out a simple vision is not always simple to execute... but that's another story. Time passed, stuff happened, and new players rose to prominence overnight.

After looking at OpenClaw, OpenCode, Hermes Agent, n8n, and many others, I came to a conclusion: start over.

So I did. I threw out the visual builders, the web UIs, the servers, and the RAG pipelines I was experimenting with, and boiled it all down to a single Go binary. I called it Contenox. (I chose Go as it's the language with the best error handling and API integration practices – just my personal opinion).

Instead of wrapping API calls in imperative Python code, doing the manual prompt dance every morning, or git revert-ing uncommitted work, you write a "Chain" once as a declarative JSON file. Like a policy, you define the exact system prompts, the steps, the model, the tools, the budgets, and the branching logic. And you commit it to Git — just like you would with claude.md.

Because it's a pure CLI primitive, it acts like the rest of our tools:

• It speaks Unix: The data feeds itself. git diff --staged | contenox run "suggest me a commit msg"
• It runs locally: llama.cpp is built straight in. Run contenox model pull qwen3-4b and the whole pipeline runs entirely on your own hardware. No Python dependencies. No API keys required.
• It respects boundaries: I still don't trust LLMs to run tools blindly, and neither should you. Human-in-the-Loop isn't a UI toggle — it's a strict policy file. Contenox executes autonomously until it hits a destructive command, then it physically freezes your terminal and asks: Approve local_shell: rm -rf tmp/? [Y/n]. You get the automation without the anxiety.

Yes, removing the UI made it harder to adopt for some. But deleting tens of thousands of lines of code unlocked the ability to optimize Contenox as a tool first. The slimmer interface stripped away all the "slideware" features that looked cool but were actually harmful to reliably delivering value.

Contenox is open-source (Apache 2.0).

For a star, a suggestion, or any contribution: https://github.com/contenox/contenox

I'm Alexander, building in Hamburg. (Disclaimer: I am the author) – If you're also tired of the repetitive prompt dance or the friction of heavy frameworks, I'd love for you to try this alternative path.

Thanks for reading; let me know what you think!