Zarlmono puts Go agent tooling in one repo

Zarldev uses zarlmono as the home for zkit, a set of small Go packages for AI applications. The repo gives Go developers an agent loop, tool calling, guardrails, history compaction, model providers, MCP support, and app infrastructure in one workspace.

The project aims at developers who want agent pieces they can compose without adopting a full platform. You can build a minimal agent from a provider, a tool registry, and the runner loop. You can add guardrails and compaction through runner options. You can swap Anthropic for OpenAI, Gemini, DeepSeek, llama.cpp, or Ollama without rewriting the loop.

Zarldev also builds its own apps on those same parts. zarlcode provides a terminal coding agent and TUI. zarlai adds a smart-home and multimodal assistant. swebench-eval runs SWE-bench evaluations through the same shared assembly that powers zarlcode.

The workspace uses go.work to join six modules: zkit, zarlcode, zarlai, swebench-eval, examples, and the root tooling module. That split matters because AI agent code tends to blur product code, evaluation code, local services, and provider glue. Zarldev keeps those concerns separate while letting them share contracts.

The strongest idea in zkit sits in the tool system. A tool implements two methods: one method returns a definition, and one method executes the call. The JSON schema comes from the Go args struct, so you do not hand-write schema files for each tool. That choice keeps tool definitions close to the code that handles them, which reduces drift between model-facing schemas and runtime behavior.

The runner design also reflects a clear bet. Zarldev treats the agent loop as a reusable primitive rather than an app feature buried inside one TUI. The runner streams model output, dispatches tools, enforces options, and returns a final result. App builders can place that loop inside a terminal agent, an evaluation harness, or a multimodal assistant.

zarlcode shows the toolkit under pressure. A coding agent needs file access, process execution, session storage, context management, and guardrails around tool calls. Zarldev stores sessions in SQLite so users can resume work with zarlcode -continue. The TUI sits above a substrate that can also run headless from a prompt file.

That architecture gives evaluation code a cleaner path. swebench-eval can build its agent through the same shared assembly as zarlcode, which helps developers compare agent behavior without creating a separate evaluation stack. Teams that test coding agents often lose time because the product path and benchmark path diverge. Zarldev tries to keep those paths close.

The examples module serves a different role. Zarldev includes small harnesses such as health checks, release gates, and Hacker News upvote flows so developers can study one pattern at a time. That style helps because agent systems fail in ordinary edges: tool schemas drift, providers return odd payloads, context windows fill, or a guardrail blocks the wrong call.

The repo also draws a useful safety boundary. Zarldev says zkit provides shared infrastructure, not a sandbox. That distinction matters. The toolkit can run processes, mutate files, fetch through a browser-backed path, connect to MCP servers, and call external model APIs. Developers must choose tools, credentials, guardrails, and policies for their own threat model.

Developers can start with the zkit README for package tiers and version notes, then inspect zarlcode for the terminal agent and zarlai for the assistant app. Zarldev also publishes a documentation site at zarldev.github.io/zarlmono.

Zarlmono will appeal most to Go developers who want agent infrastructure they can read, test, and replace in pieces. It gives them a practical path from a small tool-calling loop to a working coding agent, with enough shared structure to support evaluation and product work in the same repo.