I believe every developer understands that impulse: when a tool doesn't feel right, you just want to build your own. This was a major reason for developing covo-agent. But there was another reason: to validate the functionality of the Agent framework I wrote, covonaut.
It Started with the Desire to Write a Go Agent Framework
By 2026, AI Agents were no longer just a concept on a PowerPoint slide; they were a tangible engineering reality. However, after looking around the Go community, I found a stark reality: while Python had a flourishing ecosystem of agent frameworks, Go had very few contenders. The few that were somewhat usable were either awkwardly ported from Python frameworks or were still stuck in the "toy stage" of "calling an API + a for loop." They lacked context compression, a decent tool system, state management, and, not to mention, the fault tolerance and observability required for production environments.
So I thought, why not write one myself?
Once the idea took hold, I couldn't suppress it. I set a few hard rules for myself:
- Zero external dependencies: As an agent framework, it should minimize reliance on external libraries as much as possible. Fewer dependencies mean lower risk.
- Pure Go implementation: To fully leverage Go's concurrency and deployment advantages, it had to be a single binary.
- Production-ready: It needed to be stable enough for real-world scenarios.
From the core agent loop, tool registration, context compaction, and retry/circuit-breaking, to the DAG/Pregel graph engine, JSONL session storage, workflow orchestration, and MCP bridging, and even agent communication protocols like A2A/ACP/AGUI/A2UI, as well as a zero-dependency terminal UI engine... bit by bit, the development of covonaut was finally completed.
The process of writing a library was a mix of pain and joy. The joy came from building every layer exactly as I envisioned, but the pain came from the underlying uncertainty, never knowing if it would actually be good to use.
After Finishing the Framework, the Biggest Problem Emerged
The unit tests were all green, and the coverage looked great, but I knew this proved nothing.
Whether an agent framework is good isn't determined by how elegant its API design is or how fast its tests run. It's about whether it can run for dozens of cycles in a real environment without crashing. How should it recover from a failed tool call? How should it compress context when it gets too large? How can a streaming output be resumed after an interruption? How should it handle the different tool schema compatibilities of different models? Only a real "load" can provide the answers to these questions.
I had two choices:
- Write a few demos, get a "hello world" working, and post an article titled "My Framework Supports XXX." It would be decent, but not very substantive.
- Eat my own dog food by using covonaut to build a real product and see how the experience was.
I chose the latter, and thus, covo-agent was born.
covo-agent is covonaut's Number One Tester
covo-agent is a general-purpose AI Agent that runs in the terminal. It sounds simple, but a truly usable Agent requires a lot more:
- The user experience needs to be good: I implemented a beautiful and capable TUI, with streaming responses, tool call status, session history, a model picker, theme switching... all based on the terminal UI engine that comes with covonaut.
- Scenarios need to be separated: There's a
codemode for development and ageneralmode for daily work, each with its own toolbox and prompt strategies. - The tools need to be handy: File I/O, shell execution, code search, patch application, review, test generation, Git worktree... The
analyze,review,testgencommands you use in covo-agent are all powered by the framework's tool extensions. - Memory needs to be persistent: Sessions, memory, skills, goals, commitments, project-level configurations... allowing the Agent to remember things across sessions.
- Safety is the bottom line: Approval gates, allow/deny policies, sensitive information redaction, sandboxes, audit logs, infinite loop recovery... The stronger the automation, the clearer the boundaries must be, or you're just planting landmines for yourself.
- Integration needs to be open: It adapts to almost all major model protocols on the market, so you can use any provider's model. It can also collaborate with external systems via MCP, ACP, LSP, plugins, and gateways.
In short, covo-agent is covonaut's number one user and its most comprehensive, most demanding test case.
After Closing the Loop, Both covonaut and covo-agent Are Growing
Once the framework and the product formed a closed loop, they began to promote each other's growth.
Every pitfall encountered in covo-agent can almost always be fed back to covonaut. For example, while recently polishing the TUI model picker, I found the cursor editing experience in the input box to be poor—no arrow key movement, backspace only deleting from the end, and the cursor taking up a character position. Tracing it to the source, the rendering layer of the terminal UI engine wasn't granular enough. After fixing the product-level experience, I added capabilities like cursor rendering and differential re-rendering back to the framework layer, benefiting both repositories.
The reverse is also true. Every time covonaut gets an upgrade, covo-agent gets to try out the new features first.
This is the value of dogfooding: if you don't use your own product, you'll never know what's wrong with the framework you wrote.
Final Thoughts
Some might ask: isn't this just reinventing the wheel?
My answer is: if all wheels are round, then there's no need to reinvent it. But if I want to research why wheels are round and how round they need to be to not be bumpy, then this step is one I must take myself. covonaut allowed me to take apart and reassemble every layer of an agent, and covo-agent gave all of that a real purpose.
Together, these two things can be summed up in one sentence: First, I wrote the library to figure out how an agent should be written; then, I built the product to prove that I truly understood how to write it.
Now, I can't do my daily work and development without covo-agent. If you're also looking for an agent framework or a handy agent in the Go ecosystem, you're welcome to try these two projects and help polish them to be even better.
covo-agent: https://github.com/covoyage/covo-agent
covonaut: https://github.com/covoyage/covonaut
Top comments (0)