Set up a collaborative project space
When you maintain a host, SDK, samples, remote service, website and guides yourself, bring specialist partners together around the same change. Link projects and responsibilities, then review a dependency plan.
Outcome: Connect the host, SDK, sample, remote service, website and docs around one goal, ready for cross-project work.
Before you begin: Use a desktop source build with the collaboration workbench. Prepare the model, experts and practice projects described below; check release notes for installer coverage.
On this page
01Start with one shared change
This exercise addresses a familiar problem: after changing the host, you switch projects, repeat the same context to each agent, and track their results yourself. Choose a clearly defined host change and write down the goal, current behavior, interface rules and verification method. For example, improve an existing extension configuration flow, then align the SDK, connected service, minimal sample, website and guides. Your source and reviewed contract determine the API; this exercise invents no new method.
02Check the app and model
Use a desktop source build that includes Collaboration workbench, and configure a model with compatible tool calling. Website illustrations and browser previews do not execute tasks. Check release notes for installer coverage. Fully quit and restart the app after updating the main process or engine. Check the version before creating duplicate projects.
Start the app and connect a model03Add existing projects
Add the directories involved in this change. Replace the example names below with your own. If guides share the website repository, use that project for separate work packages; shared-directory execution remains serialized. Test the SSH connection and select a separate service directory. Keep credentials out of prompts. Without a remote environment, practice with a local service and leave remote deployment unverified.
| Example project | Location | Responsibility |
|---|---|---|
| host | Existing local host repository | Implement the host change, contract and tests. |
| SDK | Local tooling repository | Align with the reviewed host interface. |
| sample | Local examples repository | Demonstrate the SDK and service together. |
| Connected service | SSH test-server directory | Adapt the interface, test it and document deployment. |
| website | Local website repository | Update capability descriptions and entry points. |
| guides | Guide repository or website project | Write reproducible instructions from the actual sample. |
04Create the space and assign partners
Open Collaboration workbench → Project spaces → Create project space. Name it Business Agent platform · Capability alignment. Set the goal: bring each project to a verifiable state using the reviewed host change. A space stores logical associations without moving code or requiring a common root. Under Team and projects, link the projects, choose prepared experts and assign their responsibilities.
05Choose expertise by responsibility
Cover requirements and interfaces, host implementation, SDK and service integration, samples, website copy, guides, and delivery testing. Start from relevant product, architecture, integration, frontend, copywriting, documentation and QA skill combinations, then adjust specialization. One expert may own several related nodes. Role names do not determine execution order; dependencies determine handoffs.
Add specialist partners with skills06Prepare shared references and handoff rules
Add the change brief, interface contract, directory responsibilities and verification commands as space documents or discussion references. Require each work package to record changed files, a verifiable version or artifact, test commands and results, and remaining gaps. State how downstream work can obtain SDK packages, service endpoints and documents. Project links do not copy files, publish packages or grant extra read access.
07Describe the goal centrally, then review the plan
Open Discussion and describe the shared goal with those references, rather than repeating the background in a separate chat for every project. The host can coordinate experts and propose tasks. You still answer missing questions and confirm assignments and dependencies. Use the next guide to prepare a plan; review it before starting project work.
Prepare multi-project tasks and dependencies08Check the setup
You should see the participating projects, experts, assignments and shared sources. Linking them does not start implementation. An SSH connection does not prove deployment, and installed skills do not prove accepted output. This exercise describes verification to perform; it does not certify a completed multi-repository remote workflow.
Check the result and troubleshoot
Connect the host, SDK, sample, remote service, website and docs around one goal, ready for cross-project work.
Check actual results using this page’s verification steps. For business integrations, inspect UI submission, tool receipts and server records separately.
Check states and recovery steps →