Back/harness engineering

Lightweight Harness vs Orchestration Harness

Updated 2026-04-13
2 min read
280 words

Lightweight Harness vs Orchestration Harness

Framework by @PawelHuryn: Harrison Chase is right that agents need memory (markdown, git, open formats), but personal agents and enterprise workflows require fundamentally different harness designs.

Blast-radius difference

Dimension Personal agent Business-critical workflow
Examples Coding copilots, email assistants Production pipelines, financial ops
Error impact Low — fix and move on High — revenue, compliance, safety
Harness style Lightweight Orchestration

Enforcement hierarchy

Security boundaries, file permissions, and tool access must be enforced in code, not merely "suggested" in prompts.

  • Lightweight harness solves portability and fast iteration.
  • Orchestration harness is where enterprise value is actually captured because it provides deterministic guardrails.

Key distinction

  • Lightweight harness: minimal routing, open formats, easy to move across models and environments.
  • Orchestration harness: robust state machines, strict access control, audit logging, failure-domain isolation, and human-in-the-loop escalation.

Practical recommendations

  1. Segment your projects: label each agent workflow as "personal" or "enterprise" and choose the harness depth accordingly.
  2. Move security down the stack: convert prompt-level "please do not delete files" into filesystem-level read-only mounts and code-level permission checks.
  3. Add deterministic frameworks for business-critical flows: explicit error handling, rollback procedures, and observability.

Counterpoints & Gaps

  • Many workflows start personal and later graduate to enterprise; harness migration is non-trivial.
  • "Enforced in code" assumes engineering resources that early-stage teams may not have.
  • There is no widely accepted standard or open-source reference for what constitutes a minimum viable orchestration harness.

Sources

Linked from