· 2 min read · Wladmir Bonazza
Four months building Kodzonia. Thirty days of numbers.
7,209 calls, 3.8 billion tokens and 529 subagent dispatches — on real code, not a demo. What the agents are actually doing, and the architecture decision behind it.
For the past few years I've been building complex AI solutions for real problems — autonomous agents, multimodal systems, voice, integrations, MCP, data migration and automations running inside environments that existed long before AI did.
Kodzonia came out of that experience.
Four months of building. The numbers below cover only the last 30 days.
7,209 calls. 3.8 billion tokens.
That's a slice of Kodzonia's audit dashboard — the agentic engineering platform I've been building at Zonialabs.
And the interesting part isn't the token volume. It's what the agents are doing.
I use Kodzonia daily on real code — including the code that runs BeCash's operation, where I'm CTO. Kodzonia itself is also built with Kodzonia. And it already has code accepted outside the house: pull requests merged into an external Linux firmware project.
The most-used tools over those 30 days:
run_shell · read_file · code_search · dispatch_subagent · edit_file · apply_changeset · git_inspect
1,495 shell executions. 740 file reads. 640 code searches. 529 subagent dispatches. Plus edits, changesets, Git inspections and memory.
This isn't autocomplete.
These are agents reading the repository, searching code, delegating work to other agents and changing the system — working with the context of the whole project, not just the open file.
There's an architecture decision behind that: Kodzonia was not built around a single model.
Over those 30 days, the gateway orchestrated models from Anthropic, Kimi and OpenAI.
The model is part of the architecture — not the whole architecture.
After years putting AI into real systems — and four months building Kodzonia — one thing became clear to me:
AI in production doesn't die at the model. It dies in week two.
The demo works.
Then it meets the legacy code. The integration nobody documented. The architectural decision from months ago. The context that vanished between one session and the next. A second project that depends on the first. And the cost of treating every task as if it needed the same model.
It was that "after the demo" that made me build Kodzonia.
I'm not building another autocomplete.
I'm building an engineering system where agents work with context, memory, multiple projects, tools and different models as parts of the same whole.
Kodzonia is also one of the technologies that gave rise to Zonialabs.
So far I've built far more than I've shown.
That changes from today.
I'll be opening up the numbers, the decisions and the mistakes along the way — and sharing what I learn as the product evolves.
For those already past the demo stage: what was the first problem that showed up when you put AI to work on a codebase that already existed?