The agent harness for work that cannot leave the building.

Why Abhed

Five things "under your control" actually means.

Each one is a property this repository tests, not a line of copy.

A real session

Ninety seconds, captured — not a mock-up.

A 26B model running locally, asked to add a function, write a table-driven test for it, and run the suite. Step through it; the explanation on the right follows the terminal.

Install

One static binary. No runtime to install.

# Go 1.26 or newer. Abhed is a single binary with no runtime dependencies.
git clone https://github.com/yuvrajsingh/abhed
cd abhed
go build -o ~/.local/bin/abhed ./cmd/abhed

abhed -version

# Build a signed bundle on a connected machine:
./scripts/build-bundle.sh          # -> abhed-bundle.tar.gz + .sha256 + .sig

# Carry it in. On the target, with no internet route:
./scripts/verify-bundle.sh abhed-bundle.tar.gz
tar xzf abhed-bundle.tar.gz && ./install.sh

# Abhed does not ship a model. Point it at one you host:
ollama serve
ollama pull qwen3-coder:30b

# Then, in the directory you want the agent to work in:
abhed init      # writes .abhed/config.json, detects a local endpoint
abhed doctor    # check the endpoint before you rely on it

Ready.

Full instructions, configuration and every tool contract are in the documentation.

The harness

Five ways to run it. One set of rules.

The same agent loop, the same policy engine, the same audit trail, whether you drive it from a terminal, a pipeline, another language, or your own Go service. A guarantee that held in the CLI and not in the server would not be a guarantee.

Embed it

Policy, audit and deny rules hold when embedded.

Your application supplies the approver and consumes the event stream — because a host usually has better ideas than a terminal prompt about how to ask a user for permission. Policy still decides what runs, every action is still recorded, and an extension still cannot permit what a deny rule forbids. No approver means refuse, never assume yes.

One guarantee that does not come with it: the SDK builds no sandbox. An embedded agent runs commands with the privileges of the process that embedded it, so the host is responsible for isolation — a container, a jail, a separate user — exactly as it would be for any other library that shells out.

a, err := abhed.New(ctx, abhed.Options{
    Workspace: "/srv/work",
    Provider:  &abhed.Provider{Type: "anthropic", Model: "claude-opus-4-5"},
    Mode:      "auto",
    Deny:      []string{"bash(rm -rf *)"},

    // Your app decides. No approver means refuse — never assume yes.
    Approve: func(ctx context.Context, tool string,
        args json.RawMessage, d abhed.Decision) (bool, error) {
        return askYourUser(tool, args, d.Reason)
    },

    // Every action, as it happens.
    OnEvent: func(ev abhed.Event) { log.Println(ev.Type) },
})
defer a.Close()

answer, err := a.Run(ctx, "fix the failing tests")

Steer works from another goroutine, mid-run. For anything not written in Go, abhed rpc is the same agent over JSONL.

Primitives

Extend it without forking it.

Governance

What the agent did, provable afterwards.

Most of what an agent harness offers can be added later as an extension. Two things cannot: a log you can replay, and an isolation boundary the database enforces. Both have to be in the core, which is where these are.

They are not on by default. Abhed ships with an in-memory store, which keeps a single-machine trial simple and gives you none of what follows. The triggers and the row-level security are properties of the Postgres store — one config line — and a deployment that needs to prove anything to an auditor has to be running it.

Context engineering

Compaction is a capacity decision, not a quality knob.

Reference application

Abhed Chat is one thing built on it.

A multi-user console — documents in and out, diagrams, live Kubernetes debugging, SSH to declared hosts, every write behind a human approval gate. It is a demonstration of the harness, not the product, and it is built on the same SDK anyone else would use.

It is running now at abhed.zybuu.com — the sign-in page is public, and access is by invitation while it runs on our own infrastructure. Request one and we will get back to you.

Evidence

Numbers that survive a technical diligence call.

Benchmark

Same model, same prompt, three harnesses.

Twenty-four Exercism Python exercises, one local 26B model (gemma4:26b through Ollama), the identical prompt for every system, scored against the original test file after each run. What varies is the harness, so the harness is what the numbers measure.

Abhed was the slowest of the three and used the most tokens: it verifies and iterates where the others stop. That is the trade, stated plainly. The suite is small and single-file, and says nothing about multi-file work. Method, per-task table, and the mid-run correction to the aider invocation are all in the benchmark results; the raw run records are in the repository, and the figures above are recomputed from them by the site tests, never typed in.

Limitations

What Abhed does not do.

Every row below is a constraint we would rather you knew before a trial than after one. Where there is a path forward it is stated; where the honest answer is "not yet", it says that.

Pricing

Open core. Pay for the governed deployment.

The harness, the CLI, the SDK and the audit log are free and will stay free. What an organisation pays for is running it for many people under policy, and someone to call. Launch pricing, per deployment and per seat — never per token, because you run your own models.

Prices are launch pricing as of September 2026 and may change before general availability; a signed agreement fixes yours. What Abhed does not yet have — certifications, an SLA, high availability — is stated in the limitations above, not hidden in a contract.