OpenCode fork for Cadence — turning a coding agent into a multi-agent Flow team

OpenCode is an open-source AI coding agent with strong fundamentals: a plugin system, hook architecture, clean LLM abstraction, and tens of thousands of daily downloads. FlowCode is my fork. Built to drop a multi-agent team into Cadence + EVM cross-VM work.

This post is the overview. Two follow-ups go deeper on the verification-lock pattern and on a structured model sweep I ran across DeepSeek thinking modes.

Why Cadence breaks general-purpose coding agents

Cadence is Flow’s smart contract language. It’s designed around resource-oriented programming — a paradigm where resources can only exist in one place at a time, cannot be duplicated, cannot be lost.

The failure mode from big models (Claude, GPT-4, the default OpenCode prompt) is consistent: syntactically plausible Cadence that fails on resource semantics. A resource copies when it should move. An entitlement is missing. An access modifier is wrong.

These aren’t random errors. They’re systematic gaps in the model’s understanding of the resource ownership system.

What FlowCode adds on top of OpenCode

The role split — why one orchestrator routes multiple workers

Default OpenCode runs as a single agent: one model, one context, one conversation. That works for simple coding tasks. It breaks for cross-VM Cadence + EVM work because a single context fills up with too many concerns: spec, tests, deployment, security review.

FlowCode runs a small team. Each role has its own prompt, its own allowlist, and its own exit gate.

1. 1
   Planner context: brief

   Reads the brief. Decomposes into stories. Writes a verification command per story. Validates every referenced story exists before exit. Closes the loop with a mode-aware handoff to writer.
2. 2
   Writer context: 1 story

   Picks up one story. Edits inside the worktree allowlist (project scope only). Hits a cleanup-before-DONE gate. Three-strikes rabbit-hole guard.
3. 3
   Auditor context: diff

   Static analysis pass over the diff. Cadence-aware patterns: resource semantics, entitlements, capability misuse. Spawns brain_propose if a finding suggests a new heuristic.
4. 4
   Verifier context: cmd + output

   Runs the planner-defined verification command — flow test, npm run typecheck, hardhat compile, whatever the story specified. The Command becomes the lock.
5. 5
   Reviewer context: diff + claims

   Adversarial pass: try to refute the writer's claims. Defaults to refuted=true if uncertain. Real defensive read.
6. 6
   Deployer context: green build

   Final gate. Pre-commit audit before push. Refuses --no-verify and other bypass flags.

Each role can call team_spawn to escalate. If team_spawn fails, the orchestrator catches it and surfaces a fresh planning round instead of looping.

Default OpenCode vs. FlowCode adaptations

Skills as composable primitives

FlowCode wires two skill submodules at the worktree level — not the project root — so each agent in a swarm session can have its own skill view:

The openjanus-app-builder role specifically loads the openjanus skills for privacy-app generation. The evm-writer and flow-evm-writer roles load the EVM-side skills from flow-ai-tools.

What changes the daily experience

Two patterns deserve their own posts and will get them:

1. Verification locks per story. The single mechanism that stopped agent loops more than anything else. The Command from the planner becomes the lock. Re-running it is a fingerprint match. Each iteration archives its locks. (Follow-up post coming.)

2. Model sweep across DeepSeek thinking modes. I ran 8 representative agent tasks × 3 modes × 2 runs = 48 calls. The interesting axis isn’t pass-rate — it’s reasoning-token cost. (Follow-up post coming.)

Why this isn’t bundled and shipped

What I’d ship even without the full bundle

If anyone wants pieces independently:

The patterns are more valuable than the code. The code is mine to use; the patterns are anyone’s to adopt.

Coming up next: the verification-lock pattern in depth, then the model sweep findings.