The agent harness: the guarantees I give a client

Agents write code; they do not decide what ships. Every action goes through a harness that limits what they see, what they touch and what they can merge. These are the rules as they are configured, not as a slogan.

What the agents can do

Read and modify the code of a single project, in an isolated working copy (a git worktree) created for the task and removed afterwards.

Run the project's own checks: build, type checking, lint, tests, automated code review and security review.

Open a pull request to the integration branch dev, never anywhere else.

What they cannot do

Touch the production branch or deploy. Promotion to production is a manual pull request, opened and reviewed by a human.

Read or write secrets. Keys, certificates and .env files are excluded from git and injected into CI as encrypted secrets by a script that never prints them.

Act outside the repository. Any risky or outward-facing action (sending, deleting, publishing, rotating a secret) stops and waits for an explicit human approval.

Bypass the project's rules. Each repository carries a versioned policy file (requirements to read first, frozen design, conventions, delivery rules) that the agent must follow and that a human reviews like code.

What the client keeps

Traceability. Every change is a commit on a branch, a pull request and a review in the client's own git history. Nothing happens outside that history.

Reversibility. A pull request can be rejected, a commit reverted, a session stopped with one command.

Kill switch. A session stops immediately on command; a watchdog restarts or cuts a session that drifts; review loops have a maximum number of iterations.

Ownership. The code stays in the client's repositories (GitHub or Azure DevOps) and on the agreed infrastructure. No third-party orchestration platform sits in between: first-party tooling and reviewed shell scripts only. On request, the factory runs on the client's own server or Azure tenant.

Human gates. Specification, design, promotion to production. No feature code before the specification is approved.

What the model sees

Only the context the task needs: the project's files, never secrets or production data.

Model access is configured and documented so that the client's code is not used to train models.

Personal data held by the products (patients, employees) never passes through the development agents. When a product itself embeds a model (Aria, Pilume), the payload is de-identified and the output is validated by a schema and by a human.

Why a harness rather than trust

An effective agent is a fast one, and speed without limits is a risk. The harness sets the limits once, in reviewed and versioned files, so the agents' cadence never depends on their good will.