You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been looking closely at the orchestration loop in Unbound Force, specifically how the /opsx-propose and /uf.unleash workflows handle mid-execution discoveries. Right now, the swarm is highly effective at executing a feedforward, spec-driven plan (tasks.md). However, for long-horizon tasks, this rigidity can become a vulnerability.
I’d like to propose an architecture for asynchronous agent coordination (inspired by recent research like AgentRadio) paired with strongly typed interruption guardrails to give our swarm mid-flight agility without sacrificing architectural authority.
The Why: The Problem with Synchronous Execution
Currently, Unbound Force operates in a heavily phase-gated manner. If a developer agent discovers a critical flaw mid-execution—such as an invalid assumption about a repository dependency or a compliance framework—it is effectively trapped by the plan.
Because standard MCP tools are synchronous, an agent cannot work and listen for lateral updates simultaneously. It must either complete the doomed implementation or wait for a phase boundary (like a review council) to catch the error. This leads to:
Wasted Compute: Agents burning tokens executing a checklist that a peer already knows is invalid.
Context Paralysis: The lack of "passive awareness" means discoveries don't propagate across the swarm in real-time.
Flat Escalations: The swarm lacks the "attention governance" to differentiate between an implementation bug it can fix itself and an architectural flaw it shouldn't touch.
The Benefits
By transitioning to an asynchronous, typed-message architecture, we unlock several core capabilities:
Real-Time Agility: Agents can broadcast blockers laterally, allowing peers to abandon invalidated subtasks instantly rather than waiting for the review phase.
Autonomous Recovery (Self-Healing): If an agent strays from the spec, the system can autonomously force an interrupt, scrap the remaining tasks.md, and trigger an internal /opsx-repropose loop to get back on track without human intervention.
Strict Architectural Governance: By strongly typing the interruptions, we can enforce ownership boundaries. The swarm is empowered to rewrite implementations, but forced to halt and escalate to a human if the underlying Architecture Decision Record (ADR) is flawed.
The How: Implementation Architecture
To achieve this without blocking the primary agent loop, we need to decouple the listening mechanism from the LLM’s context window. We can build an asynchronous bridge using the OpenCode SDK and Replicator.
1. Replicator (The Go Message Broker)
Replicator needs to expose a pub/sub mechanism rather than standard synchronous tool calls. It will manage channels for active threads, holding connections open to push messages laterally as they occur.
2. The OpenCode Custom Tool (Background Listener)
Instead of an agent calling an MCP tool and blocking, we introduce an OpenCode custom tool (using @opencode-ai/plugin).
When called, this tool spawns a background listener connecting to Replicator and returns immediately, freeing the agent to continue its coding tasks.
When the listener receives a message, it uses the @opencode-ai/sdk client APIs to manipulate the active session and inject the lateral message back into the context window as a system notification.
3. The Guardrail Router (Typed Interruptions)
To solve the attention governance problem, the send_message primitive must require a structured JSON payload rather than plain text.
The background listener intercepts this payload and routes it based on its type:
{
"interruption": {
"type": "IMPLEMENTATION_DEVIATION",
"severity": "high",
"context": "The current authentication pipeline violates ADR-004. Current trajectory will fail compliance checks.",
"action_required": "HALT_AND_REPROPOSE"
}
}
Path A (Implementation Mismatch): If the type is IMPLEMENTATION_DEVIATION, the listener uses the OpenCode SDK to forcefully inject an interrupt prompt ("Halt current execution, discard tasks.md, and trigger reproposal"). The swarm self-corrects.
Path B (Architectural Blocker): If an agent broadcasts type: "GOVERNANCE_BLOCKER" (e.g., discovering the ADR itself contains an impossible constraint), the listener intercepts the message and halts the /uf.unleash loop entirely. It escalates to the human architect: "Execution halted: Flaw identified in ADR. Human review required."
This creates a resilient execution engine that is agile enough to fix its own coding mistakes, but respects strict architectural boundaries when the specs themselves are challenged.
Would love to hear thoughts from the community on this, particularly regarding the Replicator pub/sub implementation and OpenCode SDK session management.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hey everyone,
Inspired by this article: https://venturebeat.com/orchestration/four-ai-agents-coordinating-in-real-time-outperformed-claude-opus-4-8-on-enterprise-coding-tasks
I’ve been looking closely at the orchestration loop in Unbound Force, specifically how the /opsx-propose and /uf.unleash workflows handle mid-execution discoveries. Right now, the swarm is highly effective at executing a feedforward, spec-driven plan (tasks.md). However, for long-horizon tasks, this rigidity can become a vulnerability.
I’d like to propose an architecture for asynchronous agent coordination (inspired by recent research like AgentRadio) paired with strongly typed interruption guardrails to give our swarm mid-flight agility without sacrificing architectural authority.
The Why: The Problem with Synchronous Execution
Currently, Unbound Force operates in a heavily phase-gated manner. If a developer agent discovers a critical flaw mid-execution—such as an invalid assumption about a repository dependency or a compliance framework—it is effectively trapped by the plan.
Because standard MCP tools are synchronous, an agent cannot work and listen for lateral updates simultaneously. It must either complete the doomed implementation or wait for a phase boundary (like a review council) to catch the error. This leads to:
The Benefits
By transitioning to an asynchronous, typed-message architecture, we unlock several core capabilities:
The How: Implementation Architecture
To achieve this without blocking the primary agent loop, we need to decouple the listening mechanism from the LLM’s context window. We can build an asynchronous bridge using the OpenCode SDK and Replicator.
1. Replicator (The Go Message Broker)
Replicator needs to expose a pub/sub mechanism rather than standard synchronous tool calls. It will manage channels for active threads, holding connections open to push messages laterally as they occur.
2. The OpenCode Custom Tool (Background Listener)
Instead of an agent calling an MCP tool and blocking, we introduce an OpenCode custom tool (using @opencode-ai/plugin).
3. The Guardrail Router (Typed Interruptions)
To solve the attention governance problem, the send_message primitive must require a structured JSON payload rather than plain text.
The background listener intercepts this payload and routes it based on its type:
{ "interruption": { "type": "IMPLEMENTATION_DEVIATION", "severity": "high", "context": "The current authentication pipeline violates ADR-004. Current trajectory will fail compliance checks.", "action_required": "HALT_AND_REPROPOSE" } }This creates a resilient execution engine that is agile enough to fix its own coding mistakes, but respects strict architectural boundaries when the specs themselves are challenged.
Would love to hear thoughts from the community on this, particularly regarding the Replicator pub/sub implementation and OpenCode SDK session management.
All reactions