A single, centrally hardened agent harness can make LLM-based automation auditable and governable across the enterprise by collapsing bespoke integrations into version-controlled instruction files and enforcing identity-scoped tooling and pre-execution risk checks.

Main Finding

A single, centrally governed "harness"—a repeatable model-in-a-loop runtime packaged once and deployed unmodified across contexts—can serve as enterprise infrastructure for model-driven knowledge work. When combined with four operational primitives (credential-scoped tooling, externalized authorization, deployment-as-registration, and a pre-judging judge-runner for risky calls), this architecture closes the governance gap that has prevented harnesses from scaling across large enterprises, collapsing review and audit effort while enabling many teams to build safely and quickly.

Key Points

• Problem framed: model generation made custom code cheap to create, but review/understanding/maintenance costs remain high; enterprises therefore end up duplicating orchestrations, tool integrations, and governance.
• Harness paradigm: treat the coding-agent harness as centrally engineered infrastructure (not a per-team coding tool). The harness is a single looped runtime with memory/filesystem that iterates on reasoning and composes actions at runtime.
• Core architectural decisions:
  • Use a frontier model as the sole runtime orchestrator (no fixed design-time DAG/graph); orchestration emerges at runtime from repeated model calls.
  • Provide a single tool gateway that exposes enterprise backends through a small set of generic, credential-scoped request tools rather than one hand-written method per operation.
  • Keep authorization and policy decision logic outside the harness; control access by identity-scoped credentials and a gateway policy, not by policing per-operation calls inside the harness.
  • Make governance intrinsic to deployment: CI/CD auto-registers every solution in a solution registry; auditing reduces to reviewing version-controlled instruction files.
  • Add a judge-runner: the model flags risky calls and a freshly spawned, identical harness instance evaluates the risk before the backend is ever invoked; escalate to humans only when the judge cannot clear the call.
• Operational components (four supporting services):
  • Tool registry/gateway: central capability layer mapping credentials to backend access.
  • Solution registry: records what was deployed, by whom, and links to instruction/config files.
  • Skill library: procedural knowledge baked into images at build time or fetched live when named "live".
  • Run-trigger endpoint: lets chat surfaces or other frontends start the same harness container on demand.
• Developer flow: fork a reference harness repo (reference implementation: microcc), edit two text files (instructions + configuration), push; CI/CD builds container, registers, and deploys. Same harness artifact runs as cron, interactive terminal, or business-facing chat UI under one identity/governance model.
• Motivating evidence and citations:
  • Builds on prior findings that harness choice explains more benchmark variance than model choice, and that terminal/filesystem harnesses perform well for enterprise tasks (several cited arXiv works).
  • Architecture and mechanisms were designed and evaluated in engagements across multiple European enterprises (automotive, manufacturing, FMCG, healthcare) and implemented against an Azure RBAC environment.
• Practical tradeoffs:
  • Low-code conversational platforms retain a role as thin ingress/identity surfaces, but are not robust orchestrators for complex multi-system tasks.
  • Centralizing the harness reduces duplication and audit burden but requires careful integration with identity/access systems and CI/CD pipelines.
• Implementation artifact: microcc (https://pypi.org/project/micro-cc/) used as the paper’s reference harness.

Data & Methods

• Nature of evidence: systems-architecture and practitioner paper informed by multiple enterprise engagements, prototyping, and implementation rather than randomized controlled experiments.
• Implementation details:
  • Reference harness: microcc, used as the unmodified runtime artifact in examples and pilots.
  • Cloud context: mechanisms prototyped against Azure (directory groups, management groups, role-based access control); authors claim portability to other clouds and on-premises.
  • Mechanisms demonstrated in code snippets and system descriptions (tool calling conventions, gateway discovery/call path, solution configuration and registration, run-trigger endpoint).
• Relationship to prior literature: synthesizes and operationalizes results from several arXiv studies:
  • Terminal agents sufficing for enterprise automation;
  • Harness choice dominating model choice in benchmark variance;
  • Governance being the primary barrier to enterprise harness adoption;
  • Security-oriented work (SHarD) that converges on distributing a hardened harness artifact.
• Limitations of the methods:
  • No large-scale quantitative outcome study or cost-benefit analysis reported in the paper.
  • Enterprise engagements are anonymized; no public dataset of deployments or controlled performance comparisons across alternative topologies presented.
  • The judge-and-gateway mechanisms mitigate but do not eliminate model failure modes (hallucination, dropped constraints, lazy heuristics) — these remain operational risks that need process and iterative instruction tuning.

Implications for AI Economics

• Cost structure and productivity:
  • Lowers marginal cost of building bespoke automations by removing repeated integration and orchestration work across teams—reduces duplication of engineering effort and lowers time-to-market.
  • Shifts post-deployment cost profile: fewer unique codebases to audit/maintain, turning many code reviews into reading instruction/configuration files; this likely reduces governance and compliance costs at scale.
  • Because harness choice explains much performance variance, investing in harness engineering (reliable loop, tooling gateway, credential plumbing, CI/CD + registries) offers higher ROI than incremental model procurement improvements.
• Governance, transaction costs, and latent innovation:
  • Embedding governance into CI/CD and identity-scoped tooling reduces friction for teams to build, increasing on-radar innovation and reducing shadow IT/undocumented automations.
  • Credential-scoped tooling aligns incentives: access decisions are made once per credential, reducing transactional friction for operations while preserving enforceable audit trails.
• Labor and organizational roles:
  • New specialization: harness engineers and governance-infrastructure teams become critical; fewer custom integration engineers working in isolation.
  • Business specialists can act as effective product owners for automations (editing instructions/configs rather than writing code), potentially increasing leverage per specialist.
  • Risk of concentration of control: central harness + tool gateway concentrates power and monitoring in platform teams; governance and incentives must be designed to avoid bottlenecks or political capture.
• Vendor and market effects:
  • Reduces reliance on low-code conversational platforms for full orchestration; these platforms may be repositioned as ingress/identity surfaces or compete to offer turnkey governance hooks.
  • Demand shifts toward hardened harness distributions, tool-gateway managed integrations, and registries — a market for enterprise harness tooling and registries may expand.
• Macro-level effects:
  • If adopted widely, the approach could materially change the economics of enterprise knowledge work by reducing unit costs for complex cross-system tasks and increasing the rate of safe, auditable automation deployment.
  • The largest remaining economic frictions will be residual model failure modes (requiring human-in-the-loop design and testing), the upfront cost of integrating identity and secure tool gateways, and organizational change management for centralized platform teams.

Limitations and open questions for empirical research - Quantify benefits: rigorous measurement of time/cost savings, error rates, and governance burden compared to existing per-team orchestrations is needed. - Behavioral effects: how do teams adapt instruction-writing vs code-writing skills, and what governance incentives ensure responsible use? - Robustness: measure how judge-runner and credential-scoped tooling perform across a wide set of risky-call scenarios and across different cloud/identity environments.

If you want, I can (a) produce a short checklist for evaluating whether your organization should adopt this harness architecture, or (b) sketch an experiment / KPI set to measure the economic impact of adopting the harness in a single business unit. Which would you prefer?