unbound-force
Replies: 6 comments 1 reply
|
Went for a deep dive through the UF stack asking all of the questions that I could think of and digging into alternatives. The biggest issue that arose is the lack of a baseline for comparison. With all of the harness frameworks, we need some way to measure pre/post performance based on a reasonably stable set of criteria so that we know what adjustments are truly valuable. Full report below. Unbound Force Ecosystem: Independent ReviewReviewer: Claude Opus 4.6 Executive SummaryUnbound Force (UF) is a harness engineering system for AI-assisted software development — four Go repos (57,488 LOC production, 86,061 LOC tests) built on OpenCode. It scaffolds agent definitions, commands, convention packs, and spec templates into a repo, then coordinates AI agents through specification pipelines, review councils, and semantic search. Verdict by Component
Key Findings
RecommendationMeasure, then decompose. First, establish a baseline — run real tasks with no harness, minimal harness, and full harness, scored by independent LLMs with majority voting, to learn which components actually earn their weight. Then make the stack modular: 1. What UF Actually Is (Not What It Claims To Be)Here is what each component actually delivers when you read the source: unbound-force (the CLI + scaffold engine)What it is: A Go CLI ( Real substance:
What it isn't: Despite the "AI agent swarm" branding, UF itself does not orchestrate agents. It scaffolds configuration files that define agent personas for OpenCode/Claude Code/Cursor to execute. The orchestration is declarative (Markdown instructions + MCP tool calls), not imperative. Source code volume: 14,801 LOC production Go + 23,913 LOC tests. Solid test-to-code ratio of 1.6:1. dewey (semantic knowledge graph)What it is: An MCP server providing 49 tools for navigating, searching, and writing to a knowledge graph backed by SQLite. Supports Obsidian vaults and Logseq graphs. Real substance:
Critical limitation: Brute-force vector search only. All embeddings are loaded into memory and compared via dot product. The code comments state this is intentional for <10K vectors (~5ms query time). No ANN indexes (HNSW, LSH). This will not scale to large knowledge bases. What it isn't: Not a replacement for a real vector database. Not suitable for multi-user or high-scale scenarios. File-based locking prevents concurrent servers. No encryption at rest. No access control. Source code volume: 21,024 LOC production Go + 35,305 LOC tests. gaze (code quality analysis)What it is: A static analysis tool for Go that detects observable side effects in functions, classifies them as contractual or incidental, maps test assertions to those effects, and computes both standard CRAP scores and a novel "contract coverage" metric. Real substance:
What it isn't: Not a multi-language tool (Go only). Not useful for projects without existing tests. Does not detect transitive side effects (only direct function body). Source code volume: 15,536 LOC production Go + 21,734 LOC tests. replicator (multi-agent coordination)What it is: An MCP server providing 53 tools for work item tracking, file reservation, agent messaging, and git worktree isolation. Rewritten from TypeScript ( Real substance:
Critical limitation: Replicator is a coordination layer, not an orchestrator. It does not spawn agents, distribute work, or manage lifecycles. What it isn't: Not a true agent framework (no agent spawning). Not suitable for >5 agents (SQLite single-writer contention). Not event-driven (polling only). Version 0.2.0 — experimental. Source code volume: 6,127 LOC production Go + 5,109 LOC tests. 2. Harness Weight AnalysisThis is the central concern for any team considering UF without enterprise token budgets. Harness Content Inventory
Token estimates use ~1 token per 4 characters, calibrated against Claude's tokenizer. This is total inventory across all 4 repos — not what loads in a single session (see next table). What a Session Actually LoadsNot everything loads at once. OpenCode loads AGENTS.md always (~21K tokens for the
Estimates based on verified character counts. Agent prompts range from ~1K to ~4K tokens; command files from ~1K to ~9K. The baseline problem: AGENTS.md at ~21K tokens (844 lines, 83K characters) consumes 16% of a 128K context window before anything else loads. A typical development session (one implementation agent + one review pass) reaches ~35-40K of harness content alone — roughly a quarter of the window, leaving three-quarters for actual work. This is manageable but not trivial. Teams that find this too heavy could trim AGENTS.md's "Recent Changes" section (which at ~200 lines is a compressed project history rather than actionable guidance). Cross-Repo DuplicationAgent files are replicated across all four repos. They are not identical (each is customized with repo-specific context like Dewey integration instructions), but the structural overlap is substantial:
This is intentional — each repo works standalone without cross-repo dependencies. The tradeoff is isolation over DRY. For a team working on one repo at a time, this is fine. For cross-repo work, it means redundant context loading. Recommendations for Token-Constrained Teams
3. Persona-Based EvaluationPersona 1: Solo Developer with a Side ProjectWould UF help? Probably not. The harness overhead dominates.
Recommendation: Use Gaze standalone. Skip the rest. Persona 2: Small Team (3-5 developers, mixed AI tool usage)Would UF help? Partially, with caveats.
Recommendation: Cherry-pick. Use convention packs + cross-tool bridges + Gaze. Skip the full Speckit pipeline. Use Replicator only if you're running multiple concurrent AI sessions. Persona 3: Team with Compliance RequirementsWould UF help? Yes, this is the sweet spot.
Concern: The governance is comprehensive but aspirational in places. Convention pack rules are guidance, not automated enforcement. The pack validator checks structural format (required sections exist) but does not verify that code actually follows the rules. A team with hard compliance requirements would need to add linting integration. Recommendation: Adopt fully, but add automated linting for convention pack rules and implement the schema validation layer that is currently defined but not enforced. Persona 4: Platform Team Evaluating AI Coding ToolsWould UF help? It demonstrates what "structured AI development" looks like, but it's opinionated.
Recommendation: Evaluate the architecture patterns (permission-based role isolation, convention packs, cross-tool bridges) as design inspiration. Don't adopt the full system unless your stack aligns (Go, OpenCode/Claude Code, Obsidian). 4. What's Real vs. What's Aspirational
5. Architecture Strengths5.1 Structural Role IsolationUF uses OpenCode's permission system to restrict what agents can do. This is not a prompt instruction ("please don't edit files") — it's an OpenCode permission declaration enforced at the tool-call level: tools:
write: false
edit: false
bash: falseAn agent with these permissions literally cannot call the write, edit, or bash tools. The platform enforces this structurally. This is Anthropic's "separate the doer from the judge" principle. However, the restrictions are not uniform across agents. Of 18 agents in the
The full "judge/doer separation" guarantee — where an agent structurally cannot modify the code it reviews — applies to 6 of 18 agents (33%), all of them core review roles (constitution check + 5 critical Divisor personas). The content-focused Divisor agents (Scribe, Herald, Envoy) intentionally retain write access, presumably to produce review artifacts. 13 of 18 agents (72%) have some form of The design is intentional — different roles get different access levels — but the blanket claim of "structural isolation on review agents" applies only to the strict subset. The 3 content Divisors and 2 agents with bash-only access represent a weaker guarantee. 5.2 Temperature Gradient DesignAgent temperatures are deliberately stratified:
No agent exceeds 0.5. This is a narrow, conservative range that keeps even creative roles on a tight leash. The design recognizes that AI agent reliability decreases with temperature, and calibrates accordingly. 5.3 Graceful DegradationDewey integration follows a 3-tier fallback pattern:
This is documented in agent prompts with explicit instructions for each tier. Agents don't crash when tools are unavailable — they adapt their strategy. 5.4 Cross-Tool BridgesThe CLAUDE.md and .cursorrules files are maintained by
This means teams using mixed tools (some developers on Claude Code, others on Cursor) see the same governance without manual synchronization. 6. Architecture Weaknesses6.1 Specification InflationThe
The total spec volume (~12K LOC) rivals the production code volume (~15K LOC in 6.2 Agent Persona Proliferation9 Divisor review agents is role proliferation. The personas overlap:
A single configurable reviewer agent with a persona parameter would be simpler to maintain and cheaper to load. The 9-agent design prioritizes human readability (each agent file is self-contained and readable) over system efficiency. 6.3 Guidance Without EnforcementConvention packs define rules with [MUST]/[SHOULD]/[MAY] severity levels. Examples:
These are actionable and enforceable — but not automated. The pack validator ( Similarly, JSON schemas are generated from Go structs but never validated at runtime. The schemas exist as documentation, not as gates. 6.4 Embedding at Scale33 files (11.7K LOC of Markdown) are embedded in the
This is a deliberate design decision (consistency over flexibility), but it conflicts with the reality that AI agent prompts iterate rapidly. 35 OpenSpec changes in the pipeline suggest prompts are still actively evolving. 6.5 No Event-Driven CoordinationReplicator's agent coordination is entirely polling-based. Agents check for messages with For 2-3 agents, polling is fine. For the "swarm" scenarios UF describes (5+ parallel agents), polling creates latency and wasted tokens (each poll is an MCP tool call that costs context space in the agent's conversation). 7. Why UF Instead of Upstream Alternatives?The honest question is whether UF's custom stack is justified when larger, better-supported projects exist. Here's what's actually available and how they compare. 7.1 Open File Formats and HooksThe cross-tool governance layer is converging on open file formats that any AI coding tool can read:
What UF adds beyond these: The scaffold engine ( What UF doesn't add: Deterministic enforcement. UF's convention packs are advisory (agents read and interpret them). Hooks and Cupcake policies are deterministic (they block on failure). UF could generate hook/policy configs from convention pack rules — but currently does not. Verdict: The open file formats (AGENTS.md, CLAUDE.md, .cursorrules) are the common ground for disparate teams. Pair them with deterministic enforcement via hooks or Cupcake for rules that must be followed. UF's value-add is the organizational layer above: specification discipline, multi-persona review, and Gaze. 7.2 Microsoft Agent Governance ToolkitMicrosoft's Agent Governance Toolkit (released April 2026, MIT license) is the first open-source framework to address all 10 OWASP Agentic AI risks with deterministic policy enforcement.
How it compares to UF: AGT operates at a different layer. It governs what agents can do at the tool-call level (policy enforcement, identity management, sandboxing). UF governs what agents should do at the convention level (coding standards, review workflows, specification discipline). They're complementary — AGT could enforce UF's policies deterministically. But AGT has Microsoft behind it, an active community, and addresses regulatory compliance that UF does not touch. Verdict: If your concern is agent security, access control, or compliance (EU AI Act, SOC2), AGT is the better choice — it's purpose-built, well-tested, and backed by a major vendor. UF doesn't compete in this space. 7.3 OpenCode EcosystemUF is built on OpenCode (150K+ GitHub stars), which has developed a large plugin ecosystem. The awesome-opencode list catalogs 80+ plugins, agents, and tools. Several directly overlap with UF's components: Policy Enforcement:
Specification Management:
Multi-Agent Orchestration:
Session & Context Management:
Observability:
What this means for UF: The OpenCode ecosystem shows that others are solving similar problems — validating the problem space UF operates in. Cupcake provides stronger policy enforcement than convention packs. OpenSpec (which UF already depends on) is the specification layer. Several projects explore multi-agent orchestration. However, the community depth is thin. Contributor analysis reveals that most of these alternatives are solo-developer projects:
Star counts do not correlate with community health. opencode-workspace has 401 stars on 30 commits from one person. Agent Memory has 224 stars on 8 total commits. These projects carry the same single-maintainer sustainability risk as UF itself — they could go unmaintained at any time. Verdict: The OpenCode ecosystem validates that others need the same capabilities UF provides, but "deprecate in favor of upstream" is not a safe strategy when most upstream alternatives are solo projects. The safer path is composability: architect UF so that components can be swapped as the ecosystem matures, without betting on any single upstream project's longevity. Cupcake (real team, Trail of Bits backing) and golangci-lint (massive community) are the two alternatives with enough substance to depend on today. UF's unique contributions remain Gaze (contract coverage), the tiered permission model, and the convention pack format. 7.4 Multi-Agent Frameworks (LangGraph, CrewAI)LangGraph, CrewAI, and (historically) AutoGen provide agent orchestration as code libraries:
How they compare to UF: These frameworks answer "how do I run multiple agents?" UF answers "how do I make agents follow my engineering standards?" They're not competing products. A team could use CrewAI for agent orchestration AND UF's convention packs for coding standards — or they could use LangGraph for orchestration AND Claude Code hooks for enforcement. UF's Replicator (coordination layer) is a lightweight alternative to these frameworks, but at v0.2.0, it doesn't compete on maturity or features. Verdict: If you need real multi-agent orchestration (agent spawning, task routing, parallel execution), use LangGraph or CrewAI. Replicator provides coordination primitives (file locks, messaging, work tracking) but does not spawn or manage agents. 7.5 Static Analysis (golangci-lint, Gaze)For Go convention enforcement specifically:
How they compare: golangci-lint enforces code style rules computationally. Gaze measures test quality via side-effect analysis. They're complementary. But UF's convention pack rules (like Verdict: Use golangci-lint for deterministic convention enforcement. Use Gaze for test quality analysis. Don't rely on UF's convention packs for rules that a linter can enforce. 7.6 The Composition QuestionThe question isn't "UF vs. alternatives" — it's "which UF components are worth the weight when upstream alternatives exist?"
Bottom line: Gaze's contract coverage is genuinely unique — no upstream alternative exists. The tiered permission model — particularly the 6 core review agents with full write/edit/bash isolation — is a real structural safety pattern. Beyond those two, every UF component has a functional alternative in the OpenCode ecosystem, but most alternatives are solo-developer projects with the same sustainability risks as UF. The pragmatic strategy is not "replace with upstream" but "make composable" — architect UF so that any component can be swapped when a genuinely community-backed alternative matures, while keeping the pieces that have no equivalent. 8. The Measurement GapThe most fundamental problem with UF is not harness weight, not monolithic design, and not upstream overlap. It's that there is no way to know whether the harness is helping. UF deploys 237 files of governance across 4 repos, runs up to 9 review agents per PR, enforces an 8-phase specification pipeline, and maintains 2 MCP servers. This costs real tokens, real developer time, and real maintenance effort. But nowhere does the system measure whether the output is better than a developer using Superpowers, or raw Claude Code, or even a simple AGENTS.md with golangci-lint in CI. What ExistsThe infrastructure for measurement is partially built:
What's MissingThe feedback loop is broken. Metrics are collected but never compared against a baseline. Learnings are stored but never acted upon. The system has no way to answer:
Why This MattersWithout measurement, every design decision in the stack is an opinion:
The system's own AGENTS.md states that Mx-F "measures iterative process changes" and uses "velocity, defect rates, cycle time, review feedback to help the team define, implement, and measure iterative process changes." The metrics collection code exists ( Establishing a BaselineBefore measuring whether the harness helps, you need to know what "without the harness" looks like. The most critical missing piece is a baseline: what is the quality of code produced by the same models with no UF harness at all — just a developer using Superpowers, or raw Claude Code with an AGENTS.md and golangci-lint in CI? Without this baseline, every claim about UF's value is unfalsifiable. "The Divisor council catches defects" means nothing if a single-agent review with good prompting catches the same defects. "The 8-phase pipeline prevents rework" means nothing if Superpowers' brainstorming → planning → TDD flow produces equivalent results at a fraction of the token cost. How to Measure: LLM-as-Judge with VotingA controlled study with human reviewers across enough PRs for statistical significance is impractical. But model-driven evaluation with majority voting is cheap, repeatable, and avoids the "harness grading its own homework" problem: Setup:
Evaluation:
What you learn:
Why this works:
Ongoing MeasurementBeyond the baseline study, three metrics should be tracked continuously:
The harness decay assessment in Section 9 recommends "disable and test" experiments — but without measurement infrastructure, there is no way to evaluate the results. The baseline study provides the initial data; ongoing metrics provide the feedback loop. 9. Harness Decay RiskAs models improve, some harness components become dead weight. Here is a granular assessment: Will Persist (Organizational, Not Model-Compensating)
Decay-Prone (Compensating for Current Model Weaknesses)
Monitor and TestPeriodic "disable and test" experiments would reveal which components still earn their weight. Specific tests to run:
10. Speckit vs OpenSpec vs Superpowers: Overlapping WorkflowsThree systems compete for the same workflow space — "how do I go from an idea to reviewed, tested code?" — and a team adopting UF will encounter all three. What Each System DoesOpenSpec (45K stars, 36 releases) provides lightweight spec-driven development. Core workflow: UF's Speckit layers an 8-phase pipeline on top of OpenSpec with 10 additional commands ( Superpowers (official Claude Code plugin marketplace) provides a development methodology as composable skills: How They Overlap
The three systems solve the same problem at different levels of rigidity:
The Real-World Team QuestionOn a disparate team — developers using different tools (Claude Code, Cursor, OpenCode), different experience levels, different working styles — which of these actually gets adopted? What adoption looks like in practice:
The adoption failure mode is complexity. A system that requires everyone on the team to learn 14+ slash commands and understand an 8-phase pipeline will not be used consistently. A system that triggers automatically (Superpowers) or provides just 3 commands (OpenSpec) has a much higher adoption floor. What Should Be Local vs CIThis is the critical design question that none of the three systems answer well. What must be deterministic (CI-enforced AND locally runnable): The principle: every gate that CI enforces must also be runnable locally before pushing. Developers should never learn about a failure from CI that they could have caught at their desk. This means a single task runner (e.g., Taskfile) with targets like
UF already has the CI pipeline for the first four (verified in What belongs only locally (judgment-based, developer-time feedback):
What should NOT be in either (currently in UF but adds cost without value):
RecommendationsFor the UF team:
For teams adopting tooling on a disparate team:
11. Strategic Recommendation: Decompose and ComposeThe NumbersOf UF's 57,488 lines of production Go across four repos:
47% of the codebase (Dewey + Replicator) addresses problems that others are also solving. Gaze at 27% is the only component with no functional equivalent anywhere. The Case for ComposabilityThe UF team is maintaining four Go repositories, 34 architectural specifications, 68 agent files, 129 command files, and 36 convention packs. This is a substantial maintenance burden for a team that — per its own positioning — is not an AI company with infinite resources. The OpenCode ecosystem has projects addressing similar problems (Cupcake for policy, OpenSpec for specs, Subtask2 for orchestration). But as Section 7.3 documents, most of these are solo-developer projects with the same sustainability risks as UF. "Deprecate in favor of upstream" is not a safe strategy when the upstream could disappear. The real problem is not that better alternatives exist — it's that UF is too monolithic and too prescriptive:
What's Actually UniqueAfter removing everything that has an upstream equivalent, UF's genuinely unique contributions are:
Proposed Strategy: Decompose and Compose
The Risk of Not DecomposingThe risk is not that better alternatives will emerge (they might not — most upstream alternatives are solo-dev projects with uncertain futures). The risk is that technology moves and UF can't move with it:
A composable architecture lets the team shed weight as technology advances, adopt the best tool for each job regardless of vendor, and keep investing in what's genuinely unique (Gaze, permission patterns, convention pack format) without maintaining infrastructure that the ecosystem may eventually solve better. 12. Architectural Suggestion: XDG Symlink FarmThe single largest source of repo clutter is that The proposal: move tool-owned files to What Moves to XDG (17 files)
What Stays in the Repo (16 files)
How It Works
Why This Matters
Design Constraints
Implementation ScopeThe refactor touches exactly 3 files:
No new files. No new dependencies. All Go stdlib ( The Appendix: Key ReferencesAll references are file paths within the four repositories examined. External links are included only where they appeared in the source material. External References
Source Files Examined (selected, by finding)Scaffold engine & file ownership
Schema validation (defined but unenforced)
Orchestration & learning
Infrastructure
Dewey semantic search
Gaze static analysis
Replicator coordination
Governance & harness weight
Specifications
|
|
Your deep dive identified several issues that converge on one actionable improvement: an always-on automated review for every PR. The gap today: Our review tooling (/review-pr, /review-council, Divisor agents) is powerful but manually triggered. Someone has to be in an OpenCode session and run the command. That means:
What I'm proposing: Every PR gets an automatic first-pass AI analysis with inline comments and a quality score -- no human initiation required. This does not replace human review or auto-merge anything. PRs still need our approval to merge. The bot handles the initial analysis so reviewers can focus on architecture and intent. Why this addresses findings from your review:
Impact: Reduces manual effort on routine checks, faster feedback for PR authors, consistent coverage across all PRs, and -- critically -- produces the measurement data the project currently lacks. |
|
@trevor-vaughan I find this statement puzzling:
My direct experience from using uf including replicator is contrary to that statement. |
|
I suspect that this really boils down to philosophy differences more than anything else |
|
The baseline point is important. Harness engineering becomes much more persuasive when it is evaluated against explicit counterfactuals, not only described architecturally. A useful evaluation matrix could compare at least four modes:
Then measure outcomes on the same task set: defect escape rate, test pass rate, unnecessary file churn, policy violations, recovery after failed CI, and human review time. That would turn the philosophical question into an engineering one: which parts of the harness reduce which classes of failure? I would also separate orchestration from scaffolding in the terminology. A system can create strong agent operating conditions without being a live multi-agent orchestrator. Calling that distinction out would make the architecture easier for new contributors to assess fairly. |
|
@musaabhasan After thinking about this further, this is definitely the main takeaway. With each model change and/or instruction change, we need some way to say if we're getting better or worse and why. |
Uh oh!
There was an error while loading. Please reload this page.
Yanli Liu's article "Harness Engineering: What Every AI Engineer Needs to Know in 2026" (AI Advances, Apr 17, 2026) codifies what three independent camps (OpenAI, Anthropic, ThoughtWorks) discovered about making AI agents reliable. The core thesis: Agent = Model + Harness, where the harness is everything that isn't the model itself -- constraints, feedback loops, documentation, and tools.
I analyzed Unbound Force against this framework. The findings are organized in three layers: UF as a harness system, OpenCode as the platform beneath it, and how UF concretely uses OpenCode's primitives.
The Five Convergence Principles
Liu identifies five principles that all three camps independently discovered. UF implements all five -- and in several cases goes further than the camps described.
1. Context Beats Instructions
What the camps found: Showing the agent real file paths, real code patterns, and real progress outperforms abstract instructions.
UF implementation: Three-tier context system that exceeds what the article describes:
@imports) and .cursorrules ensure the same context reaches Claude Code, Cursor, and OpenCode usersThe article describes AGENT.md files and JSON feature lists. UF adds a semantic memory layer (Dewey) and structured convention packs on top.
2. Planning and Execution Must Be Separated
What the camps found: Letting an agent plan and execute in the same pass produces unreliable output. The steps must be separate.
UF implementation: An 8-phase pipeline with hard gates between phases:
Crossing phases is a process violation -- agents MUST stop and report. Enforced through branch naming conventions, filesystem markers (
<!-- spec-review: passed -->), Spec Commit Gate (commit specs before implementation), and CI Parity Gate. The/unleashcommand has 6 defined exit points where human judgment is required.The article describes plan/execute separation as a two-phase concern. UF has 8 phases with hard gates between them.
3. Feedback Loops Are Non-Negotiable
What the camps found: A harness without feedback is "just a prompt with extra steps." ThoughtWorks says use both computational and inferential feedback, layered.
UF implementation: Exactly what ThoughtWorks recommends -- computational first, inferential second:
go test -race -count=1, golangci-lint, govulncheck, OSV-Scanner, TrivyThe key design decision: review agents (Guard, Adversary, etc.) have
tools: {write: false, edit: false, bash: false}-- they structurally cannot modify the code they review. This is Anthropic's "separate the doer from the judge" implemented as a structural guarantee via OpenCode's permission system, not a prompt instruction that could be violated.4. One Thing at a Time
What the camps found: Agents that try to do too much lose coherence. Forced incrementalism is universal.
UF implementation: One-phase-at-a-time progression enforced at the specification level, not just implementation. Tasks are checked off immediately, not in batches. The
/unleashcommand implements sequential phase execution with CI checkpoints between phases.5. The Codebase Is the Documentation
What the camps found: The repo is the single source of truth. Nobody maintains a separate knowledge base.
UF implementation: Everything lives in the repo -- 20+ agent files, 46 command files, convention packs, skills, constitution. The scaffold engine (
uf init) deploys harness artifacts viaembed.FS. Drift detection tests ensure embedded assets match their sources. CLAUDE.md and .cursorrules bridge the same documentation to other tools.Dewey provides a search layer over the repo contents, not a separate knowledge store.
OpenCode as the OS Layer
The article uses a computer analogy: Model=CPU, Context=RAM, Harness=OS, Agent=Application. OpenCode fits the OS role precisely -- it provides the primitives from which UF builds its harness:
OpenCode is the runtime. UF is the application.
How UF Uses OpenCode's Primitives
Quantitative Inventory
Five Architectural Patterns
1. Layered Context Injection: Four progressive layers using different OpenCode primitives:
2. Structural Role Isolation: Triple constraint combining three primitives:
3. Command-Mediated Workflow: Commands orchestrate multi-step workflows with feedback loops and exit points.
/review-councilsequences CI checks → Gaze analysis → 5+ parallel Divisor agents → fix iteration → final verdict.4. MCP as Infrastructure: Dewey fills OpenCode's cross-session memory gap. Replicator fills the multi-agent coordination gap (file reservations, messaging, work items).
5. Convention Packs as Portable Standards: 9 versioned, severity-classified rule files with a tool-owned/user-owned ownership split. No native OpenCode equivalent -- loaded through agent prompts, AGENTS.md directives, and cross-tool bridges.
Temperature Strategy
No agent exceeds 0.5. The range is deliberately narrow -- even creative roles stay on a tight leash.
ThoughtWorks 2x2 Control Matrix
The article's most rigorous framework classifies controls along feedforward/feedback and computational/inferential axes. UF populates all four quadrants:
go test -race -count=1, Gaze CRAP scores, coverage analysis, OSV-Scanner, Trivy, drift detection tests/review-pr, Dewey learnings storageMost teams have strong computational controls but weak inferential ones. UF has invested heavily in inferential controls on both axes.
Harness Decay Assessment
The article warns that as models improve, harness components become dead weight ("harness decay"). UF's layers have different decay profiles:
Likely to persist (organizational intent, not model compensators)
Potentially decay-prone (may compensate for current model limitations)
Structural concern: harness weight
AGENTS.md at 950+ lines, 46 commands, 19 agents, 9 convention packs, 13 skills. Per the "build to delete" advice, the team should periodically test whether disabling components (e.g., running with 3 Divisor agents instead of 6, skipping the Gaze feedback loop) affects output quality. If quality holds, delete the component.
Opportunities
OpenCode Features UF Doesn't Use Yet
instructionsconfigpermission:syntax (allow/ask/deny)tools:booleansaskmode for content agents (human confirms before file writes)bash: true/false"gh issue create *": "allow"for Curatorstepslimithidden: true@menuUF Patterns That Could Become OpenCode Primitives
handoffs:as a first-class concept with TUI visualizationConclusion
Unbound Force is a comprehensive harness engineering implementation built on OpenCode's platform primitives. It independently arrived at -- or deliberately adopted -- all five convergence principles before the article codified them. Its strongest innovation is the combination of OpenCode's permission system with multi-agent review to create structural judge/doer separation that no prompt instruction can violate.
The primary risk is harness weight. The system is comprehensive but heavy. Active pruning and periodic decay testing will determine whether the harness remains an asset or becomes a tax on every run.
The relationship validates the platform thesis: OpenCode provides the operating system, Unbound Force builds the application. The harness is not OpenCode -- it is the 19 agents, 46 commands, 13 skills, 9 convention packs, and 950-line AGENTS.md constructed using OpenCode's primitives.
All reactions