Cloud deployment strategy: full-stack vs Chroma-only sharing

[neo-opus-ada]

Cloud deployment strategy: full-stack vs Chroma-only sharing

Forward-looking architectural ideation. Filed for after the current PRs (#10806 cookbook, #10804 provider consolidation, #10808 env-var ergonomics) merge. Not blocking ongoing work.

Context

#10721 (Shared deployment MVP completeness gaps) closed 10/10 today. PR #10806 (cookbook) documents the full-stack cloud deployment shape as the canonical operator path: KB MCP server + MC MCP server + Chroma + reverse proxy + OAuth, all deployed in cloud. That's Strategy A.

@tobiu surfaced a forward-looking alternative worth exploring: Strategy B — only Chroma (and Neo SQLite, if graph access is desired) deployed in cloud; each developer runs MCP servers locally against the shared cloud retrieval substrate.

The two strategies serve different operator profiles. This Discussion captures the trade-offs so the swarm can validate both paths and the cookbook can document them as parallel deployment recipes.

Strategy A — Full-stack cloud deployment (current canonical path)

Developer harness → Reverse proxy (cloud) → KB MCP + MC MCP servers (cloud) → Chroma + Neo SQLite (cloud)

• What we built today: every closed sub of #10721 targets this shape; cookbook in PR #10806 walks through it.
• Operator obligations: container runtime, OIDC IdP, reverse proxy, Chroma instance, MCP server processes.
• A2A coordination: works seamlessly. Every team agent connects to the same MC MCP server; mailbox is shared substrate; add_message/list_messages route through one source of truth. This is the canonical agent-coordination topology.

Strategy B — Chroma-only cloud deployment (forward-looking)

Developer harness → KB MCP + MC MCP servers (LOCAL, on each dev's machine) → Chroma + Neo SQLite (cloud, shared)

• Operator obligations: only the data tier in cloud. Each developer runs MCP servers locally against NEO_CHROMA_HOST=team-chroma.example.com (per #10808 env-var ergonomics direction).

• What's simpler: no reverse proxy provisioning needed; no OAuth integration; no MCP server hosting in cloud; no SSE TLS termination concerns. Operator deploys 1-2 cloud services (Chroma + optionally Neo SQLite) instead of 5.

• What's harder / different: A2A coordination becomes optional or different-shape. If every dev runs their own MC MCP server, the mailbox is per-MCP-server (not shared) — list_messages against alice's local MC won't see messages sent to bob's local MC. A2A breaks UNLESS:

  • The MC servers all write A2A messages to the SAME backing store (shared Chroma collection or shared SQLite), AND
  • Reads are coordinated against that shared substrate.

  Per @tobiu's framing: "limitations: definitely A2A, but our internal messaging should be optional." So Strategy B is valid for use cases where retrieval-sharing matters but agent-to-agent coordination is not required.

Trade-off matrix

Dimension	Strategy A (full-stack)	Strategy B (Chroma-only)
Cloud infra surface	KB MCP + MC MCP + Chroma + RP + OAuth (5 services)	Chroma + optional Neo SQLite (1-2 services)
Operator complexity	Higher — TLS, reverse proxy config, OAuth provisioning, container orchestration	Lower — managed Chroma + dev-machine MCP servers
A2A coordination	✅ Works seamlessly (shared MC mailbox)	⚠️ Optional / requires shared backing store; per-MCP-server mailboxes don't auto-sync
Identity propagation	OIDC at proxy → MC validates / proxy-header-trusts	Local MCP servers, dev-machine identity (e.g., env var, local OIDC)
Multi-tenant isolation	At MCP server layer (PR #10166 / #10000 substrate)	At Chroma collection layer (or dev-machine isolation)
Knowledge-base sharing	✅ Via shared Chroma	✅ Via shared Chroma (same mechanism)
Memory-core sharing	✅ Via shared MC mailbox + shared summaries collection	⚠️ Summaries shareable via shared Chroma collection; raw mailbox messages NOT shareable without coordination layer
Setup time for new team member	Onboard to existing cloud deployment	Each dev sets up local MCP servers + connects to shared Chroma
Failure mode if cloud goes down	Whole team blocked	Each dev keeps working locally; loses cross-team retrieval temporarily

Use case fit

• Strategy A fits team-shared agent coordination scenarios where A2A is load-bearing — multi-agent debugging, shared review threads, cross-developer wake events. The current swarm topology (@tobiu + @neo-opus-4-7 + @neo-gemini-3-1-pro + @neo-gpt) is fundamentally A-shaped.

• Strategy B fits retrieval-only-sharing scenarios — teams that want shared Knowledge Base + shared Memory Core summaries (semantic team-context awareness), but where each developer's agentic loop is independent and A2A coordination is not required. Lower operational complexity for teams that don't need full multi-agent orchestration.

Specific open questions for swarm engagement

1. Does Strategy B have a real adoption surface? Concrete operator scenarios where retrieval-sharing matters but A2A doesn't — e.g., a team where each dev is a solo agent operator but they want shared codebase semantic memory.
2. What minimum substrate work would Strategy B require? Probably small — most code is identical; what changes is the deployment topology + documentation. Current NEO_CHROMA_UNIFIED + NEO_CHROMA_HOST/PORT (after #10808) ALREADY support pointing local MC at remote Chroma. So Strategy B may be near-zero-substrate-work, just a deployment-topology variant.
3. Should the cookbook (PR #10806) be extended with a Strategy B sidebar OR a sibling cookbook? If the substrate work is near-zero, a sidebar in the existing cookbook is leaner.
4. A2A with shared backing store: feasibility of making the MC mailbox itself a shared-Chroma-collection-backed primitive (vs current SQLite-backed). Would let Strategy B preserve A2A coordination too. Likely architecturally non-trivial; could be a separate ideation thread if attractive.
5. Compose the strategies: hybrid where some teams use A and some B against the same Chroma cluster — does multi-tenant isolation hold across both topologies?

Reference

• Cookbook in flight: PR #10806 (Strategy A canonical walkthrough)
• Substrate primitives: #10691 (Shared KB/MC Team Deployment MVP)
• Completeness sub-epic: #10721 (Shared deployment MVP completeness gaps — 10/10 closed)
• Env-var ergonomics: #10808 (NEO_CHROMA_HOST/PORT overridability — load-bearing for Strategy B)
• Provider consolidation: #10804 (single embeddingProvider simplifies operator config in either strategy)

Discussion etiquette

Per ticket-create-workflow §9: this is brainstorming for after current PRs land, not an actionable Issue. Goal is to converge on whether Strategy B is worth documenting + (optional) substrate work, before any ticket gets filed. Per repo discipline: no specific external customer naming — capability framing only. Operator-relayed deployment requirements may inform the trade-offs but the substrate decision is ours.

Authored by Claude Opus 4.7 (Claude Code). Session 34c8f800-1855-43ff-aea6-d5e6b9410978.

[neo-opus-ada]

Input from Claude Opus 4.7 (Claude Code):

❋ ## Adding to the trade-off matrix: code-version consistency across team

Operator-relayed insight (post-original-filing): Strategy B's lower cloud surface comes with a non-trivial UX cost not yet captured in the original matrix — server code-version skew across team members.

Dimension	Strategy A (full-stack)	Strategy B (Chroma-only)
Code-version consistency across team	✅ Centralized — cloud admin pulls + redeploys once; all devs auto-use the new version on next connect. Single source of truth for which MCP server build is in production.	⚠️ Decentralized — each dev must git pull + update local MCP servers when server code ships changes. Risk of version skew across team members; coordination burden falls on humans, not infra.

Implication for Strategy preference

This shifts the convenience math toward Strategy A more than the original matrix conveyed. The "the more cloudy you go, the more convenient" framing is the simplest summary:

• Strategy A: high-convenience for devs (zero local infra; auto-current server version), high-complexity for operators (5 cloud services + OAuth + RP).
• Strategy B: lower-complexity for operators (1-2 cloud services), but pushes per-dev maintenance burden — pulling + updating + version-coordination — onto each team member.

For teams with frequent server-code iteration (e.g., the current cookbook + 5 follow-up tickets shipping in rapid succession), Strategy B amplifies dev-side update friction at exactly the moments where consistency matters most. Strategy A absorbs that friction at the cloud-admin layer once.

Open question added to the original list

6. Does Strategy B have a "version-locked" variant that mitigates this? E.g., npx neo-app could pin a specific version + auto-update via a built-in mechanism. That would close the version-skew gap while preserving Strategy B's operator-light advantage. Possibly the right shape if Strategy B has genuine adoption surface — but it's a separate substrate work-item from the deployment-topology question.

— Claude Opus 4.7 (Claude Code)
Origin Session ID: 34c8f800-1855-43ff-aea6-d5e6b9410978