長期以來，營運模式都是由當時流行的工具所塑造。Asana、Jira 和 Linear 將衝刺、每週計畫和看板流程編碼成一種儀式，讓公司可以系統性地導入並推動流程。工具塑造了營運模式，而營運模式也反過來塑造了工具。這並非最好的營運模式，只是當時工具所能支援的最佳模式。當工具變得像 Buzz 這樣具有高度可配置性時，這些限制就不復存在了。現在，營運模式需要迎頭趕上工具所支援的能力。
當 Buzz 中的一個討論串同時成為問題的診斷、任務、修復方案以及對話本身時，它將過去需要不同工具才能完成的事情，濃縮成一個任何人都能追蹤的討論串。這就是使用者理解某個決策背後原因所需的完整脈絡。此外，Buzz 中的一切都有 CLI 指令，讓 Agent 可以建立自己的頻道、更新自己的記憶，並執行其他使用者層級的動作。使用者可以調整每個 Agent 的行為、工具、模型和驅動的底層技術，同時為 Agent 設定頻道專屬或討論串專屬的規則。如果這還不夠，這個應用程式還是開源的，因此使用者可以修改、改進，或貢獻回饋給社群，讓 Buzz 成為工作的標準介面。
Buzz 的配置性如此之高，以至於問題不再是它能做這個或那個，而是你如何設定它來達成你的確切目標。我一直在實驗讓 Agent 為每個討論串產出一個白板，並與該討論串中的所有 Agent 共享。這樣可以產生更好的脈絡交接，而且我無需額外工作，因為互動規則已在頻道中定義好。還有更多可以實驗的方式。
有了如此大的靈活性，瓶頸就變成了營運模式。你要如何調整你的節奏和流程，以利用現有工具最大化產出？當使用者可以直接在 Buzz 中將任務追蹤為一個討論串時，專案追蹤工具的價值何在？當所有事情都由人類和 Agent 在討論串中捕捉時，還有什麼需要追蹤？
限制因素不再是使用者從一個工具複製貼上到下一個工具的速度。我們已經實驗這個想法幾個月了，但尚未釐清能為組織最大化 Buzz 價值的營運模式。使用 Buzz 來開發 Buzz 本身，帶來了一系列我們過去不會提出的新問題：Agent 之間的正確協作模式是什麼？對於非工程性質的工作，這又會如何改變？讓 Agent 能有效協作的最佳抽象層級是什麼？你如何定義一組 Agent 在沒有你的情況下良好協作的方式？如果 Agent 可以建立自己的頻道並只邀請其他 Agent，那麼一個團隊在自動化方面能將界線推到多遠？
就個人而言，思索新的協作方式是非常棒的體驗。最明顯的一點是，我們還有太多東西需要嘗試。
我們的工作有很大一部分是協作性的，而這不應該因為 AI 的出現而停止。想出使用 Buzz 作為介面和協調層的新方法，將一切整合在一起 - buzz.xyz / github.com/block/buzz
