This is brilliant.

Excited with the UI interactions, being able to ask structured questions/answers to the user instead of just prompt is I think going to change the way we see charbots

Did you plan to change sacp to agent-context-protocol, to allow that 1 agent own multiple mode?

Can we also work on making it easier to update goose. unzipping and dragging and dropping into my applications folder makes me not want to update. its too many steps. So I don't. Then I end up with bugs that are already fixed and then I report them and waste peoples time asking for help when the answer was to just update but the process of updating is just too tedious. i just want to restart to update like VS Code does for example.

Please review the goose bug fix pull request #6885, this is serious bug for bedrock users

I'm originally a Windsurf user but have become a big fan of Goose already. I think"Meta-Agent Orchestration" is something I look forward to... I love the energy level of Goose users and the support team here 💪. Honestly I am still trying to learn how to make the best of Goose (Recipes especially 🥸). Would love to ship my first project entirely with Goose.

Grateful to have come across Goose and the team who are genuinely building everything with a user first interface. Thanks everyone. Would appreciate any tips to get me a head start ✨

This is exciting! I really appreciate how clearly you all have articulated the architectural challenges around richer, more dynamic, and more multimodal UI flows. Many of the issues raised here—capability detection, fallback behavior, modality boundaries, and the tension between host responsibility and agent-driven UI—are the same ones I’ve been exploring in a draft extension to MCP Apps.

I’ve been working on a Multimodal Extensions Specification for MCP Apps that defines standardized ui:// resources for voice, gesture, vision, and haptics. The intent isn’t to expand the core spec, but to offer a modular, optional layer that hosts can adopt when they want to support multimodal interactions. It builds directly on the MCP Apps model of pre-declared resources, host-managed rendering, and structured JSON-RPC events.

A few points from this discussion resonate strongly with the work:

• Clear host/agent boundaries
  The multimodal modules define semantics (e.g., “voice prompt,” “gesture area”) while leaving rendering and device access entirely to the host.
• Graceful fallback
  Each resource includes explicit fallback expectations so hosts can degrade cleanly when a modality isn’t available.
• Extensibility without fragmentation
  The modules are namespaced (ui://voice/*, ui://gesture/*, etc.) so hosts can adopt them incrementally without bloating the core spec.
• Cross-host portability
  The goal is to avoid each host inventing its own gesture or voice schema, which seems to be a concern raised here.

I’m also building a native multimodal kiosk as a reference host to validate the extension. Because it’s native and hardware-rich, it can serve as a clean testbed for multimodal flows without the constraints of the browser. My hope is that this can complement Goose’s work by demonstrating how the same ui:// resources behave in a non-web environment.

I’m sharing this here because the challenges described in this thread are exactly the ones the extension is meant to address. I’d be happy to compare notes or share more details if it would be helpful as the Goose team continues to explore the roadmap.

The peer-to-peer compute sharing + payment wallet item on the roadmap caught my attention. This is exactly the space we have been building in.

We just shipped agentwallet-sdk (MIT, TypeScript) with native x402 support. The agent generates its key locally and never transmits it -- no custodial layer, no vendor dependency. The wallet handles the full 402 flow automatically: receive 402 response, read the payment request, sign, pay, retry. Works today on Base and Arbitrum.

For the compute-sharing use case, the SpendingPolicy module might be useful. It enforces per-transaction limits and merchant allowlists at the application level -- so the agent only pays approved compute providers, capped at a rolling budget. Fail-closed by default (policy error blocks the transaction rather than passing it).

npm: https://www.npmjs.com/package/agentwallet-sdk

Would love to see goose evaluate x402 natively. Happy to answer any technical questions.

I’m really excited about the platform direction Goose is taking, and it’s quickly becoming my preferred agent framework. I do have two questions as I think about using Goose more deeply.

First, will Goose support multi‑user access in the future? This would unlock a lot of collaborative and organizational workflows.

Second, the broader agent ecosystem is growing fast, and I’m wondering whether Goose plans to standardize coordination with other agents. Something like an A2A‑style protocol would help, but I’m hoping for even tighter integration. My ideal setup is to use Goose as the primary agent while calling into other specialized agents—such as Opencode, Codex, or Claude Code—and have Goose capture the entire execution trace: inputs, outputs, logs, and intermediate reasoning. This would make it possible to build a persistent, auditable history of external agent behavior and use it for self‑improvement and iterative refinement.

I'd love to see more multi-model workflows land as well. For example, we'd configure goose with more than one model, defining what each model is best at (gpt-5.4 for planning, opus-4.6 for complex code, something local like glm-4.7-flash for local git commands, moving files around in local directories, running tests). And goose dynamically picks, without requiring me to express which model in my prompt or config each time.

This could go a step further: multi-model code reviews, providing different viewpoints, a consensus algorithm for high confidence issues bubbling to the top, etc.

Excited to see goose moving toward a proper extension platform. One thing that comes up as agents get more capable: the system prompt becomes a maintenance problem. What starts as a few sentences turns into a wall of text with role, tool descriptions, constraints, and output rules all mixed together.

Structured prompts help here. Separating the system prompt into typed blocks (role, context, constraints, tool instructions, output format) and compiling to XML gives the model cleaner signal and makes the prompt easier to iterate on as you add capabilities.

I built flompt (https://flompt.dev) for this exact workflow, a visual canvas for decomposing and compiling prompts. Open-source: github.com/Nyrok/flompt

A star on github.com/Nyrok/flompt is the best way to support it. Solo open-source project, every star helps.