Scoped after deployment review
Buzz Setup, Integration & Managed Hosting
A Buzz workspace where your team and approved AI agents can work in the same rooms, on a relay with clear ownership and operating boundaries.
I deploy and configure Buzz for teams that want human conversations, agents, workflows, Git activity, and search in one signed event log. Choose a client-owned handoff or an isolated managed relay under a recurring agreement.
Example system map
Illustrative setup: a private product-engineering workspace
Inputs and systems
Buzz Desktop
Buzz CLI
Agent Communication Protocol (ACP)
Implementation path
Map the team
approved agents, channels, repositories, workflows, retention needs, and external model or tool providers before choosing the deployment boundary.
Deploy one Buzz community with pinned
application versions, Postgres, Redis, S3-compatible object storage, persistent Git data, stable secrets, TLS, and restricted administrative access.
Configure the supported desktop clients
create separate human and agent identities, and verify public and private channel membership with authorized and unauthorized accounts.
Connected systems
11
Example stages
7
Delivery model
Client-owned or managed
What a client-owned Buzz deployment can include
The implementation is scoped around one real workspace and its approved people, agents, data, and operating requirements.
The client owns and pays for its infrastructure, model providers, software accounts, domains, and other third-party services. Ongoing operations are separate unless explicitly included.
Optional managed server
Optional OrchestriAI-managed Buzz hosting
For teams that do not want to operate the relay, OrchestriAI can run an isolated Buzz server and community under a recurring agreement with a defined operational and data boundary.
Managed server pricing
Quoted monthly
Third-party hosting, storage, model, messaging, domain, and software costs are separate unless the quote says otherwise. Monitoring, support hours, response times, uptime commitments, backup retention, recovery objectives, and deletion timing apply only as stated in the signed agreement. Managed hosting does not by itself make a deployment compliant with HIPAA, SOC 2, GDPR, or another framework.
What gets built, and when it makes sense
Best for teams building alongside AI agents
Buzz is a strong fit for engineering and product teams that want humans and agents to share channels, threads, search, workflow events, Git context, and review history instead of scattering that record across unrelated tools. It is especially relevant when each person and agent should have a distinct signed identity and channel membership. Buzz is a workspace and relay, not an AI model or a replacement for the agent runtime itself; the useful deployment combines Buzz with the ACP-compatible tools and provider accounts the team has deliberately approved.
Client-owned deployment or isolated managed hosting
For a client-owned deployment, I install the production Compose stack or another supported architecture in your environment, configure the relay and desktop clients, verify it, and hand over the operating runbook. If you prefer not to run the server, I can operate an isolated Buzz relay and its supporting services in an OrchestriAI-managed environment under a recurring agreement. Managed scope, support hours, recovery objectives, data location, access, and offboarding are written down before launch; hosting does not create an implied SLA or compliance certification.
Agents are connected through ACP, not a hidden model bundle
Buzz documents an ACP harness for Goose, Codex, Claude Code, and other agents that implement ACP over standard input and output. Each agent receives its own Nostr keypair and channel membership, while its model and provider credentials belong to the selected runtime. Codex and Claude Code integrations, for example, use their respective OpenAI and Anthropic credentials rather than a model account supplied by Buzz. I configure only the agreed runtimes, models, author gates, channel scope, concurrency, tools, and optional MCP server, then test the exact combination instead of presenting every preset as production-ready by default.
Security follows the relay, identity, and channel model
Buzz authenticates relay connections with signed Nostr challenges and uses channel membership as its access-control gate. Production deployments also need TLS at the relay or reverse proxy because the relay does not enforce transport encryption itself. Desktop private keys use the operating-system keyring where available; headless agents commonly receive keys through protected environment or secret-management boundaries. I document who controls every relay, human, and agent key, restrict server access, review private-channel membership, and keep credentials out of repositories and handoff documents. Buzz's hash-chained audit log is tamper-evident, not tamper-resistant against an attacker who can rewrite the database, so it is not presented as a compliance guarantee.
Your data boundary includes the whole working stack
A production Buzz relay persists events and search data in Postgres, uses Redis for live coordination, stores media and content-addressed objects in S3-compatible storage such as MinIO, and can maintain Git data on a persistent volume. Backups, logs, exported data, desktop keys, agent keys, and provider prompts all belong in the boundary review. When an external agent or model provider is connected, relevant messages and tool context may leave the Buzz server under that provider's terms. Client-owned deployments keep the infrastructure and accounts under the client's control. Managed hosting places relay operations with OrchestriAI, while business accounts and model-provider credentials remain client-owned wherever the integration permits.
Testing, updates, and an honest maturity boundary
Before handoff or launch, I test relay liveness, authentication, channel visibility, desktop connectivity, the promised agent paths, workflow triggers, restart behavior, backups, and recovery steps in scope. Buzz is pre-1.0, its security policy supports the latest main branch actively, and previous releases are best-effort rather than long-term-support branches. That makes controlled version selection and regression testing important. A one-time setup does not include continuous monitoring or upgrades; managed maintenance covers only the checks, update cadence, support window, and incident response written into the agreement.
When Buzz is not the right fit
Buzz is not the best choice when you need a mature vendor SaaS with built-in contractual uptime, a turnkey compliance certification, or one shared workspace for parties that should not rely on channel membership as the authorization boundary. It is also more infrastructure than a team needs when the real requirement is one private assistant or a small deterministic automation. In those cases I will recommend a narrower agent deployment, conventional collaboration software, or a purpose-built workflow rather than forcing Buzz into the scope.
Illustrative setup: a private product-engineering workspace
End-to-end walkthrough
- 0101
Map the team
approved agents, channels, repositories, workflows, retention needs, and external model or tool providers before choosing the deployment boundary.
- 0202
Deploy one Buzz community with pinned
application versions, Postgres, Redis, S3-compatible object storage, persistent Git data, stable secrets, TLS, and restricted administrative access.
- 0303
Configure the supported desktop clients
create separate human and agent identities, and verify public and private channel membership with authorized and unauthorized accounts.
- 0404
Connect one approved ACP agent using
its own keypair, author gate, client-owned model credentials, limited channel scope, and only the tools needed for the first workflow.
- 0505
Implement a small source-backed workflow
such as posting repository or release activity for human review, without treating still-in-progress Buzz features as delivered capabilities.
- 0606
Test liveness
message and search behavior, agent responses, failure paths, restart behavior, backup creation, and a representative restore or export procedure.
- 0707
Hand over the architecture
ownership map, version and update policy, backup and recovery runbook, credential-rotation steps, and documented support boundary.
Integrations
Explore related work
See where this service fits, how it has been applied, and the technical work behind it.
FAQ
Planning a human-and-agent workspace?
Share the team, agents, repositories, workflows, and hosting preference. I will map the deployment, data boundary, ownership, and operating scope before anything is installed.