Source-linked AI summary
Applying Anthropic Primitives at Large Enterprises: Harness Paradigm for Knowledge Work
George Juraj Salapa
TL;DR
The paper addresses the difficulty of governing increasingly cheap, bespoke enterprise automation built from inconsistent codebases and limited orchestration patterns. It proposes an unmodified harness backbone with credential-scoped tooling and deployment-native controls, and argues that this architecture supports governed operation across enterprise surfaces. The paper presents the architecture and field-informed examples but runs no benchmark of its own.
Problem
Enterprises lack a centrally governed alternative that combines cheap domain-specific customization with reusable, reviewable architecture across varied automation contexts.
Method
The paper proposes one unmodified harness backbone with credential-scoped generic request tools, external authorization, registries, CI/CD deployment, and run-triggered execution.
Results
The architecture is described as operating across cron, chat, and terminal deployments, with examples spanning policy application, CRM triage, and document checking.
Takeaways & Limitations
The paper’s supported conclusion is that harnesses can serve as a universally capable, governable architecture for enterprise AI automation at scale.
Takeaways & Limitations
No benchmark accompanies the paper, so its claims about harness sufficiency and comparative performance rely on cited work and field experience rather than a study-specific comparison.
Abstract
from arXiv · showhide
Frontier models have collapsed the cost of writing custom code: a niche problem a specialist sees in their own domain now costs an afternoon. The cost of reviewing and maintaining that code hasn't collapsed. Each solution drifts from the next; understanding one means reading its codebase from scratch. Large enterprises build something centrally governed instead: at worst an off-the-shelf product, at best a graph-orchestration framework wired bespoke per use case, or a low-code platform used as the orchestrator. These are custom every time and limited in scope. Enterprises don't weigh a third option that escapes both constraints: the harness paradigm. Recent work treats the coding-agent harness as enterprise infrastructure rather than a coding tool, converging on three findings: harnesses suffice at the task level and outperform more elaborate architectures on enterprise work (arXiv:2604.00073, arXiv:2604.13107); harness choice accounts for most of the variance in agent benchmark results, more than model choice does (arXiv:2605.23950); and the gap between that finding and enterprise adoption is governance (arXiv:2605.10223, arXiv:2605.18747). We propose an architecture that closes that gap. One harness runs unmodified as the backbone; the code stays identical across every deployment, so reviewing what gets built collapses to reading its instructions file. Section 4 gives four mechanisms: credential-scoped tooling, where each backend gets one generic request tool and a scoped credential instead of a hand-built method; authorization logic outside the harness, so one artifact runs as a cron backbone, a chat-surface engine, and a terminal tool; registration is a side effect of pushing code, collapsing an audit a review of a text file. Built on microcc (<https://pypi.org/project/micro-cc/>), our reference harness.
1. Introduction
Enterprises commonly build siloed, operation-specific model systems whose tools and orchestration vary by team. The paper proposes one unmodified harness backbone with credential-scoped tooling and deployment-native governance.
- Enterprise solutions typically use separate codebases, tool layers, and governance models for different systems, problems, and user surfaces.
- Low-code conversational platforms offer accessible deployment and governance but are weak, opaque orchestrators for workflows spanning many actions.
- Recent work finds that harnesses can suffice for enterprise tasks, while harness choice explains more benchmark variance than model choice.
- The proposed alternative uses one harness unmodified across deployments, supported by thin registries, CI/CD, skills, and run-trigger services.
- Credential-scoped tooling gives each backend one generic request tool and an identity-bound credential, moving access control to the credential.
- Deployment registration as a shipping side effect reduces auditing an enterprise’s N solutions to reviewing N version-controlled instruction files.
2. Background / Related Work
Related work supports harnesses as enterprise infrastructure and identifies governability as the adoption gap. This paper addresses that gap with one harness artifact spanning multiple deployment contexts under shared controls.
- Recent work reframes coding-agent harnesses as infrastructure rather than merely coding tools.
- Terminal-agent research argues that simple terminal and filesystem interfaces can match or outperform more complex enterprise-agent architectures.
- ERP experiments report reliable success on simple tasks without ERP-specific tools, while greater complexity exposes domain-logic and execution-bridging failures.
- The harness literature identifies shared state and human oversight for safety-critical actions as open challenges addressed by this paper’s state and approval mechanisms.
- Comparative design work describes distinct harness configurations for different deployment contexts, whereas this paper uses one harness core across those contexts.
- The paper narrows risk governance to identity-scoped entitlement, registration, and blocking approval primitives rather than a more elaborate risk-tiered framework.
- The paper reports no comparative benchmark and identifies microcc as its reference harness implementation.
- The claimed deployment-topology gap is a single unmodified harness running as scheduler backbone, chat engine, and terminal tool under one governance model.
3. The Evolution from Chat to Harness
Enterprise model integration progresses from chat and narrow autocomplete toward iterative harnesses with memory, filesystem access, and self-directed action. This enables work that spans systems and supports non-software knowledge tasks.
- Chat: Chat systems preserve conversational context but lack independent hands and remain bounded by fixed, builder-anticipated tools.
- DAG / chain orchestration: Graph and chain orchestration add persistence and multi-step structure but freeze the workflow path at design time.
- The autocomplete layer: Autocomplete embeds a narrow one-shot model suggestion inside an existing product for human acceptance, editing, or rejection.
- Harness: A harness repeatedly calls the model, feeds results back, and provides filesystem access for iterative reasoning and artifact creation.
- Enterprise work often requires spanning systems, combining data, and reasoning iteratively, beyond the reach of the first three patterns.
- Specialists can guide harnesses through domain-specific problems without writing code, although terminal interaction remains a barrier for some users.
- The harness paradigm extends beyond coding to document review, case triage, report generation, and other reasoning-and-language tasks.
4. System Architecture
The architecture packages one harness as a reusable backbone, with shared services and deployment surfaces built around it. Teams customize deployments through text configuration while retaining common orchestration, tooling, governance, and registration paths.
- Architecture overview: One harness serves as the backbone across three deployment surfaces, with four supporting services providing the surrounding structure.The harness is packaged once; the gateway, registries, skills, and knowledge layer support its deployments.
- Motivation and scope: The architecture targets enterprises where teams otherwise build disparate custom solutions that are costly to review because each requires understanding a different repository.The paper also reports use in cron-based back-office automation beyond software engineering.
- Harness engine: A single harness repeatedly calls the model, allowing runtime orchestration and model upgrades without code changes to deployed solutions.The model observes each prior result and can spawn further harness instances; process changes become text edits.
- Shared capability layer: A shared tool gateway centralizes enterprise integrations so teams select capabilities from a registry instead of building separate integrations.Adding a tool is described as a gateway configuration change that becomes available to every solution.
- Governance by construction: Governance is built into creation and execution through infrastructure policy, automatic deployment registration, entitlement checks, per-call risk declarations, and approval gating.Risky calls are blocked before backend execution and escalate to human approval only when the judge cannot clear them.
- Deployment model: Teams fork one reference repository, edit an instructions file and configuration file, then use CI/CD to build, register, and deploy the solution.The deployment process provisions infrastructure and registers the solution automatically.
4.3 Four architectural layers
The architecture combines a shared knowledge substrate, harness engine, tool gateway, and governance structure around a filesystem-oriented agent loop. These layers support active document exploration, reusable skills, generic API access, and auditable execution.
- Four architectural layers: The architecture’s four layers are a git-mirrored knowledge substrate, harness engine, tool gateway, and cloud governance skeleton.The harness engine is driven by an instructions file and configuration file, while the gateway handles entitlement and risky-call approval.
- Knowledge substrate: The knowledge substrate mirrors enterprise documents into a plain-text tree that the harness reads directly rather than retrieving only nearest vector matches.The proposal treats retrieval as active filesystem exploration using the harness’s existing tools.
- Knowledge substrate: Scheduled source synchronization uses native change keys, preserves source-folder paths, and transcribes visual documents to text at ingest.The implementation avoids re-crawling unchanged content and writes each changed item to its mirrored path.
- Knowledge substrate: Git history makes knowledge access auditable by linking each logged model read to the mirror commit resolved at that moment.Auditors can reconstruct what a solution could have known by checking out the recorded commits.
- Identity-filtered knowledge: The same identity-filtering mechanism governs both tool discovery and document reads, so callers see only content permitted by their groups.A caller outside a document’s ACL group cannot list or read it.
- Skills: Skills load from built-in, shared-library, and project-specific tiers, with later tiers overriding earlier ones; deployed skills are baked in by default or fetched live when configured.The shared library is versioned and project-specific skills win on name clashes.
- Tool gateway: Generic backend request tools rely on model fluency with enterprise APIs instead of narrowly enumerated, hand-maintained action schemas.The proposed surface gives each backend one generic request tool with open parameters.
- Governance: Risky calls are presented with the judge’s reasoning and caller identity, blocking execution until an approver acts when automated review cannot resolve them.The approval queue holds the request open and provides an approve/deny action.
4.6 Identity and tool visibility
Tool visibility and execution are determined by caller identity through directory-group entitlements. The harness applies the same authorization path across unattended, interactive, and chat-triggered contexts.
- Entitlement configuration: A solution declares desired tool groups in config.yaml, and CI/CD adds its deployed identity to the matching directory groups.At runtime, an admin-edited, git-versioned YAML entitlement mapping determines what callers can discover and call.
- Risk review: A risky call is evaluated by a freshly spawned harness instance, and unresolved cases enter a blocking approval queue before backend execution.The judge’s verdict determines whether human approval is required.
- Discovery and enforcement: discover filters the tool catalog by the caller’s directory groups, and call recomputes that filtered set before allowing execution.A tool missing from discovery returns 404, while an unauthorized tool id returns 403.
- Risk declaration: The request must include a boolean risky field; omission returns 400 before entitlement checks or judging proceed.The harness does not assign risk levels or filter tools itself.
- Deployment contexts: The same unmodified harness artifact applies identical identity checks to unattended deployments, interactive engineers, and chat-triggered end users.Authorization remains outside the harness, avoiding a second copy that could drift or be bypassed.
4.7 Deployment mechanism: fork, configure, push
Deployment reduces a solution to a forked harness, two edited files, and a push; CI/CD handles registration, packaging, infrastructure, and fixed governance controls.
- Fork and configure: Deployment begins with an interactive harness run against the real problem before configuration is written.Tool discovery is filtered to the engineer’s entitlements during this initial pass.
- Fork and configure: The engineer records ownership, the problem, tool groups, skills, business area, model, schedule, and trigger in configuration.The example uses a cron trigger and names a live skill fetched from GitHub at each run.
- Push and deploy: On push, CI/CD registers first deployments, runs overlap and risk checks, builds the container, and generates infrastructure-as-code from shared modules.Registration identifiers are written back into configuration after the initial deployment.
- Push and deploy: Every deployment template is one shared module call with different arguments, while governance decisions remain encoded in the module rather than configuration.Runtime tool visibility is granted only after infrastructure creates the deployed identity.
- Fixed governance: The engineer never handles authentication, model clients, infrastructure, auditing, tool implementations, filtering, or registration because these controls are structurally fixed.The specialist’s domain work is captured in a skill that the same harness later rereads unattended against new exception batches.
4.8 Registration gating
Registration gates deployments through entitlement, overlap, and risk checks before infrastructure is provisioned, surfacing failures for human review rather than silently rejecting or allowing them.
- Entitlement: Registration resolves the triggering engineer’s directory groups and checks whether that person may register a solution for the business area.The entitlement gate uses the engineer’s existing single-sign-on identity.
- Entitlement: An unconfigured business area falls back to a low ceiling.
- Overlap: The overlap gate retrieves nearby registrations and uses a model to classify actual task overlap rather than relying on raw embedding similarity.A low threshold informs reviewers; only a high threshold for a near-certain duplicate blocks registration.
- Risk: Risk assessment evaluates the instructions, resolved skills, and requested tool groups to decide whether a human should review the combination before execution.The same tool group can imply different risk depending on the instructions and business area.
- Review outcome: A failing check marks the deployment pending review, prints the reason in the build summary, and prevents infrastructure provisioning until resolution.Reviewers approve or deny through links that update the review and registration statuses together.
4.9 The business-user path
Business users reach the same gateway and identity model through direct chat tool calls or asynchronously triggered harness runs, with execution separated from ingress for long tasks.
- Entry points: The business-user path assumes a chat surface such as Copilot Studio, Teams, or Slack with two entry points.
- Entry points: Direct tool calls provide synchronous access for short, read-only lookups, while full harness runs handle other work asynchronously.A multi-step run can exceed a chat connector’s timeout, so ingress and execution are separated.
- Trigger and execution: The run-trigger endpoint verifies the caller, enqueues the solution, caller, and payload, and immediately returns acceptance.
- Trigger and execution: Execution runs in a separate isolated instance that completes the loop and posts a callback, preventing scale-in or redeploy from killing a long-running process.
- Identity: The user’s identity, rather than the calling service’s identity, determines tool visibility for chat-triggered runs.
4.10 Code structure
The architecture keeps the harness code unchanged across terminal, cron, and chat deployments while external repositories and services supply configuration, skills, tools, registration, and triggering.
- Shared harness: Authorization remains outside the harness, allowing one codebase to run unmodified in terminal, unattended cron, and chat-triggered contexts.
- Supporting services: The harness is configured through instructions, skills, and tools, while a versioned skill library supplies procedural documents either interactively or to deployed solutions.Skills may be baked into images at build time or fetched at runtime with deployment-scoped tokens.
- Supporting services: The tool gateway, solution registry, and run-trigger service operate as always-on APIs around the harness.The run-trigger service launches cron-deployed backends and supports business-user interaction through chat surfaces.
4.11 Operating model
The operating model lets teams build and deploy niche solutions themselves while replacing upfront approval with registration and making review cheaper through a shared codebase. Its durability depends on continued frontier-model improvement and governance remaining inexpensive enough for teams to choose the fast path.
- A central platform team owns the gateway, lifecycle registry, reference harness, and policy baseline, while business and engineering units own use-case delivery.
- Registration replaces approval: deployment records the owner, purpose, tools, and business area, escalating only when entitlement or overlap gates are triggered.
- The architecture lets domain experts cheaply build niche fixes that central teams would not prioritize because the problems are too small or specific.
- Because every solution shares the same reference codebase and changes only through instructions and configuration files, auditing N solutions becomes reviewing N instruction files.
- Its durability depends on continued frontier-model capability improvement and governance staying cheap enough that teams voluntarily keep using the fast path.
5. Discussion / Limitations
The paper identifies limitations in measurement, failure-mode validation, scope, API coverage, security controls, knowledge permissions, and portability. These boundaries constrain what the architecture’s evidence currently demonstrates.
- No benchmark or paper-specific comparison evaluates the claims that harnesses suffice or outperform more elaborate architectures.
- The paper has no controlled benchmark showing how well its deployment-path mitigation handles lazy heuristics, hallucination, dropped constraints, or overconfidence.
- Governance by construction applies only to new work built on the reference repository and does not alter the installed base of existing pipelines and integrations.
- Credential-scoped tooling is untested on internal, undocumented, or unusually shaped enterprise APIs, where hand-built methods might perform better.
- The paper develops tool restriction in depth but lacks equivalent skill scanning and tests only coarser container isolation rather than SHarD’s dedicated OS sandboxing.
- The knowledge substrate inherits ACL fidelity from source permissions and trades freshness for reconstructibility because post-sync changes remain invisible until the next sync.
- The evidence comes from European enterprise engagements evaluated against Azure primitives, so portability to other clouds and on-premises settings remains un demonstrated.
6. Conclusion
The paper presents the harness as a governable architecture for enterprise AI automation, using four mechanisms to close the adoption gap identified by recent work. It frames the design as a durability bet while acknowledging that measurement remains unresolved.
- The architecture uses credential-scoped tooling, one unmodified harness across deployment surfaces, registration by shipping, and fresh-harness review for risky calls.
- These mechanisms address a governance gap identified by recent harness research and were informed by real enterprise engagements rather than designed in isolation.
- The design bets on continued frontier-model capability improvement, open-weight alternatives, and governance remaining cheap enough for voluntary adoption.
- Measurement remains open because the paper includes no benchmark and leaves comparison against alternatives for later work.