Agnes Harness: a pluggable runtime for forward deployed engineering agents

The problem: the same delivery, a different site every time

Forward deployed engineering, the FDE model, is how a software company delivers to a customer who has unusual systems, unusual approval processes and unusual constraints at every site. The argument in the project documentation is that taking AI into a real deployment is rarely about the model alone. It is about the customer's systems, the people who approve the work, and the details that differ at every site.

Agnes Harness is built for that shape of work. Its stated purpose is to connect models, tools, task state and business interfaces, and the instruction it gives is direct: put the differences into plugins, let the harness run and record the work, and carry what you validated into the next deployment.

That last clause is the whole product idea. An FDE team does the same integration repeatedly, in a new environment each time, and the knowledge of how to do it lives in the heads of the engineers. A harness that records the work as reusable methods, captured as Skills, turns a series of engagements into a compounding asset rather than a series of projects.

The interface is a CLI and a Web application, with business systems integrated through plugins, task methods captured in Skills, and those combined into an agent application of your own.

The status is stated plainly on the badge: developer preview, pre-alpha. The licence is Apache-2.0, the last push was on 2026-10-20, and there are no GitHub releases, so this is a project to watch and to prototype with rather than to depend on.

Four roles, and what each one is actually responsible for

The architecture is described with a deliberate metaphor, and the table that accompanies it is worth reading because it pairs each role with its current scope rather than with its aspiration.

The LLM is the brain: understanding requests, reasoning about the task and proposing actions, with the current scope being model integration through AI providers. Jev is the cerebellum: structured decisions such as routing and scoring to help coordinate execution, and the scope column says integration in progress, with the main currently using the built-in Core loop. The Harness is the memory: retaining session history, task state, execution records and reusable methods in Skills, and the scope is the existing task context and recovery mechanisms, with the Harness also running and governing execution. MHS is the body: connecting device capabilities so tasks can read physical state and request actions, with the scope covering the MHS and MOS 1.0 specifications, device libraries, the mhs-check conformance suite, and AgnesHub as an optional plugin with device tools for the brain.

What this table gives a reader is a status. The brain and the memory are the parts that exist, the cerebellum is being built, and the body is a protocol with an ecosystem around it. A team reading it can tell which parts of the system they are actually relying on.

The framing also explains why the project separates FDE from devices in its documentation: FDE is a delivery approach, MHS brings devices into the same work, both build on the same foundation, and an FDE deployment can include devices.

The shared modules: server, agent loop, execution constraints, plugins

Below the four roles there is a second table, and it describes the modules that both the FDE side and the device side reuse.

The App Server supports FDE today with shared sessions, task submission, event delivery and approval routing for CLI, Web and SDK clients, and the MHS integration reuses the task entry points, the human confirmation and the status presentation. The Agent Loop covers model and tool execution, task state, event records, interruption handling and recovery, and the device side reuses high-level device task orchestration and result records.

The sandbox and execution constraints module is the one to read carefully. For FDE it provides tool authorization and applicable command, file, network and process constraints, and for MHS it provides the software execution boundaries, with the note that device controllers retain motion control, interlocks and emergency stops. In other words, the software side is sandboxed, and the part of the system that can move something physical is deliberately outside the sandbox.

Plugins are the extension surface: backend tools and services, Web panels, Skills, hooks and MCP connections, organized with Cordis and package governance. The MHS integration reuses that surface, since AgnesHub runs as an optional plugin providing device tools for the brain and a Devices panel in the workbench.

The result is one runtime that serves both enterprise delivery and device work, with a plugin system that is common to both. Business connectors and workbenches are built through these extension paths for each deployment, which is the mechanism that makes the differences at each site cheap to express.

Skills, the execution record and the trust model

The demo description in the documentation is a useful sketch of the intended loop: the agent reads the refund rules and order data, asks for approval before running a command, verifies the result, returns a checkable table, and records every step in the Trace view. The summary line is that you read the code, ask before running a command, verify, answer, and record every step.

Two mechanisms sit behind that. The first is Skills, the reusable methods that carry a validated approach from one deployment to the next. The second is the trace, the record of what actually happened, which is what makes the checkable table checkable and what turns one engagement into a method someone else can run.

The trust model is stated with unusual clarity, in a list of what AGH is not. It is not a hosted service, so you build it from source and run it in your own environment. It is not a sandbox for arbitrary plugin code: ordinary backend plugins run as trusted in-process code, and the approvals and the command sandbox apply to the supported execution paths. It is not a certified device driver, because MHS is AGH's own device protocol and independent of MCP, and passing its conformance suite does not certify a device as safe. And it is not finished, since APIs, configuration and plugin interfaces are evolving and may change.

That first non-claim about the sandbox is the one an engineering lead should hold on to. If your threat model involves third party or customer written plugins, this project is explicit that the sandbox does not cover them.

MHS, the device protocol and what the conformance suite covers

The device side, MHS, is where the project is most unusual, and it is worth separating what it claims from what it does not.

MHS is AGH's own device protocol, and the scope column lists the MHS and MOS 1.0 specifications, device libraries, the mhs-check conformance suite, and AgnesHub as an optional plugin with device tools for the brain. The protocol is described as independent of MCP, which is a deliberate design decision rather than an implementation detail: MCP is the bridge to models and tools, MHS is the bridge to physical capability, and conflating them would tie device control to a model-facing interface.

The conformance suite has a clearly bounded meaning. Passing it does not certify a device as safe, and device controllers keep real-time control and physical safety. That is the right division of responsibility, because a test suite can check that a controller speaks the protocol correctly and cannot certify that a motor stops when it should.

The documentation for MHS and devices is a separate guide in the docs directory, alongside the quickstart, the demo walkthrough, the plugin development guide, the security and trust guide and the document that explains the FDE scenarios. The examples directory carries three things: a mars-world example, a packages example, and a third-party-plugin example, which is the quickest way to see how an out-of-tree plugin is expected to be shaped.

Building and running from source: pnpm workspaces, two vitest projects, six benchmarks

The packaging tells you what kind of project this is. It is a private pnpm workspace with the package manager pinned to pnpm 10.34.5 and Node 24.10 or later, and the scripts are short and specific:

    "test": "vitest run --project fast --maxWorkers=1",
    "test:heavy": "vitest run --project heavy --maxWorkers=1",
    "typecheck": "tsc -b",
    "lint": "biome check .",

Two things are worth noticing. The test suite is split into a fast project and a heavy project, which is the usual way to keep a pre-alpha agent runtime usable in a development loop without running the slow suites on every save. And maxWorkers of 1 on every project means the tests are serialised, which is what you do when the code under test holds global state, which a harness with a task ledger and an execution record does.

The dev script is a single command that serves the web interface through the CLI package, and there is a gen:check script that runs a generation check across the workspace packages, which is the mechanism that keeps generated code in step with the sources.

The benchmark scripts are the most revealing part, because they name what the project thinks is worth measuring: attachment open, compute unit artifact garbage collection, and four ledger operations, integrity, scan, write and package load. A ledger with integrity checking is the load bearing part of a harness that records what an agent did, and benchmarking its write path and its scan path says the authors expect the record to be the thing that grows.

The repository is built with Biome for linting, TypeScript 7.0.2 for types, Vitest 5.0.0 for tests with a happy-dom environment, and it carries a start-local-windows.ps1 script, an AGENTS.md and a CLAUDE.md, a NOTICE file and a SECURITY.md.

Who should try it, and what to check before you do

The documentation has a section on who it is for, and the honest reading of the project is narrower than the vision.

This is for a forward deployed engineering team that has the same integration to deliver repeatedly, that wants each delivery to leave behind a reusable method, and that is willing to run a pre-alpha runtime inside customer environments. It is also for anyone who wants to study the shape of a plugin-first agent runtime: the four role model, the Cordis based plugin system with package governance, the Skills mechanism and the MHS device protocol are all documented, and the third-party-plugin example shows how a plugin is expected to fit.

It is not for a team shipping to production under a service level agreement, because the project says its APIs, configuration and plugin interfaces are evolving and may change, and there are no GitHub releases to pin. It is not for a team whose security model requires untrusted plugin code to be isolated, because the documentation is explicit that ordinary backend plugins run as trusted in-process code. And it is not a substitute for an MCP client or an agent framework, because AGH is a runtime and a plugin host rather than a model integration layer.

Three checks come before anything else. Read the security and trust guide, so that the trusted-plugin boundary is understood rather than assumed. Check the recorded local checks, which the status badge lists as macOS only, so that you know what has actually been exercised. And look at the examples directory, in particular the third-party-plugin example, because the shape of your own integrations will follow it.

The licence is Apache-2.0 with a NOTICE file, which makes it straightforward to try inside a company, and the project asks for followings and use cases. For a team that is willing to be an early user, the cost of entry is a pnpm install and a look at the quickstart, and the upside is a harness that treats the knowledge of a deployment as something to be captured rather than retyped.

Editorial conclusion

Adopt Agnes Harness if you are a forward deployed engineering team that repeatedly delivers the same integration to different customers and wants each validated method to become a reusable Skill. Do not adopt it for a production deployment now, because the project labels itself a developer preview, pre-alpha, and states that APIs, configuration and plugin interfaces are evolving. Before you build on it, read the security guide, since ordinary backend plugins run as trusted in-process code, and check the recorded local checks, which cover macOS only.

Frequently asked questions

Official sources

1. AgnesAI-Labs/agnes-harness on GitHub
2. Issues
3. License: Apache-2.0
4. README