DEV Community: 路多辛

As the number of tools available to agents continues to grow, how can we prevent models from becoming overwhelmed?

路多辛 — Tue, 08 Sep 2026 15:22:55 +0000

It is well known that the more tools an agent has, the broader its capability boundary becomes. However, as the number of tools increases, so do the challenges: the model must simultaneously understand the purpose, parameters, and invocation methods of hundreds of tools, which not only consumes context but also reduces the probability of selecting the correct tool. covo-agent comes with over 100 built-in tools. To address this issue, it does not treat tool quantity as capability per se; instead, it employs two independent mechanisms to deliver the right tools to the model at the right time.

Tiered Tool Registration

Tool registration in covo-agent is centralized within the extension initialization of the internal/tools package. Tools are organized into approximately 29 batches by function, covering a wide range of capabilities:

Coding & File Operations: Patch application, file editing, diff viewing, unified file search, test generation, code graph analysis.
Planning & Goal Management: To-do lists, plan updates, goal creation/query/update.
Memory & Conversation: Memory recall/storage/forgetting, semantic vector memory, conversation retrieval and derivation.
Media & Creation: Text-to-speech, image/video/music generation, transcription, voice interaction, canvas visualization.
Communication & Collaboration: Feishu Docs/Base/Drive, sub-agent spawning and orchestration, Kanban boards, swarm collaboration.
Execution & Isolation: Process management, sandboxing, remote execution, deployment, tmux.
Hardware & Desktop: I2C, SPI, serial ports, macOS desktop control (computer use).

Profile Pruning Determines Tool Ownership

The first mechanism operates during the tool registration phase. covo-agent defines four tool profiles: minimal, coding, messaging, and full. After registration, the tool list is pruned according to the active profile.

This layer semantically defines "which tools this Agent possesses," determining the Agent's overall capability boundary rather than what is visible in a single conversation. The distinctions among the four profiles are as follows:

minimal: Retains only a few core tools: conversation retrieval, message sending, to-do, plan update, exit planning mode, clarification, and structured output (7 tools in total).
coding: Covers coding, execution, debugging, memory, and goal management, targeting programming-centric use cases.
messaging: Targets communication and channel-oriented scenarios, retaining message sending, scheduled tasks, swarm collaboration, Kanban, voice, and media generation.
full: No pruning; all tools are available.

Pruning uses a whitelist approach. Each profile corresponds to a mapping table of "tool name → allowed profiles." If a tool is not listed in this table, it is skipped entirely under restricted profiles rather than being allowed by default. This ensures that expanding the toolset does not automatically pollute restricted scenarios; newly added tools will not appear in minimal or coding unless explicitly assigned to them.

Toolset Filtering Determines Per-Turn Visibility

The second mechanism activates before each model invocation. covo-agent implements a toolset system comprising approximately 20 basic toolsets (file system, search, shell, Git, patch, documentation, code execution, media, memory, skills, delegation, etc.) and 3 composite toolsets (coding, creative, full).

Composite toolsets reference other toolsets via Includes, which are recursively expanded and deduplicated during resolution. For example, when expanded, the coding toolset actually covers 25 tools across file system, search, shell, Git, patch, documentation, and code execution.

This system is driven by ToolsetFilter, a lifecycle hook that filters out tool definitions irrelevant to the current request based on the platform-specific toolset before each model call. Different deployment platforms have their own default toolsets: the code platform defaults to coding plus web, memory, skills, and productivity; the minimal platform provides only file system, search, and shell; other platforms default to full.

Consequently, in any given conversation turn, the model sees not the entire set of tools the Agent possesses, but a pruned subset tailored to the current scenario.

Differences and Synergy Between Profile Pruning and Toolset Filtering

These two mechanisms are often confused, yet their responsibilities are orthogonal. It is important to note that while the term "coding" appears in both contexts, it refers to two distinct concepts: "coding" in profiles is a tier, whereas "coding" in toolsets is a toolset; they belong to different dimensions.

Profile pruning answers "which tools this Agent possesses." It occurs during registration and establishes the capability boundary.
Toolset filtering answers "which tools to send to the model in this turn." It occurs before each invocation and adapts dynamically to the scenario.

The former represents convergence of the "capability surface," while the latter represents convergence of the "attention surface." Together, they ensure that even an Agent with hundreds of tools exposes only task-relevant tool definitions to the model in any specific conversation turn.

Tool Bootstrapping: No Need to See All Tools at Once

In addition, covo-agent provides a set of "discovery" tools: tool_search, tool_describe, and tool_call. The model does not need to receive all tool definitions upfront; instead, it can retrieve and review a tool’s description on demand, then invoke it by name when needed.

This further alleviates the burden of having too many tools: the model can focus on the current task and dynamically discover required capabilities as needed, rather than passively digesting all tools at once.

Summary

The versatility of covo-agent stems not from indiscriminately enabling all tools, but from layered convergence: defining capability boundaries via profiles during registration, scoping attention via toolsets during invocation, and supplementing these with on-demand discovery. The value of a tool system lies not in quantity, but in delivering the right tools to the model at the right time.

Built in Pure Go: The Story Behind covo-agent, a CLI General-Purpose AI Agent

路多辛 — Sat, 29 Aug 2026 04:15:06 +0000

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 code mode for development and a general mode 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, testgen commands 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

Why Use Go to Build AI Agents? Reflections on covo-agent's Technology Choices

路多辛 — Fri, 28 Aug 2026 14:26:12 +0000

In the AI Agent domain, Python is virtually the default choice, making Go a relatively rare sight. However, covo-agent’s adoption of Go is not an act of contrarianism but rather the result of a series of deliberate engineering trade-offs. Below, we walk through the rationale behind this technology selection.

A Restrained Dependency List

The benefits of this choice are most immediately apparent in the dependency manifest. covo-agent has only about fifteen direct dependencies: a self-developed TUI library (covonaut), a CLI framework, a WebSocket library, observability components, and a pure-Go SQLite driver, among others.

There is no bulky runtime, no all-in-one framework, and no deeply nested transitive dependencies. For a tool intended to run reliably over the long term, such restraint is itself a significant advantage.

Effortless Cross-Compilation

Within the Go ecosystem, there are typically two approaches to integrating SQLite: one leverages CGO to call the native C implementation, while the other uses a pure-Go port. covo-agent opts for the latter, translating SQLite’s C codebase into Go and eliminating any reliance on a C compiler.

The immediate payoff is dramatically simplified cross-compilation: from any platform, a single command can produce binaries for Linux, macOS, and Windows without requiring platform-specific C toolchains or encountering “it compiles on my machine” issues. For a tool that must be distributed across platforms and integrated into CI pipelines, this is a tangible convenience.

Single-Binary Deployment

The combination of minimal dependencies and CGO-free builds yields a powerful outcome: a single, self-contained binary.

This means deployment requires no interpreter installation, no dependency fetching, and no runtime environment configuration—simply place the executable on the target machine and run it. For individual developers, this lowers the barrier to trial; for teams, it eliminates maintenance overhead caused by environment inconsistencies.

Concurrency Model and Resource Efficiency

Agent workloads are inherently concurrency-intensive: multiple tool invocations may execute in parallel, streaming outputs continuously push data, and messaging platform bridges must maintain numerous simultaneous connections. Go’s goroutine and channel model is ideally suited to handle such high-concurrency I/O-bound tasks.

As a compiled language, Go offers low resource footprint and fast startup times—critical advantages for tools like this, ensuring that runtime overhead never becomes a bottleneck.

Conclusion

It must be acknowledged that Go’s library ecosystem for AI and LLM-related tasks is indeed less mature than Python’s. However, in the context of agent development, the core challenges lie not in model training or inference, but in orchestration, tool invocation, context management, and flow control—all areas where Go excels as an engineering language. Go’s type safety, deployment simplicity, and efficient concurrency model deliver precisely the kind of engineering benefits that make it an ideal fit for building AI agents.