Xyne Spaces: Juspay's Apache-2.0 Org-OS for Humans and Agents

The problem Xyne Spaces solves: context scattered across Slack, Google Workspace and Microsoft 365

Most organizations already know a great deal. That knowledge sits in Slack threads, Google Workspace documents, Microsoft 365 mail, Jira issues, Confluence pages and call transcripts. The README's framing is that query responses, automation and agents are only as good as the context they can reach, and that this context has to live in one place rather than be reassembled from a dozen tools on every request. Xyne Spaces is the answer to that, and it is aimed at organizations that want both their people and their agents working from the same store.

The audience is narrower than the tagline suggests. This is a monorepo with a backend, a dashboard, a claw gateway, a claw runtime, an OCR server and a Vespa core directory, plus Nix files and four Docker Compose files. Someone evaluating it needs a team that can run Postgres, Redis, BullMQ, GCS-compatible object storage and a search engine. A single developer looking for a chat bot with a vector index is not the target reader.

How the context store and the permission model actually work

Connectors pull in what the organization already knows and normalize it. The README states that everything is normalized, deduplicated, threaded and indexed for hybrid search, and that bulk import from Jira, Confluence and Slack is supported alongside ongoing sync. The same index backs both the search box and an agent's context lookups, so there is one retrieval path rather than one per surface.

Access control is enforced at the data layer rather than in each app. Reads are scoped to the acting user, writes go through the same permission layer, and agents inherit the access of the person invoking them. The README is explicit that there is no privileged bypass. That is a strong claim and it is the architectural decision the whole product rests on: if the enforcement point is real, every app added later gets the same guarantees for free.

The client keeps a live local replica instead of polling, which is how the README explains the real-time behavior of channels, threads, tickets, boards, calls and canvases. The repository layout backs this up with a `vespa-core/` directory for retrieval and `packages/` for shared code, though the truncated README does not describe the wire protocol between dashboard and backend.

The three-tier agent sandbox, and why the split is the security model

Agents in Xyne Spaces read repositories, execute shell commands, call internal APIs and write files. The README treats that as the point and the risk at once. The mitigation is a three-tier split, and the README states the rule directly: the tier that runs untrusted code holds no secrets, and the tier that holds every secret runs no untrusted code.

The gateway tier, built around `claw-auth`, verifies an HMAC-signed webhook from Spaces, resolves the agent and its credentials, dispatches the run, and executes every external tool call itself through `/mcp/call`. It owns Postgres for agents and credentials, Redis and BullMQ for scheduled jobs and run recovery, and GCS for session checkpoints.

The runtime tier, the `xyne-claw` pod, runs the LLM agent loop and path-scoped filesystem tools. It cannot reach a connected system directly. It posts a tool name and parameters back to the gateway with a short-lived HMAC session token and receives only the result. The README's argument is that a compromised run yields no reusable secret because none was ever there.

Shell access is separate again. Anything needing a real shell runs in a Kata Containers QEMU microVM with its own kernel, driven by the gateway through `sandbox-*` control-plane calls. That VM has egress closed, so it is safe by isolation rather than by permission. Setup lives in `apps/xyne-claw/infra/kata/`.

Writes require a human. Read tools run freely, but tools that create a ticket, schedule a call, edit a canvas or send a message as the user post an approve/decline card in the thread and wait. The README frames the distinction as identity rather than danger: acting as the bot is autonomous, acting as the user needs consent. That is a defensible line, but it also means every write path has a human in the loop, which will be a bottleneck for anyone hoping to run unattended automation that changes state.

Installing Xyne Spaces locally with pnpm and Docker Compose

The Quickstart section names the prerequisites: Node.js 22.x, pnpm 10.15.0, and Docker (or OrbStack / Podman) with Compose. There is a `clone-and-setup.sh` at the repository root and a `setup.sh`, though the truncated README does not spell out what they do beyond the name. What the repository does document is a set of pnpm scripts.

The first step is dependency installation and the shared package build, which the `setup` script combines:

pnpm install
pnpm run build:shared

Before starting anything, the repository provides a doctor script. The `doctor:demo` variant exists for a demo configuration, and `doctor:llm` pings the configured LLM provider, which is worth running early because the agent tiers are useless without a reachable model.

pnpm run doctor
pnpm run doctor:llm

Local secrets and environment files are generated by two scripts. The `secrets` script writes local secrets and `env:setup` writes the env files, so run them before the services come up.

pnpm run secrets
pnpm run env:setup

Services start through the local Compose file with three profiles: transcription, egress and search. The `services:stop` script shows the exact shape, including the Podman fallback, which tells you the supported container runtimes without guesswork.

pnpm run services

For a Nix-based path, the `justfile` exposes `just services`, which runs `nix run .#xyne-space-services`, and `just cleanup` to tear down ports and database volumes. The same file has `just backend`, `just dashboard`, `just migrate` and `just assign-admin`, the last of which calls a script with an email argument or falls back to `DEFAULT_ADMIN_EMAIL` from `.env.local`. After that, `just fresh-start` chains cleanup and services and prints the instruction to start backend and dashboard in separate terminals. No port numbers or environment variable names beyond these appear in the repository files, so treat the generated env files as the source of truth.

Where Xyne Spaces is the wrong tool

The operational surface is the first limitation. Running this means Postgres, Redis, BullMQ, a GCS-compatible store, Vespa for hybrid search, and Kata Containers for the shell sandbox. The `services:stop` script alone references three Compose profiles. If your team does not already run container orchestration and a search cluster, the setup cost is real and the README does not claim otherwise.

The second limitation is the human-in-the-loop write path. The README is clear that tools acting as the user wait for an approve/decline click. That is the right default for a system with broad connector access, but it rules out fully autonomous workflows that modify tickets, send messages or edit canvases without someone watching. Any agent product promising hands-off write automation is solving a different problem.

The third is maturity of documentation. The README covers architecture and intent well, but the truncated text does not document upgrade procedures, migration paths between versions, or what happens to in-flight agent runs during a restart. The `CHANGELOG.md` and `API_DOCUMENTATION.md` files exist at the root, so the information may be there, but the README itself does not carry it. The `package.json` shows version 1.317.3, which suggests frequent releases and therefore a real upgrade cadence to keep up with.

Alternatives: Xyne Spaces versus a plain RAG pipeline over your SaaS tools

The obvious comparison is a retrieval-augmented generation pipeline assembled from an ingestion job, a vector database and a chat front end. The difference in approach is where permissions live. A typical RAG stack indexes documents once and filters at query time in application code, which means every new surface has to re-implement the filter correctly. Xyne Spaces puts enforcement in the data layer, so the search box and the agent's context lookup hit the same scoped path. If your organization has strict access boundaries across Slack channels and Confluence spaces, that difference is the whole argument.

The second comparison is agent platforms that give the agent its own credentials. Xyne Spaces deliberately does not. The runtime tier holds no secrets and the gateway executes every external call, so a compromised run cannot exfiltrate a reusable token. The trade-off is that the gateway becomes a single chokepoint for all tool traffic, and the README does not describe its horizontal scaling story.

The third is the bundled apps. Chat, Call, Canvas, Tickets, Customer Support Desk, Agentic Search and Automations ship in the same repository, which means adopting the context layer also means adopting a collaboration surface. If you only want the context store, the repository does not appear to offer a context-only distribution.

Licence, maintenance and what an upgrade costs

The licence is Apache-2.0, declared in both the repository metadata and `package.json`. That permits commercial use, modification and redistribution with the usual notice and patent terms. It does not give any legal advice, and the `LICENSE` file at the root is what governs.

Maintenance status cannot be judged from the repository metadata, because no last push date is given. The repository is not archived, and the version string in `package.json` is 1.317.3, which indicates a long release history. Beyond that, check the commit history before committing to it.

The upgrade cost is the part worth planning for. A monorepo at this version number with a Prisma schema, a Vespa core directory and four Compose files will not upgrade by pulling a tag. The `justfile` shows `prisma db push` against two schemas, a common schema and a backend schema, plus a Zero permissions deploy step. Any upgrade that touches the schema will involve those commands, and the README does not document rollback. The `Dockerfile.ci` and the Makefile's image targets (`xyne-spaces-backend`, `xyne-spaces-runner`, `xyne-spaces-dashboard`, `xyne-spaces-claw`, `xyne-spaces-claw-auth-backend` and others) show how many artifacts a release produces. Treat a version bump as a deployment project, not a dependency update.

Editorial conclusion

Adopt Xyne Spaces if you want your agents and your people reading and writing the same permission-filtered org context, and you are willing to run Postgres, Redis, Vespa and Kata Containers yourself. Do not adopt it if you need a single small service or you cannot operate a microVM-backed sandbox. Verify first that the pnpm doctor script passes on your machine, that your LLM provider is reachable through doctor:llm, and that the connectors you need are listed in the README's connectors section.

Frequently asked questions

Official sources

1. Official README
2. Project repository