Xyne Spaces

Context is the foundation. Every conversation, decision, ticket, document, and call adds to your organization’s understanding of what it knows, how it works, and where it’s going. Query responses, automation, and agents are only as good as the context they can reach.

That context has to live in one place — normalized, indexed, and served through one interface — rather than pieced together from a dozen tools every time a person or agent needs it.

The apps build the context as work happens. They are agent-first and collaboration-first: real-time and shared by default, with people and agents working together in the same threads, tickets, and canvases.

Accessing context — through search or agents — must respect the permissions of the underlying work, so access control is enforced at the data layer:

• Reads respect user permissions. Queries are scoped to the acting user, returning only the context they’re allowed to access.
• Writes are enforced centrally. Mutations go through the same permission layer, so access rules apply consistently across apps and features.
• Agents inherit the user’s access. Agents act as the person invoking them, so they can only search, read, and act on context that person can access. There is no privileged bypass.

Xyne Spaces breaks down into four stacks:

• Context — the store at the center: connectors bring in what the org knows, and permission-aware APIs serve it back.
• Collaboration — real-time work with your team: Chat, Call, Canvas.
• Agentic workflows — Claw agents, Agentic Search and Automations, all working from the same context.
• Org productivity apps — Customer Support Desk and Tickets for the day-to-day running of the org.

Agents here run real code — they read repositories, execute shell commands, call internal APIs and write files. That is the point, and it is also the risk. So the agent plane is split across three tiers, and the split is the security model:

the tier that runs untrusted code holds no secrets, and the tier that holds every secret runs no untrusted code.

The gateway holds everything. claw-auth verifies the HMAC-signed webhook from Spaces, resolves the agent and its credentials, dispatches the run, and then executes every external tool call itself through /mcp/call. It also owns the backing stores — Postgres for agents and credentials, Redis and BullMQ for scheduled jobs and run recovery, GCS for session checkpoints.

The runtime has no secrets and no shell. The xyne-claw pod runs the LLM agent loop and a set of 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. A compromised run yields no reusable secret, because none was ever there.

Bash lives behind a hypervisor. Anything that needs 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 — no network, no gateway credentials — so it is safe by isolation rather than by permission. Setup lives in apps/xyne-claw/infra/kata/.

Writes need a human. Read tools run freely. Tools that create a ticket, schedule a call, edit a canvas or send a message as you post an approve/decline card in the thread and wait for a click. The distinction is identity, not danger: acting as the bot is autonomous, acting as you needs your consent.

Prerequisites — Node.js 22.x, pnpm 10.15.0, and Docker (or OrbStack / Podman) with Compose. Details in Prerequisites — or, for a machine with nothing installed yet, follow Local Setup end to end.

git clone https://github.com/juspay/xyne-spaces.git
cd xyne-spaces
pnpm run up

Once it finishes:

Sign in locally with admin@xyne.ai / xynelocal@123.

Stuck? → Troubleshooting. Configuring model providers? → AI providers.

Context arrives two ways. Live sync is continuous — webhooks in, scheduled pulls out. Migration is a one-time bulk import of history. Both end in the same place: normalized records in PostgreSQL, indexed into Vespa, behind the same ACLs as everything else.

The pipeline is platform-agnostic: each connector is an adapter — resolve, authenticate, transform, sync — and everything after it is shared. Adding a platform means writing an adapter, not touching the pipeline. Credentials are stored encrypted and decrypted only at the moment of use.

→ Adapter contract: apps/backend/src/integrations/README.md

Eight apps, adopted independently. All of them read and write through the same context store and permission model.

Connectors bring context in. MCP tools let an agent act on an external system — different system, different code path, configured per user rather than per workspace.

Claw Auth brokers 50+ MCP integrations. A representative slice:

A connector only appears for a user once they have connected it, so an agent's available tools are a function of that user's own integrations — and tool sets are scoped per agent rather than handing every run the full catalogue.

📹 Walkthroughs are being recorded. Links land here as they are published.

xyne-spaces/
├── apps/
│   ├── backend/            REST API, Zero sync server, workers, integrations
│   ├── dashboard/          Web client — React 19 + Vite + Zero
│   ├── dashboard-external/ Externally embeddable dashboard
│   ├── electron/           Desktop wrapper
│   ├── public-web/         Public marketing site
│   ├── site/               Documentation site
│   ├── xyne-claw/          Agent runtime — the sandbox
│   └── xyne-claw-auth/     Identity, credential store, MCP gateway
├── packages/
│   ├── shared/             Zero schema, query ACLs, shared types
│   ├── framework/          Agentic framework library
│   ├── icons/              Icon set
│   └── xyne-claw-mcp/      MCP server + plugin for Xyne Claw agents
├── vespa-core/             Search schemas and deployment
├── docker/                 Container configuration
├── docs/                   Setup documentation
├── scripts/                Bootstrap, seeding and validation scripts
└── tools/                  E2E automation and analysis tooling

Read CONTRIBUTING.md first — it covers what the tooling enforces, so a first pull request does not bounce on something mechanical. In short: branches are fix/* or feature/*, commits are <type>: <TICKET-ID> <subject>, and dependencies are added with a --filter.

For anything larger than a small fix, open an issue first so the approach can be agreed before it is written. Participation is governed by our Code of Conduct.

• Bug — open a bug report with what you ran, what happened, and the output.
• Feature — open a feature request describing the problem before the solution.

Licensed under the Apache License 2.0.