A harness that tells coding agents how your code works

• Instructions for each repository, brief enough for an agent to follow
• Commands the agent can use to build the project and run its tests in a newly cloned repository
• A clear scope for context and tools: which services, files and endpoints the agent may use
• Rules for which shell commands, file edits and network access are allowed and which need approval
• Tests, hooks and review steps that catch problems in the agent's work before anyone on your team looks at it

If no one is watching an agent, its limits are what keep it in check. Each run gets permissions that match its task, its own isolated workspace and credentials scoped to that run. Nothing merges until it has passed review. The exact setup differs between tools and infrastructures, so we settle it with your security team.

Harness files are versioned just like code. Every file has someone responsible for it and an agreed way to change it. Without that, each engineer adds settings of their own and the repositories drift apart. We work out with you which parts every repository shares and which stay local, and how you will spot drift.

Each change touches one piece of the harness, and we measure it on tasks typical of your work. When two setups need comparing, we use evaluations on your own repositories. The configuration files and written runbooks go to your engineers, so they can go on adjusting the harness without us.

In a repository, context engineering means settling what the agent is given at the start and what else it may fetch along the way. That covers the commands for builds and tests, the instruction files, the documents it can open and the tools it is permitted to call. More is not better. Instructions that load with every request take space away from the task itself. We keep that part brief. Everything else moves into files that load only when a task calls for them, for example Skills or rules attached to a path.

Context changes go through the same process as every other change to the harness. We make each one on its own and test it on a fixed set of sample tasks. Then we record whether accepted changes and review effort go up or down.

A number of published workflows change the way an agent moves through a task. One is the Ralph technique, which Geoffrey Huntley described in July 2025. The agent gets the same prompt again and again in a loop and starts each round with a fresh context. Progress is stored in files between rounds, for example in a plan and in specs. For Claude Code, Anthropic offers the ralph-wiggum plugin. It keeps the loop inside a single session and ends it on a completion phrase, or after an iteration limit if you set one. In Huntley's view the technique suits new projects, and he advises against using it on an existing codebase.

Superpowers, by Jesse Vincent and Prime Radiant, opens with a brainstorm and a written plan. Subagents then do the work test-first, and code review is part of the process. Every's compound engineering plugin works through brainstorm, plan, work, simplify and review. Afterwards it writes down what was learned, for use in later tasks. Lauren Tan's pstack, a plugin for Cursor, sends each task to a matching playbook and has several models review the result.

These workflows give the agent instructions. None of them enforces anything. A loop that keeps going for hours calls for the same safeguards as any run without a person watching. That means capping iterations and budget, isolating the workspace, protecting the tests from changes by the agent and reviewing before any merge. Before a team takes up a workflow, we test it on your repository and check it against your controls. We also run it side by side with your present setup on identical tasks.

Our guide to pstack · Spec-driven development in practice · How we compare workflows

In OpenCode, the provider and the model endpoint are set in the configuration. That is the first thing we settle, together with the people who own your data and your contracts. The setting determines the destination of your prompts and code context, the terms that cover them and who is billed. Routing traffic through a gateway gives you attribution and policy in a single place. The gateway, though, is another system with access to that traffic. Whether session sharing is enabled is also something we decide together.

Apart from the format, the harness work does not differ from other tools: it is simply written in OpenCode's configuration. We document the path your data takes, from developer machines via any gateway to the provider. You also receive a runbook that explains how to switch provider or model at a later date. Retention periods come from your contracts and from the terms each provider currently publishes. We record them for every provider you use.

Kilo can be used in the editor, in a CLI and in the cloud. First we take stock of the Kilo surfaces and versions in use on your teams, and of the providers your organisation permits. We test that combination on your code before other teams start using any of it. The desktop app is a beta release, so we add it only for teams that already rely on it. The client is open source and runs locally, yet that tells you nothing about which servers receive prompts and code context. The provider you configure decides that, along with any gateway the traffic passes through, Kilo's own if you use it.

Each custom agent, repository rule, skill and command lives in version control and has an owner. The current extension is built on the CLI and reads custom agents from Markdown files. Older installations still read custom modes, the legacy format. For every installed version we confirm which format it reads, and we repeat the acceptance tasks once a migration is done. All of these files tell the agent what to do. What the agent is actually able to do is bounded by its permissions and its MCP access, which we configure agent by agent. How far you can restrict models depends on your plan. The organisation control in Kilo's documentation is a blocklist on the Enterprise plan. Any new provider or model stays usable until someone blocks it. For that reason, the approved selection needs a person who owns it and checks each addition. We also confirm which mechanism enforces the selection on your plan.

• Your teams' surfaces, versions and providers, tested against your own code
• Shared agents, commands, rules and skills in version control, with a named person owning each, stored in whichever format your installed versions understand
• MCP servers and permissions limited to what each agent is for
• Models and providers measured by accepted changes, review effort and retries, plus someone in charge of the approved list

Adoption with a choice of provider · How we compare workflows · What multi-agent workflows cost · Kilo's documentation on customising agents

When the agent runs in the vendor's cloud, the harness must be set up in that environment too. Whatever makes the project work on a developer's machine has to be rebuilt there. That includes installing dependencies, starting services, loading test data and providing secrets limited to the task. We then open a new session and check that the project builds and its tests run. We also check that its git, MCP and network access fits the task. The product and the plan determine what can be enforced there. How to choose tasks, who owns review and how to run the pilot are described in the Devin section of our adoption page.

Handing work to Devin

• The share of the agent's first attempts that pass your checks
• How many review rounds agent pull requests need, and how much rework
• Each harness change measured on an unchanged set of tasks before it is kept