A Local-First Coding Agent Needs a Measurable Boundary

A coding agent is easier to evaluate when its limits are visible in the interface.

I built Metron around that constraint. It is a small terminal coding agent that runs against a local Ollama model. Version 0.1.0 includes macOS and Linux archives, checksums, and SPDX SBOMs.

That release is a public artefact, not evidence of production readiness, adoption, or security certification. It gives another engineer a specific implementation to inspect.

The boundary is the product

A model can produce a plausible answer after seeing more context than a reviewer intended. A demo may still look capable while concealing what the model read and which effects it could trigger.

Metron exposes code through narrow, budgeted tools.

The default limits are visible in the README:

  • 121 lines per file slice
  • 500 characters per line
  • 60 listed files
  • 10 search matches per request
  • 10 model round-trips per turn
  • no retained tool slices after a turn completes

These are implementation limits. They are available to inspect, change, and test. I do not present them as universal defaults.

A tool surface makes the policy concrete

The tool surface carries the policy:

  1. list a bounded set of files;
  2. search for a bounded set of matches;
  3. inspect a bounded slice;
  4. propose a patch;
  5. wait for explicit approval before applying it.

The project directory is another boundary. Paths are resolved against the enclosing Git work tree, and a path that escapes that tree is refused. Symlinks are followed before the check, so a link outside the project does not quietly become an escape route.

Those checks do not make the agent suitable for every environment. They make the controls visible in the code and documentation instead of leaving them in a system prompt.

Approval is separate from generation

Metron shows the proposed diff and waits for a y before applying it. The patch is dry-run through git apply --check first. A refusal is returned to the model as text so it can explain the change instead of retrying silently.

One-shot mode applies the same boundary to a command such as:

metron -p "which files define Greet?"

can answer a question without an interactive session. If the request would apply a patch, one-shot mode fails closed unless --yes is supplied.

A generated patch and an applied patch are different events. Keeping them separate lets a reviewer tell whether the tool answered, proposed, or changed something.

What the release lets another engineer inspect

The v0.1.0 release includes archives for macOS and Linux on amd64 and arm64, checksums, and SPDX SBOMs. The README explains the required local tools and the --doctor command. The public evaluation brief sets out a zero-credential first run and the limits of what that exercise can establish.

The first useful evaluation is small:

  1. download the archive for the local platform;
  2. run metron --version;
  3. run metron --doctor in a test repository;
  4. ask a read-only question;
  5. inspect the proposed patch without approving it.

I added a public installation-feedback template for that evaluation. It asks for reproducible environment details while excluding credentials, private paths, prompts, and source code.

The limits are part of the result

Metron depends on a local Ollama server, a tool-capable model, ripgrep, Universal Ctags, and Git. When a binary is missing, the related tool is unavailable. The agent does not guess around that dependency.

The project has no customer study, production deployment, adoption measure, or security certification. The release does not establish any of those things. It establishes a public implementation with a documented boundary and a repeatable way to inspect it.

I want agentic software to make its effect, scope, revision, evidence, and approval state visible enough for another engineer to challenge a design for specific reasons.

The most useful feedback on this release is where the boundary is unclear or the first-run path breaks.

A separate review exercise

If you are evaluating agent-assisted changes in a team rather than building a local tool, the free AI-assisted code review kit provides a bounded exercise with code, a worksheet, and a worked answer. It is complete without a subscription.

Teams that want facilitated discussion can review the workshop interest details. That page describes an interest enquiry only; it does not reserve a date or accept payment.