Harness Selection Criteria for Polyglot Monorepos

Selecting a bring-your-own API key cloud coding agent runner for a polyglot monorepo is an infrastructure decision. Harness selection depends on its ability to control context overflow, coordinate cross-language changes, enforce constraints, interpret the build graph, preserve workflow state, and reach external tools safely.

Why a polyglot monorepo makes harness selection a distinct engineering decision

A polyglot monorepo contains dependencies that cross language runtimes. Build systems such as Bazel, Buck2, and Pants model those relationships explicitly. A change can work in its own module but break a module written in another language that depends on it. The harness must expose the relevant dependencies and support verification across them.

Harness Engineering by Barbaste et al. defines seven canonical harness subsystems and identifies the runtime around the model as the layer governing reliability, extensibility, and deployability. That runtime includes context controls, rules, skills, sub-agent management, workflow state, and tool bridging. Code as Agent Harness by Ning et al. frames code as an executable, inspectable, stateful substrate through which agents reason, act, and verify progress. The harness makes that substrate usable during a task.

These distinctions make repository structure the source of the selection criteria. Loading several language trees makes context harder to manage, and changing their shared contracts adds work to coordinate and verify the changes. An interruption adds the separate problem of recovering what has already been completed. Swapping models does not repair these runtime gaps. The six criteria address the engineering conditions under which delegation remains useful.

Context isolation: how a harness manages what the agent sees across language boundaries

Context isolation starts with a smaller scope than the whole repository. A multi-language repository contains overlapping dependency graphs, and loading all of them introduces unrelated material before the agent reaches the relevant boundary. More context is not automatically better context. The harness needs to scope retrieval to the affected sub-graph while retaining the contracts that connect it to other modules.

The Barbaste study finds that none of the eleven production harnesses studied retrieves code with vector embeddings. Instead, the systems use deterministic retrieval mechanisms including ripgrep, tree-sitter, glob, and auto-discovered Markdown context files. This distinction is useful in a monorepo because explicit paths, ownership, and build relationships provide stronger boundaries than semantic resemblance alone. Similar-looking code in another language module may have no role in the change. However, deterministic search still needs the build graph to establish which files belong in scope.

SKILL.md-style units can give instructions for a language or service without putting every convention in shared context. The same study reports that more of the systems use SKILL.md skills than use MCP. That finding concerns scoped knowledge. Evaluate whether the harness permits context boundaries per task or language boundary or always loads from one root.

Sub-agent partitioning: assigning roles across language boundaries without shared state collisions

When a task crosses language boundaries, it may need process isolation as well as context isolation. A coordinator can assign a Go service change and a TypeScript client change to role-specific sub-agents, each with its own context window. This limits interference between their working contexts. It does not, by itself, keep their edits compatible. Partitioning the work creates a corresponding obligation to reconcile its results.

The Barbaste study maps sub-agent coordination as a canonical harness subsystem and documents different dispatch architectures. Codex exposes its multi_agent_v2 feature through the MultiAgentVersion::V2 configuration flag. Claude Code uses definitions in .claude/agents/*.md and dispatches them through the Agent tool, formerly the Task tool. These mechanisms offer concrete places to inspect delegation behavior. Their existence alone does not establish how reliably outputs are reconciled.

The Ning survey identifies consistent shared state across agents as a leading open challenge. Consider a Go sub-agent renaming an interface while a TypeScript sub-agent retains a stale import path. Both can proceed coherently within their own contexts while producing an incoherent change together. A shared artifact provides the reconciliation point. Build graph snapshots, schemas, shared repository state, and test feedback can give the coordinator evidence against which to compare outputs.

Does the dispatch protocol transfer explicit state between roles, with a shared artifact for reconciliation, or does each sub-agent work in isolation?

Rule and script enforcement: making agent constraints non-negotiable across every language runtime

Partitioning determines who performs the work, but enforcement determines what any participant may do. Rules in a prompt are still soft constraints. Scripts can act as hard gates that catch tool calls before they run. The boundary must survive a language switch. A restriction on rm -rf cannot disappear when an agent moves from a Python service to a Rust crate or a Bash build script.

The Barbaste study documents behavioral policy moving from prompt prose into configuration and hook interceptors. Its examples include Starlark execution-policy rules, TOML hooks, and JSON/Zod agent schemas. Claude Code has PreToolUse hooks that run before a tool call. Exit code 2 blocks the tool call and sends the stderr reason back to the model so it can correct the call without human help. At PostToolUse, the same exit code can surface stderr but cannot block an action that has already run.

In a cross-language dependency graph, a blocked action can affect modules beyond the one in the agent’s current context. Rules need to be enforced at the execution boundary even when they are given as language-specific advice. Hard-gating scripts also keep structured records of the actions they block, which can be used to tune policy and review compliance. Evaluate whether the harness exposes a pre-execution intercept layer capable of blocking the action or relies on the model to obey instructions.

Build-system awareness: whether the harness understands the repo's dependency graph or has to be told

Execution controls establish permission, but they do not establish understanding. A harness can obey every rule and still verify the wrong targets if it treats the repository as a flat file tree. Build-system awareness supplies the missing structural model. It connects a changed target to downstream dependents and the tests needed to assess the full change.

In practice, this requires target enumeration, dependency traversal, scoped test invocation, and interpretation of build-tool semantics. Bazel target labels, Buck2 cell boundaries, and Pants goals are not interchangeable with a generic make test. The Ning survey treats execution traces, tests, and runtime feedback as structured representations against which agents plan and revise. Build output serves that purpose only when the harness can invoke and interpret it.

A shared proto change illustrates the failure mode. Tests in the proto package may pass even though its Go gRPC client and TypeScript HTTP client break. If the harness stops at the nearest test suite, those failures can appear only in CI, hours later, after human review. The agent has edited the right file but verified the wrong change surface.

Repository conventions help make this integration possible. Standardized build entrypoints, machine-readable ownership maps, and Architecture Decision Records kept in the same places give the harness an interface it can use the same way each time. Evaluate whether build queries have a defined integration point or depend on the agent discovering commands in README files.

Workflow durability: keeping multi-step cross-language tasks alive across context resets and failures

A five-hour cross-language migration that loses conversational state leaves an engineer with edits but no reliable account of progress. In a task spanning a Go service, a TypeScript client, and a shared proto, twelve discrete steps may be involved. An interruption at step seven can erase the distinction between completed edits and pending work. Recovery then becomes another engineering task. Re-reading changed files is not equivalent to recovering the workflow that produced them.

Durability needs an explicit state machine or DAG outside the context window that records which steps are done, which are pending, and the failure state. The Ning survey identifies execution traces, program states, repositories, tests, and logs as stateful representations used for reasoning and verification. Those records must still be there when the conversation ends. Otherwise, a new session has artifacts to inspect but no dependable place from which to resume. Persistent step records also make handoff between agents possible.

A durable harness can checkpoint after a verified build step, so failure at the TypeScript client step need not force repetition of the already-verified Go service step. Persistence without verification would merely preserve an uncertain status. Evaluate whether an interrupted run can resume at step N from recorded state, restarts at step one, or requires an engineer to reconstruct its history.

Tool bridging via MCP: whether the harness can reach the external systems that polyglot work requires

A harness also needs access beyond the repository. Package registries, schema stores, lint rulesets, and CI systems form part of the environment in which a cross-language change becomes valid. Without that access, the agent remains confined to editing files. Tool bridging connects internal reasoning to the systems needed to complete and verify the work.

Model Context Protocol, or MCP, provides a standardized JSON-RPC interface over stdio or SSE for external tool invocation. The harness registers MCP servers and routes calls through them, reducing the need for custom integration code for each tool. The Barbaste study reports MCP adoption across eight of the eleven harnesses examined. The Ning survey identifies tool search and selection as a core harness mechanism. Discovery is significant because the required tool can change with the language context.

For example, a Go module agent may need the Go module proxy, while a Python agent needs PyPI or an internal Artifactory mirror. A shared proto agent may need a schema registry. Registering tools by hand for every language module adds more configuration work as the number of modules grows. Flat access creates a different problem. An agent assigned local lint work should not gain unrestricted access to a production schema registry simply because both tools are registered.

The Barbaste study documents registries and trust tiers as emerging governance for skills. Evaluation must therefore establish whether MCP access is actually scoped by agent role. This also brings sandboxing into the assessment, because an isolated process still needs controlled access to external tools.

How the six criteria interact and what harness evaluation looks like in practice

The six criteria form a coupled system. Context isolation cannot maintain cross-language coherence without a way to reconcile partitioned work. Durable workflows without build-system awareness can checkpoint progress they have not verified. MCP access without role-based trust can give sub-agents with narrow tasks access to privileged tools. A strength in one subsystem does not cancel a gap in another.

The coupling can also improve the system. Sub-agent partitioning gives each role a bounded context, while build-aware checkpoints make durable recovery more precise. Script enforcement and tool-access controls each protect a different layer of the same execution boundary. These relationships favor evaluation against the actual repository. Success in a 50-package Python monorepo does not establish competence at a Go/TypeScript boundary.

The Barbaste study describes architectural convergence, but it does not benchmark or rank the systems. No studied harness was purpose-built for polyglot monorepo constraints, and the notes identify no uniformly strong option across all six criteria. Harness-agnosticism is therefore a practical response. A platform that can run multiple harnesses against the same task preserves the option to route work by subsystem strength. The study identifies Omnigent, open-sourced by Databricks in June 2026, as the first meta-harness its authors are aware of, orchestrating interchangeable harnesses behind one API.

For teams evaluating cloud runners, the starting posture is to test context isolation and workflow durability against the repository’s real structure. Can the harness respect build-graph boundaries, and can it resume after a failure? These are the hardest capabilities to retrofit. The other four can be addressed incrementally, but the tests must eventually exercise their interactions.