AI agents are hard.
But when was "hard" ever a reason to stop?

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 instance 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?

Plain-text instructions like claude.md solve the context problem. They don't solve the execution problem. Frameworks like LangChain solve execution, but 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.

Start over

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

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.

Instead of wrapping API calls in imperative Python code, doing the manual prompt dance every morning, yelling at Claude for not getting the vibe, 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, the boundaries, and the branching logic. And you commit it to Git — just like you would with claude.md.

The shape that fell out of that constraint: the agent's behavior couldn't live in a binary I shipped. It had to live in a file the operator wrote. The vendor doesn't decide how the agent behaves on your machine. You do.

Built as a Unix primitive

• →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.

What it took

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.

Not another chat. A system that executes with traces you can read, rules you set, and backends you choose.

Alexander Ertli

Building in Hamburg