AI agents can do real work now - not just answer questions, but carry out whole tasks on your behalf: sift your inbox, pull together research, draft and send a report, or, if you write software, open a branch, run the tests, and file the pull request - all while you sleep. Getting a model to do that reliably took more than a smarter model, though. It took figuring out how to put one to work.
The rise of the coding harness
The first harness was just the chat box - a model wrapped in a conversation. That was enough to answer questions, but people quickly found that getting real work out of a model took more than a place to type, and that different kinds of work wanted differently shaped tools. Specialised harnesses followed, and the coding harness was the one that took off: writing, running, and fixing code is a tight, verifiable loop with an obvious payoff, which made it the ideal proving ground for agents.
So the innovation concentrated there first. The techniques that now define agentic AI - long-running loops that let an agent keep working on its own, sub-agents that split a job across specialists, the ability to run unattended in the background, planning which tools to reach for - were pioneered and hardened inside coding harnesses like Claude Code before they spread to anything else. Same model, far better results, because the harness gives it hands. Today it is the harness, not the raw model, that decides how much useful work you actually get.
The trust problem
A harness is still just one agent at a terminal, though. Turning that into something you would trust with your credentials and your business is a different problem, and the tools we found all failed it in one of a few ways. The self-hosted agents get the biggest thing right but fumble the secrets. Tools like OpenClaw have the correct instinct - run on your own hardware, keep your data local - but they keep configuration, memory, and skills as plaintext on disk, with no vault between those files and an autonomous agent that has shell access. And that agent can be turned on you: Cisco's AI Defense team scanned the most-downloaded OpenClaw skill and found it silently sending data to a server the skill's author controlled, and using prompt injection - a hidden instruction slipped into content the agent reads - to get around its safety limits, all without the user's awareness - and they note OpenClaw has already been reported to leak plaintext API keys.
Once an agent can be steered like that it becomes a security liability.
And even setting security aside, a bare harness stops at the edge of a single task. The capabilities that make agents useful in production are exactly the ones a bare CLI doesn't ship. Persistent long-term memory - so an agent carries your preferences and conventions across sessions instead of starting from zero every time - is now widely considered essential for goal-oriented agents, yet most harnesses forget everything the moment the process exits. Sandboxed, containerized execution is treated as a baseline for running AI-written code safely, yet among the major coding CLIs only Codex ships it on by default - Claude Code and Gemini CLI leave it opt-in. Add secret isolation, budgets, an audit trail, and a second agent to check the first, and you have a long list of things every serious deployment needs and almost no harness provides on its own.
How Hezo solves this
We couldn't find a single tool that did everything we needed on hardware we controlled, so we built one. The move is to stop treating the harness as the whole system and start treating it as one layer of a larger one.
The meta-harness architecture
One conviction drives the design: add uniformity above the harnesses. A meta-harness sits above a harness and becomes a control plane - it can enforce a budget, sandbox the run, swap a secret at the network edge, inject a learned rule, or halt a run that isn't actually finished, all without reaching inside the harness or dumbing it down. The harness keeps its full native power; the meta-harness platform governs how it is used - and supplies the things a bare harness never had.
The CLI harnesses do what they are good at; the platform does what all of them need. You can put Claude Opus on architecture decisions and DeepSeek on routine implementation - same platform, same safety, different price points.
Dynamic workflows and reusable teams
Not every job wants the same team. A software project wants a software team - engineer, QA, architect, security reviewer, designer. An investment-research project wants none of that - analysts, a risk reviewer, someone who models scenarios. Different roles, different expertise, different shape.
Harnesses already do a small version of this: hand Claude Code a task and it spins up sub-agents to fit the work. Hezo lifts it to the team level. Start a project from a template matched to the work, or have the CEO assemble one; tune the roles and prompts to your standards; then snapshot that team and reuse it on the next project. Shape a team once, deploy it again.
The reason to prefer a team over a lone agent holds even outside Hezo: the hard part of AI work isn't producing output, it's verifying that the output meets the requirement. A single agent grading its own homework is where things go wrong. Split the work across roles and the checks become structural - QA verifies the engineer; the security reviewer and designer sign off on the architect's spec before code is written. Every handoff is a checkpoint.
You steer by outcome
You don't write prompts for Hezo. You create goals and tasks, and the team works toward them.
You can talk to the CEO in real-time chat - describe what you want, answer its clarifying questions, and it turns the objective into well-scoped tasks. That chat sits right alongside the project dashboard and task board, so you watch work move, open any task, and change direction while it runs. The Captain breaks tickets down, assigns them, and re-checks progress against your goals on a schedule, so drift is caught without you babysitting it - you get up-to-date project summaries instead of a firehose of activity. In short: the CEO answers what to build, the Captain answers how to build it.
In addition to this Hezo has a concept of goals - objectives which team Captains will check on a regular basis to ensure that the team is heading in the right direction in terms of output and outcomes.
Security by design
Because these agents run real, often AI-written code, we assume any agent can be compromised - by a bug, a jailbreak, or a prompt injection hidden in an issue or a web page - and we make sure there is nothing worth stealing when it is. In a survey of 750 executives, 54% of organizations reported experiencing or suspecting an AI-agent security incident in the past year; the root cause is almost always an agent holding a credential it never needed to see.
An agent needs to use a secret, not know it. So every credential is referenced by a placeholder - never the real value:
Authorization: Bearer __HEZO_SECRET_STRIPE__The real key lives encrypted with AES-256-GCM in a host vault, unlocked by a 12-word BIP39 master key only you hold. When a request leaves the container, the egress proxy checks the destination against that secret's allowed hosts and substitutes the real value only on a match; send it anywhere else and the proxy blocks the request. No secret ever enters a model's context window, so there is nothing to extract even under a successful injection.
The same posture runs end to end. Each agent is sandboxed in its own Docker container - read-only root filesystem, isolated process and network namespaces, no Docker socket mounted, network egress only through the proxy - and destroyed when the task finishes. A compromised agent cannot reach the host, spawn siblings, phone home, or use a secret against a host you never scoped it to. The security docs have the full picture.
Knowledge, memory, and a team that gets better
A team is only as good as what it remembers. Every Hezo project gets durable knowledge: documents and memory that carry across runs, skills that hold your conventions so they aren't re-explained every session, full-text search over all of it, and version history you can roll back. The CEO chat keeps its own memory, so it stays in context between conversations.
That durable memory is also what lets the team improve itself. The Coach reviews every finished task, spots patterns - e.g the Engineer keeps skipping tests, the Writer keeps using passive voice - and writes a durable learned rule back onto the relevant agent's system prompt for all future runs. It is why we use an org chart rather than a graph: a hierarchy gives clear accountability and an escalation path, plus a place for the Coach to sit above the team and raise its standards. After a month, the generic workforce you started with has adapted to your project, your preferences, and your standards.
One binary, easy to run
All of it ships as a single self-contained binary - nothing to compile, no runtime to install. Run hezo and it starts the server, web app, embedded Postgres, vault, and egress proxy; open localhost:3100 and the workforce is there - task board, CEO chat, budgets, project dashboard. Docker is the only prerequisite. It runs on macOS, Linux, and Windows, needs about 4GB of RAM, and is happy on a modest VPS. Self-hosted software shouldn't need a DevOps background to install.
Where we are
As of July 2026, Hezo works; we use it daily. There is plenty left to build but the core is solid.
If any of this resonates, try it: star the repo at github.com/hezo-ai/hezo, file an issue, tell us what is broken. And if you are still wondering whether you can trust an agent with your credentials - you shouldn't have to. The right question is whether the system is built so trust is never required in the first place. That is what we have built.