Why I Built OpenZeroCode: From Learning Coding Agent Harnesses to Building My Own Reins for the AI Era

I started building OpenZeroCode for a simple reason.

I wanted to understand:

How does a coding agent actually work?

Not just the surface-level version where you call an LLM API and print the answer.

I wanted to understand the full layer underneath:

• How does it understand the user’s task?
• How does it decide whether to read files?
• How does it modify files?
• How does it execute shell commands?
• How does it know whether the result is correct?
• How does it feed errors back into the model?
• How does it manage context?
• When can it act on its own?
• When should it stop and ask a human?

Those are the parts of coding agents that I find genuinely interesting.

I built OpenZeroCode not because the world needed another coding agent, but because I wanted to understand the complete process myself: from receiving instructions and interpreting the task, to operating tools, editing files, and validating the result.

For me, OpenZeroCode is more of a learning project.

It was never meant to replace Cursor, Codex, Claude Code, OpenCode, or other mature tools from day one.

What I really wanted was: to take apart the skeleton of a coding agent, understand it, and rebuild it in my own way.

A Coding Agent Is More Than an LLM API

When people first encounter AI agents, they often assume the model is the core of everything.

That is not wrong.

Without LLMs, the current generation of agents would not exist.

But once you actually start building a coding agent, you quickly realize:

the model is only one part of the system.

What makes an agent capable of doing work is the execution framework around the model.

That framework usually includes:

• prompt orchestration
• tool calling
• file system operations
• shell command execution
• context management
• task planning
• feedback loop
• approval / safety mechanism
• session state
• error handling
• result observation

Together, these pieces form an agent that can actually execute tasks.

Without them, the model is only capable of talking.

It can tell you “how you should change this,” but it cannot actually edit the file for you. It can guess where a bug might be, but it cannot run the tests itself. It can write a command, but it cannot know what happened after the command ran.

So the important part of a coding agent is not only whether the model can write code. It is whether:

you have given it an environment where it can observe, act, verify, and receive feedback.

What Is a Harness, and Why Is It Worth Learning?

I eventually realized that one of the most important terms for understanding coding agents is:

Harness.

It is not an easy word to translate directly.

You can think of it as a “control framework,” an “execution framework,” or, more visually:

the mechanism that connects an LLM to the real world.

If the LLM is the brain, the harness is like its nervous system, limbs, and safety belt.

It determines what the AI:

• can see
• can operate
• can read from files
• can write to files
• can execute as commands
• can access on the network
• must ask the user to approve
• should do when errors occur
• should report when the task is complete

In other words, a harness is not something that makes AI smarter.

It is what makes AI usable, constrained, observable, and controllable.

That distinction matters.

If you use an LLM only as a chatbot, you mostly ask it questions and copy-paste the answers.

But once you place an LLM inside a harness, it can start executing tasks.

It can read a project. It can understand the file structure. It can search the codebase. It can modify files. It can run tests. It can see errors. It can fix them and try again. It can move step by step toward the result.

That is the core of the agent loop.

The Agent Loop: Where AI Starts Doing Work

The most important realization for me while learning how coding agents work was this:

An agent does not stop after one model call.

It operates in a loop.

Roughly:

1. The user submits a task
2. The system gathers context
3. It builds the prompt
4. It calls the model
5. The model decides the next step
6. If it needs a tool, it calls the tool
7. The tool returns an observation
8. The observation is sent back to the model
9. The model evaluates the new information and continues
10. The loop continues until the task is complete or human confirmation is needed

This loop looks simple, but it is the core of what gives an agent its capabilities.

The model does not know everything in one shot.

It needs to inspect files. It needs to try things and fail. It needs to see command output. It needs to reason again based on error messages. It needs to know what it changed a moment ago. It needs to decide whether to continue or stop and report.

That is also why I wanted to build OpenZeroCode myself.

If I only use someone else’s tool, I can feel that it is powerful, but I may not truly understand where that power comes from.

Once I implemented a simplified version myself, I began to understand:

an agent’s capability is not one isolated feature. It is a system-level capability.

Why I Think of It as “Reins for AI”

I think the metaphor of “reins for AI” fits the current agent era very well.

AI is like an extremely fast horse.

It runs fast. It is powerful. It can carry you a very long way.

But the question is:

Do you know how to ride it?

Without reins, it may run in the wrong direction. If the reins are too short, it cannot do anything useful. If you do not understand how to control it at all, you are left standing on the side watching someone else ride.

That is also how I think about OpenZeroCode.

For me, OpenZeroCode is more than a coding agent.

It is the beginning of learning how to build my own reins for AI.

I want to know:

• How do I connect AI to my tools?
• How do I help AI understand my projects?
• How do I let AI act without letting it act recklessly?
• How do I define permissions?
• How do I preserve memory?
• How do I observe what it is doing at every step?
• How do I let it recover after making mistakes?
• How do I make it a work partner instead of a black box?

I believe the coming AI era will not consist only of a few large companies offering universal agents.

Instead, more and more people will build agents of their own and connect them to their own workflows, tools, data, and rules.

Everyone will need a set of AI reins that belongs to them.

The Design Goals of OpenZeroCode

The goal of OpenZeroCode is not to become the most powerful coding agent from the beginning.

I want it to be:

minimal but complete.

That means:

the features can be simple, but the basic agent flow should be complete.

I want it to have several properties:

• understandable
• modifiable
• extensible
• able to connect to LLMs
• able to define tools
• able to read and write files
• able to execute commands
• able to demonstrate a complete agent loop
• able to grow gradually into a more capable agent

I do not want it to become complex, hard to read, and hard to modify from the start.

The main value of this project is not “having lots of features.” It is that every module can be understood.

I want OpenZeroCode to be a project for “understanding coding agents from zero.”

Instead of chasing the largest feature set immediately, I want every module to be clear enough that I can understand how an agent thinks, acts, gets constrained, and can be extended.

The Overall Architecture of OpenZeroCode

You can think of OpenZeroCode as several main parts:

• User Interface
• Session Manager
• Context Manager
• Prompt Builder
• Agent Loop
• LLM Provider
• Tool Router
• Tools
• Observation / Feedback

The overall flow looks roughly like this:

The most important thing in this diagram is not which box is the most powerful.

It is what the diagram expresses:

a coding agent is a loop-based system, not a one-shot question-and-answer system.

After the user provides a task, OpenZeroCode creates a session, gathers context, builds a prompt, and calls the model.

The model can answer directly or choose to use a tool.

If the model uses a tool, the Tool Router dispatches the request to the appropriate tool, such as reading a file, writing a file, searching, executing a shell command, or calling another custom tool.

After the tool finishes, the result becomes an observation and is fed back into the agent loop.

The model then decides what to do next based on that observation.

That is how AI moves from merely “answering” to actually having the ability to act.

Coding Agents Will Not Stop at Coding

One thing I find especially interesting about coding agents is this:

they look like programming tools on the surface, but they are really an early form of a much larger trend.

Why are coding agents maturing first?

Because code, terminals, and file systems are naturally suited to text-based models.

Code is text. Error messages are text. Terminal output is text. File paths are text. Git diffs are text. Test results are text too.

So coding is the most natural experimental ground for AI agents.

At first, a coding agent may only help you:

• read code
• modify files
• run tests
• fix bugs
• generate documentation
• refactor
• explain architecture

But the next step will inevitably go broader.

It will become a computer agent.

That means it will operate not only code, but the entire computer.

It could:

• operate the operating system
• manage files
• use the browser
• control applications
• organize data
• analyze spreadsheets
• operate admin systems
• automatically reply to customers
• generate scripts for media content
• edit videos
• create music
• publish content
• monitor data
• assist with business decisions

At that point, a coding agent is no longer just a coding agent.

It becomes a kind of AI work partner.

Or, more precisely:

coding agents are simply one of the earliest mature forms of AI agents.

Code, terminals, and file systems are naturally easy for text models to operate.

But once those capabilities extend outward, the result becomes an agent that can operate an entire computer, or even an entire business workflow.

From Coding Agent to Personal AI Operating System

This is how I imagine the future:

What this diagram is trying to show is:

the coding agent is only the entry point.

The larger trend is that everyone will have their own AI operating layer.

That layer does not necessarily mean the operating system itself.

It is more like an AI control interface between you and your computer, tools, data, and workflows.

It knows your rules. It knows your preferences. It knows how your tools work. It knows which tasks can run automatically. It knows which tasks must ask you first. It knows which data it is allowed to read. It knows which operations are risky. It knows how far each task has progressed. And over time, it accumulates the context of your work.

I do not think this will belong only to large companies.

In the future, every person, every team, and every small company may need its own AI agent control system.

Not because everyone wants to reinvent the wheel.

But because everyone’s workflow is genuinely different.

Your tools are different. Your data is different. Your risk tolerance is different. Your work habits are different. Your business processes are different. Your automation boundaries are different too.

So a more universal agent is not necessarily a better one.

What really matters is:

can you control it?

Why Build My Own Instead of Only Using Existing Tools?

This is a question I have asked myself repeatedly.

If there are already so many coding agents available, why build OpenZeroCode myself?

My answer is:

using a tool and understanding a tool are two different things.

With Cursor, I can write code faster. With Claude Code, I can modify projects faster. With Codex, I can let AI complete tasks for me.

But if I want to understand how these tools are assembled underneath, I need to take one apart myself.

I want to know what the smallest core of an agent really is.

Is it the prompt? Is it tool calling? Is it context management? Is it the approval flow? Is it shell execution? Is it memory? Is it the task loop?

Eventually, I realized the answer is not any single module.

It is how all of these parts are connected.

That is where OpenZeroCode has the most value for me.

It is a place where I can add things gradually, run experiments, and slowly understand agent architecture.

I can start with the smallest agent loop. Then add file tools. Then shell tools. Then permissions. Then memory. Then task planning. Then web fetch. Then a UI. Then a more complete workflow.

The process itself is the learning.

What OpenZeroCode Means to Me

OpenZeroCode is not a story about “I built a stronger coding agent.”

At least, not yet.

It is more like:

I wanted to understand the AI agent era, so I started by building my own reins.

I think AI agents will become much more capable over the next few years.

Models will become cheaper. Context windows will become longer. Tool calling will become more reliable. Computer use will mature. Local models will become increasingly practical. Everyone will be able to connect more tools.

But the stronger these systems become, the more important “control” becomes.

The more capable AI gets, the less you can rely on intuition alone when using it.

You need to know what it can see. You need to know what it did. You need to know why it did it. You need to know when it should stop. You need to know whether its actions can be rolled back. You need to know whether it actually completed the task.

None of these problems is solved simply by switching to a stronger model.

They require a harness.

They require a control layer.

They require workflow.

They require permissions.

They require memory.

They require observation.

They require human approval.

In other words, what we need is not only a fast horse.

We also need reins that let us truly control it.

Closing: OpenZeroCode Is My Practice Ground for the Agent Era

I did not build OpenZeroCode because I thought I could immediately create the most complete, powerful, and mature coding agent.

Quite the opposite.

I built it because I know I still have more to learn.

I want to learn the full architecture of coding agents. I want to learn how to design a harness. I want to learn how an agent loop works. I want to learn how tools connect. I want to learn how permissions should be controlled. I want to learn how context should be assembled. I want to learn how errors should feed back into the system. I want to learn how an AI system goes from “able to answer” to “able to do work.”

For me, OpenZeroCode is the starting point of that learning process.

It is a small coding agent. It is also an early form of an AI agent control system. And it is a place where I can practice building my own personal reins for AI.

I believe many people will have agents of their own in the future.

Not everyone will write the code themselves. But everyone will need an AI workflow suited to them. A system that knows their rules. An interface that can operate their tools. An AI control layer that can be trusted, constrained, and extended.

OpenZeroCode is my first step in that direction, starting from coding agents.