A basic agent loop fits on one screen. Send the conversation and a list of available tools to a model, run whichever tools it asks for, add the results to the conversation, and repeat until it answers. Many engineers write one in an afternoon, and it works. That early success raises a fair question: why adopt a harness at all?
The answer depends on what you count as the harness. If it means the loop, building your own is reasonable.
Count everything a team needs before it can rely on an agent, and the loop is a small fraction of the work. Most of the cost arrives after the first version ships.
The harness is much more than the loop
Once more than one person depends on an agent, it tends to need all of these layers. Each one has a question it must answer well.
| Layer | The question it must answer |
|---|---|
| The agent loop | What happens on a timeout, a malformed tool request or a provider error? |
| Context | Which instructions and knowledge reach the model, and how large can that get? |
| Model choice | Can you change models without rewriting the agent? |
| Identity and access | Who is asking, what may they do, and where is that decision recorded? |
| Scheduled and durable work | What happens to a run interrupted halfway through? |
| Records and usage | Can an administrator answer who did what and what it cost? |
| Interfaces | Where do people actually use it: chat, an API, their own assistant? |
| Administration | Can someone who is not an engineer manage access? |
| Upgrades | Who keeps all of the above current as providers and libraries change? |
The hard problems live around the loop
The loop is well understood and short. The layers around it each bring their own failure modes, and they rarely show up in a demo.
- A scheduled run is interrupted after it sent a message but before it recorded that fact. On restart, does it send the message again?
- A sensitive tool is protected by an instruction in the prompt. Does it stay protected when a document the agent reads contains a contrary instruction?
- A chat window built for one team gains requests for sign-in, file uploads, branding and a mobile layout. Is it now a product you maintain?
- A model provider changes how its tools or structured answers behave. Who notices, and who tests every agent that depends on it?
None of these problems is hard on its own.
Together they are a product, and a product needs an owner long after the afternoon it took to write the loop.
Count the cost over years, not weeks
Compare building and adopting over the life of the system.
- First version. Building is fast for the loop and slow for everything around it. Adopting costs time to learn someone else's conventions.
- Security review. If you build, every layer is yours to design and review. If you adopt, you review the integration and the defaults you inherit.
- Upgrades. If you build, you track every provider and library change yourself. If you adopt, you track upstream releases and test before upgrading.
- People. A homegrown harness concentrates knowledge in whoever wrote it. An adopted one has documentation and a community outside your team.
- Leaving. A homegrown format has only your migration path. An adopted one tends to use formats other tools also read.
Adoption is not free. It moves cost from writing code to evaluating, configuring and upgrading someone else's code. The real question is which kind of cost your team can sustain.
Building your own is right in a few clear cases
Four situations justify owning the whole harness.
- The harness is your product. If you sell an agent runtime, or your advantage lives in the loop itself, own it.
- Your constraints are unusual. An environment no available runtime supports, a latency budget where every layer matters, or a company-wide language standard that existing runtimes do not fit.
- The job is narrow. One well-defined model call inside an existing service, with no people, no schedule and no access decisions. You may not need an agent at all.
- You are learning. Writing a loop is an excellent way to understand what the layers above it are for, even if you adopt one afterward.
If none of these applies, adopt the parts others maintain and spend your effort where your organization is different: its context, its tools and its processes.
How Hubzoid splits the work
Hubzoid's approach is to adopt existing open-source projects where they do the job well, and to build only the parts needed to make them work together for a team. In release 1.0.1, the adopted parts include:
- The agent loop from the OpenAI Agents SDK or the Claude Agent SDK. The model setting decides which one runs.
- Model routing through LiteLLM, which reaches providers such as OpenAI, Anthropic, Azure OpenAI and OpenRouter.
- The chat app and accounts from Open WebUI, including sign-in.
- Durable scheduled work on DBOS, a workflow engine that saves each finished step so an interrupted run can resume.
- Smaller libraries for storing permissions, upgrading databases and serving MCP.
Hubzoid builds what connects them: the layout of the Hub, the access check in front of every sensitive tool and the record behind it, the Console, the ways to write scheduled work, the adapters for Slack, WhatsApp, Telegram and webhooks, the written checks known as evals, backup and restore, a health check, and a gateway that serves several Hubs behind one sign-in.
The Hub itself stays independent of the loop underneath. The same folder of instructions, knowledge, skills and tools runs on either agent runtime. Tools can also come from MCP servers, an open protocol that many assistants support, so the work you put into them is not locked to one runtime.
Adopting brings its own costs
Adoption is a trade, and it helps to see the costs Hubzoid itself carries.
- Version limits. Hubzoid's dependency versions are bounded and locked for each release. An upgrade is a deliberate, tested step, not something that happens by accident.
- Inherited requirements. The durable engine needs a fairly recent version of SQLite, the small database built into many Python installations. Hubzoid's health check reports it, and the container image moved to a newer base system for that reason.
- Inherited behavior. The durable engine ties each run to the code that started it. After an edit or an upgrade, runs that were queued or interrupted under the old code are cancelled at start so they cannot block the queue. That is a sound rule, and it is one operators need to know.
- Defaults to review. The OpenAI Agents SDK sends traces of each run to OpenAI by default. Hubzoid keeps that export off unless an administrator turns it on.
- License terms. Hubzoid's own code is open source under the Apache 2.0 license, including the Console and the access controls. Its dependencies keep their own licenses and terms, which belong in any adoption review.
These costs are real, but for a team whose product is a business process, they are usually easier to carry than every layer built alone. They are also visible, in release notes and a health check rather than in someone's memory.
Build where you are different
The loop is the part everyone can write. The layers around it are where most of the cost lives, and they look much the same from one company to the next. So ask one question before you start.
Is the harness your product, or is the business process your product?
If it is the process, adopt the plumbing and put your effort into the context, tools and routines that make your organization different.
For more, see how Hubzoid's pieces fit together or read when building more software stops helping.