Summary
Deep research of OpenCode (139k stars, by OpenTUI creators) and Goose (39.1k stars, Linux Foundation AAIF) reveals concrete patterns we should adopt for Grove's multi-agent TUI and collaboration model.
Part 1: What to learn from OpenCode's OpenTUI usage
OpenCode is THE reference implementation for how OpenTUI should be used — built by the same team that created OpenTUI. Key architectural patterns Grove should adopt:
1. Worker thread architecture (High value)
OpenCode runs the backend (Hono server, SQLite, agent runtime) in a worker thread while the main thread handles TUI rendering. Communication is via typed JSON-RPC. This prevents UI hangs during heavy I/O.
Grove's problem: grove up runs server + TUI in the same process. Heavy contribution store operations or gossip exchanges can lag the TUI.
Adopt: Move server/store operations to a worker thread. The TUI communicates via RPC to the worker, keeping rendering smooth.
2. Plugin slot system for TUI extensibility (High value)
OpenCode uses OpenTUI's plugin slots system to let external plugins contribute UI:
feature-plugins/sidebar/ — LSP status, MCP connections, file context, todosfeature-plugins/home/ — footer tips, home page contentfeature-plugins/system/ — plugin management
Plugins are loaded from .opencode/plugins/ (TypeScript files) at runtime.
Grove's opportunity: Use plugin slots so presets or external tools can register custom TUI panels. A research-loop preset could add an "Eval Results" panel. A GitHub integration could add a PR panel. This maps to our existing BrickGate-style panel visibility but is much more powerful.
3. Configurable layout system (Medium value)
OpenCode's layout system lets users customize spacing and visibility via JSON files:
/layout slash command to switch layouts- Built-in layouts:
default, dense
- Custom layouts in
~/.config/opencode/layout/
- 18 configurable parameters (padding, spacing, visibility)
Grove's opportunity: Create a ~/.grove/layout.json for custom TUI layouts. Users with small terminals get a dense mode, users with large terminals get a wide mode.
4. Scroll acceleration with anchoring (Medium value)
OpenCode solved the jitter problem — when an agent streams content and you're scrolled up, the viewport stays anchored. Uses 50ms polling to track position and adjusts offset when layout recalculates.
Grove's problem: Manual terminalScrollOffset in reducer, no anchor when content changes.
Adopt: Use OpenCode's scroll acceleration pattern with anchoring in all scrollable panels.
5. Agent-colored messages with subagent footer (High value for multi-agent)
OpenCode uses useLocal().agent.color(name) to assign distinct colors per agent. There's a subagent-footer.tsx that shows subagent status inline in the session view.
Grove's opportunity: Grove's topology defines roles with multiple agents. Each agent's contributions should be color-coded in the TUI by role/agentId. The agents panel should show live status with role-specific colors (already partially done via AGENT_COLORS and agentStatusIcon in theme.ts).
6. Extmarks and rich autocomplete (Medium value)
OpenCode's prompt supports @ for file/agent references and / for slash commands with fuzzy search (fuzzysort) and frecency-based ranking.
Grove's opportunity: The command palette could support @agent mentions for inbox messages and / for slash commands. The search panel could use fuzzy matching with frecency.
7. 60 FPS with requestLive() (Low value)
OpenCode runs at 60 FPS with requestLive() during animations. Grove uses default 30 FPS. Worth considering for smoother spinner/transition animations.
Part 2: What to learn from Goose's agent organization
Goose's architecture has several patterns relevant to Grove's multi-agent collaboration:
1. Recipe system — reusable task templates (High value)
Goose has a "recipe system" for reusable task definitions with parameters, execution, and scheduling. Recipes can be shared, run on schedule, and composed.
Grove's equivalent: This maps to our GROVE.md contracts + presets, but Goose makes recipes first-class objects that agents can discover, parameterize, and schedule. We could model recipes as plan contributions with structured parameters, discoverable via grove_search --tag recipe.
2. Extension types and lifecycle (Medium value)
Goose supports 6 extension types: stdio, builtin, streamable_http, platform, frontend, inline_python. Each has different transport and lifecycle.
Grove's analogy: Our MCP tools are analogous but we only have two transport types (stdio, HTTP/SSE). The frontend extension type is interesting — it lets extensions contribute to the desktop UI. This maps to OpenTUI plugin slots.
3. Agent Communication Protocol (ACP) (High value for Grove)
Goose implements ACP — a standardized protocol for agent-to-agent communication beyond MCP's tool/resource model. ACP enables:
- Agent discovery (who's available?)
- Capability negotiation
- Task delegation with structured handoff
- Session management across agents
Grove's opportunity: Grove's gossip protocol + topology router + inbox messaging already implement much of this, but it's ad-hoc. Formalizing an ACP-like protocol for how Grove agents discover each other, negotiate capabilities, and hand off work would make multi-agent collaboration more robust. The contribution DAG with typed relations (derives_from, reviews, responds_to) is actually a richer handoff model than ACP — but the discovery/negotiation layer is weaker.
4. Memory extension — persistent knowledge (Medium value)
Goose's memory extension stores categorized information with tags in local and global storage (.goose/memory, ~/.config/goose/memory). Agents can remember_memory and retrieve_memories.
Grove's equivalent: Discussion contributions tagged with skill or memory already serve this purpose. But Goose's two-tier storage (project-local vs global) is a useful pattern — Grove could distinguish between grove-scoped and agent-global memories.
5. Context compaction (Already done better)
Goose has context management and compaction for token efficiency. Grove's contribution model inherently handles this — each contribution is a self-contained unit that can be selectively loaded. The frontier ranks what's most relevant. No action needed.
6. Custom distributions (Interesting for Grove)
Goose supports custom "distros" — preconfigured builds with specific providers, extensions, and branding. Think "Goose for Data Science" or "Goose for Security Auditing."
Grove's equivalent: Our presets (review-loop, swarm-ops, etc.) already do this. But Goose's approach of making distros self-contained packages you can publish and share is more polished than code-defined presets.
Prioritized Action Items
| Priority |
Item |
Source |
Grove Issue |
| P0 |
Plugin slots for extensible TUI panels |
OpenCode |
Update #212 |
| P0 |
Agent-colored contributions in TUI |
OpenCode |
New work in #216 |
| P1 |
Worker thread architecture for TUI |
OpenCode |
New |
| P1 |
Configurable layout system (default/dense) |
OpenCode |
New |
| P1 |
Scroll acceleration with anchoring |
OpenCode |
Update #216 |
| P1 |
Formalize agent discovery/handoff protocol |
Goose ACP |
New |
| P2 |
Recipe-style reusable task templates |
Goose |
Maps to plan contributions |
| P2 |
Rich autocomplete with @agent mentions |
OpenCode |
Enhancement to command palette |
| P2 |
Two-tier memory (grove-local + agent-global) |
Goose |
Enhancement to discussion/skill model |
| P3 |
Custom grove distributions as packages |
Goose |
Enhancement to presets |
References
Summary
Deep research of OpenCode (139k stars, by OpenTUI creators) and Goose (39.1k stars, Linux Foundation AAIF) reveals concrete patterns we should adopt for Grove's multi-agent TUI and collaboration model.
Part 1: What to learn from OpenCode's OpenTUI usage
OpenCode is THE reference implementation for how OpenTUI should be used — built by the same team that created OpenTUI. Key architectural patterns Grove should adopt:
1. Worker thread architecture (High value)
OpenCode runs the backend (Hono server, SQLite, agent runtime) in a worker thread while the main thread handles TUI rendering. Communication is via typed JSON-RPC. This prevents UI hangs during heavy I/O.
Grove's problem:
grove upruns server + TUI in the same process. Heavy contribution store operations or gossip exchanges can lag the TUI.Adopt: Move server/store operations to a worker thread. The TUI communicates via RPC to the worker, keeping rendering smooth.
2. Plugin slot system for TUI extensibility (High value)
OpenCode uses OpenTUI's plugin slots system to let external plugins contribute UI:
feature-plugins/sidebar/— LSP status, MCP connections, file context, todosfeature-plugins/home/— footer tips, home page contentfeature-plugins/system/— plugin managementPlugins are loaded from
.opencode/plugins/(TypeScript files) at runtime.Grove's opportunity: Use plugin slots so presets or external tools can register custom TUI panels. A
research-looppreset could add an "Eval Results" panel. A GitHub integration could add a PR panel. This maps to our existingBrickGate-style panel visibility but is much more powerful.3. Configurable layout system (Medium value)
OpenCode's layout system lets users customize spacing and visibility via JSON files:
/layoutslash command to switch layoutsdefault,dense~/.config/opencode/layout/Grove's opportunity: Create a
~/.grove/layout.jsonfor custom TUI layouts. Users with small terminals get adensemode, users with large terminals get awidemode.4. Scroll acceleration with anchoring (Medium value)
OpenCode solved the jitter problem — when an agent streams content and you're scrolled up, the viewport stays anchored. Uses 50ms polling to track position and adjusts offset when layout recalculates.
Grove's problem: Manual
terminalScrollOffsetin reducer, no anchor when content changes.Adopt: Use OpenCode's scroll acceleration pattern with anchoring in all scrollable panels.
5. Agent-colored messages with subagent footer (High value for multi-agent)
OpenCode uses
useLocal().agent.color(name)to assign distinct colors per agent. There's asubagent-footer.tsxthat shows subagent status inline in the session view.Grove's opportunity: Grove's topology defines roles with multiple agents. Each agent's contributions should be color-coded in the TUI by role/agentId. The agents panel should show live status with role-specific colors (already partially done via
AGENT_COLORSandagentStatusIconintheme.ts).6. Extmarks and rich autocomplete (Medium value)
OpenCode's prompt supports
@for file/agent references and/for slash commands with fuzzy search (fuzzysort) and frecency-based ranking.Grove's opportunity: The command palette could support
@agentmentions for inbox messages and/for slash commands. The search panel could use fuzzy matching with frecency.7. 60 FPS with
requestLive()(Low value)OpenCode runs at 60 FPS with
requestLive()during animations. Grove uses default 30 FPS. Worth considering for smoother spinner/transition animations.Part 2: What to learn from Goose's agent organization
Goose's architecture has several patterns relevant to Grove's multi-agent collaboration:
1. Recipe system — reusable task templates (High value)
Goose has a "recipe system" for reusable task definitions with parameters, execution, and scheduling. Recipes can be shared, run on schedule, and composed.
Grove's equivalent: This maps to our GROVE.md contracts + presets, but Goose makes recipes first-class objects that agents can discover, parameterize, and schedule. We could model recipes as
plancontributions with structured parameters, discoverable viagrove_search --tag recipe.2. Extension types and lifecycle (Medium value)
Goose supports 6 extension types:
stdio,builtin,streamable_http,platform,frontend,inline_python. Each has different transport and lifecycle.Grove's analogy: Our MCP tools are analogous but we only have two transport types (stdio, HTTP/SSE). The
frontendextension type is interesting — it lets extensions contribute to the desktop UI. This maps to OpenTUI plugin slots.3. Agent Communication Protocol (ACP) (High value for Grove)
Goose implements ACP — a standardized protocol for agent-to-agent communication beyond MCP's tool/resource model. ACP enables:
Grove's opportunity: Grove's gossip protocol + topology router + inbox messaging already implement much of this, but it's ad-hoc. Formalizing an ACP-like protocol for how Grove agents discover each other, negotiate capabilities, and hand off work would make multi-agent collaboration more robust. The contribution DAG with typed relations (
derives_from,reviews,responds_to) is actually a richer handoff model than ACP — but the discovery/negotiation layer is weaker.4. Memory extension — persistent knowledge (Medium value)
Goose's memory extension stores categorized information with tags in local and global storage (
.goose/memory,~/.config/goose/memory). Agents canremember_memoryandretrieve_memories.Grove's equivalent: Discussion contributions tagged with
skillormemoryalready serve this purpose. But Goose's two-tier storage (project-local vs global) is a useful pattern — Grove could distinguish between grove-scoped and agent-global memories.5. Context compaction (Already done better)
Goose has context management and compaction for token efficiency. Grove's contribution model inherently handles this — each contribution is a self-contained unit that can be selectively loaded. The frontier ranks what's most relevant. No action needed.
6. Custom distributions (Interesting for Grove)
Goose supports custom "distros" — preconfigured builds with specific providers, extensions, and branding. Think "Goose for Data Science" or "Goose for Security Auditing."
Grove's equivalent: Our presets (review-loop, swarm-ops, etc.) already do this. But Goose's approach of making distros self-contained packages you can publish and share is more polished than code-defined presets.
Prioritized Action Items
References
packages/opencode/src/cli/cmd/tui/packages/opencode/src/cli/cmd/tui/plugin/