UniqueAI Conduct

UniqueAI Conduct is Unique's per-user, sandboxed code-execution platform that runs swappable AI coding agents (Claude Code, Cursor CLI, Codex, PI-Coder) behind a single chat-driven UX. It is designed to be runnable fully air-gapped, with no direct internet access from the sandbox, no secrets inside the sandbox, and every outbound interaction mediated by the Unique API.

This document captures the architecture, security model, and the capabilities shipped to date.

Why UniqueAI Conduct?

UniqueAI Conduct turns a swappable AI coding agent into something a regulated business can actually deploy. It runs anywhere you can run a Kubernetes pod — on-prem, in your own cloud, or fully air-gapped — with strict per-user isolation, no dependency on an external SaaS coding-agent provider, and no requirement that the work happens on a user’s machine.

The short version. A “co-work”, spun up per user, running the AI coding agent Harnesss of your choice, fully inside your environment — with the distribution, skill organisation, governance, and security that a regulated business needs.

What it gives you

• Deploy where your data lives. The full runtime can run on-prem, in your own cloud, or fully air-gapped if your governance demands it. Nothing forces you to ship source code, context, files, or prompts out to a third-party SaaS coding-agent provider.

• No user machine required. The harness runs in the cloud-side sandbox, not on the user's machine. There is nothing to install. Users get the agent experience from any browser, on any device, on any network — the heavy lifting always happens in the managed sandbox.

• Per-user isolation by construction. Each user gets their own sandbox pod. Nothing is shared across users — not state, not skills, not files, not memory, not credentials.

• Embeddable as a component. UniqueAI Conduct can be installed as one component inside your platform and connected to your own frontend. You do not have to adopt the Unique chat UI to benefit from the runtime, swappable harnesses, skills cascade, sandbox, CLIs, MCP integration, and checkpointing.

• Choice, not lock-in. It is not yet clear which AI coding agent will “win”. We integrate every harness with meaningful traction (Claude Code, Codex, Cursor, PI-Coder) behind the same product surface, and more are on the way. Customers can swap the harness per space without changing the product, the skills, or the integrations.

• Built for business users, not only developers. A non-developer in chat gets the same cloud-co-worker experience as a power user. Skills, rich file previews, scheduled tasks, and user memory are designed for everyday business use — the technical complexity stays inside the sandbox.

• Governed by default. Allow-listed egress, DLP-checked web search, no secrets in the pod, Knowledge Base access inheriting the user's permissions, audit-grade logs — these are properties of the platform, not features you have to assemble yourself.

The mental model: a private cloud co-worker

Think of UniqueAI Conduct as a personal computer that is spun up on demand for one user, with the AI coding agent of their choice already installed, running fully managed in your environment.

• It can run long jobs and scheduled jobs without keeping the user's laptop online.

• It can read, write, transform, and move files with the full flexibility of a local developer environment — but inside a sandbox, not on the user's machine.

• It can talk to your systems (SharePoint, Outlook, your MCP servers, your Knowledge Base, your search proxy) through governed CLIs that respect your DLP, allow-list, and access-control rules.

• It drops produced files straight back into the chat (or into your frontend) as rich previews, and remembers what it did via checkpoints so the next session continues seamlessly.

You keep the distribution, the skill organisation, the governance, and the security controls; the user keeps the experience of working with a capable co-worker who never sleeps.

1. Architecture diagram

2. High-level overview

The platform separates the conversational surface (chat) from the execution surface (sandbox pod), so that arbitrary, untrusted AI-generated code can run with full filesystem and tooling flexibility — without ever needing direct internet access, secrets, or shared state between users.

• Frontend (Next-Chat) — user-facing chat. Sends a normal chat message that invokes the agent and carries the agent config / event, including the list of MCP servers configured for the space. The frontend is pluggable — UniqueAI Conduct can also be wired to your own frontend instead.

• Backend (Node-Chat) — receives streaming thinking / messages from the sandbox and renders them inline in the chat UI (thinking steps, tool calls, setup status, interactive checklists, file previews).

• Firewall (secret injection boundary) — the outer security envelope. Secrets are injected at this layer; the sandbox itself never holds them.

• Sandbox Pod (per-user, isolated) — a Kubernetes pod dedicated to a single user. No direct internet access in or out, no secrets, can run fully air-gapped. Reused across that user's chats with workspace isolation per chat.

• Knowledge Base — the durable, governed data plane. Holds the skills directory, checkpoint zips, in-chat uploads, files discovered by the agent, and the results produced by the agent.

• Unique API — the single egress for the sandbox. All outbound work (Knowleage Base navigation/search, web search, MCP calls) is funneled through Unique CLIs that talk to the Unique API.

Isolation-Maxing: One pod per user, one workspace per chat. Sandboxes are never shared between users. A given user's pod is reused across their chats for speed, but each chat has its own workspace so different conversations cannot leak state into each other.

3. Swappable harness strategy

Inside the sandbox, the AI coding agent is a pluggable harness. The same product UX sits in front of any of four interchangeable backends:

All four are wired behind the same orchestration layer (skills, MCP connections, CLIs, streaming, checkpointing), so a space can be configured to use a different harness without changing the chat experience.

Inside the sandbox, the chosen harness has full read/write access on the sandbox filesystem: it can write files, run code, inspect downloaded data, run long jobs, run scheduled jobs, and move files around. It does not have ambient internet access — every outside interaction is mediated by the Unique CLIs described below.

Why integrate them all? The AI coding-agent market has not settled. Rather than betting on one provider, UniqueAI Conduct treats the harness as a configuration choice, integrates every harness with meaningful traction, and adds new ones as they emerge. Customers get choice and avoid lock-in; the product UX stays the same.

4. Sandbox pod — security model

The sandbox is the strong isolation boundary of the system.

• Per-user pod on the Unique Kubernetes cluster. One long-lived pod per user, reused across their chats.

• Workspace isolation per chat — different chats inside the same user's pod cannot see each other's working trees.

• No direct internet — outbound network is locked to a strict allow-list and routed through Unique's managed gateway. There is no ambient outbound DNS, HTTP, or socket access.

• No secrets in the pod — credentials are injected at the firewall layer; the harness never sees them.

• Can run fully air-gapped — the sandbox does not require internet to operate. Outbound access is opt-in per capability (e.g. web search) and per space. This is what makes on-prem and regulated deployments possible.

• Hardening against token forgery, host-header spoofing, and unauthorized header passthrough on the gateway path.

Because the sandbox is per-user and stateless across users, “chaos” in one user's environment cannot affect another user's data, skills, or files.

5. Agent invocation flow

1. The user sends a chat message in Next-Chat (or your own frontend).

2. The platform invokes the agent. The invocation event carries the standard agent config plus the list of MCP servers configured for the space.

3. The user's sandbox pod is started (or reused) behind the firewall.

4. The pod's Python orchestrator assembles MCP connections from the provided MCP server list.

5. The orchestrator downloads skills, in-chat uploaded files, and (if present) the previous checkpoint zip from the Knowledge Base into the sandbox filesystem.

6. The selected harness (Claude Code / Codex / Cursor / PI-Coder) is started inside the sandbox with access to the assembled context.

7. The harness executes the user instruction, streaming thinking, tool calls, and messages back to Node-Chat — and on to the chat UI — in real time.

8. Produced files are uploaded back to the chat (and optionally to the Knowledge Base). The full working state is packaged into a new checkpoint zip and stored for the next turn.

6. Skills system

Skills are versioned instruction packages that guide the harness on how to perform specific tasks. They are loaded into the sandbox at startup from the Knowledge Base skills directory.

6.1 Cascading skill layers

Skills are organized in a cascade, from broadest to most specific:

More specific layers shadow more general ones at load time.

6.2 Promotion model

When a user saves a new skill, it is written to their individual folder. Admins (with the appropriate access control) can promote a skill into the team or company folder, given the correct access rights of course. This prevents accidental pollution of shared folders while still allowing a clean path from “works for me” to “works for the team” to “works for the company”.

6.3 Versioning & isolated discovery

• Skills are versioned in the Knowledge Base; the sandbox loads a coherent snapshot at startup.

• Skill discovery is isolated per user: the listing the harness sees at startup is the cascade resolved for the invoking user, not a global pool.

• When the harness produces a new skill during execution, the orchestrator places it in the correct folder automatically (defaulting to the user's individual folder).

7. CLI-first tooling (why CLIs and not in-context MCP tools)

The orchestrator exposes platform capabilities to the harness as command-line tools, not as tools wired into the model's tool-calling schema:

Why CLIs instead of in-context MCP tools?

• Context budget. Listing every MCP tool with its full schema in the model's context blows up the context window. CLIs are discovered on demand, so they don't loot the context.

• File-format interop. CLIs work on files on the sandbox filesystem — the harness can attach a file to an Outlook email, upload it to SharePoint, transform formats, etc., by piping files through MCPs rather than serialising blobs into JSON tool calls.

• Scalability. Adding a new MCP becomes “ship another CLI”, not “extend the model's tool list and re-prompt every agent”.

• Composability. The harness can compose CLIs (pipes, scripts, loops) the way it composes any other shell tool — something LLMs are exceptionally good at because of their training data.

8. Knowledge base integration

The Knowledge Base is the durable, access-controlled side of every sandbox.

8.1 Inputs into the sandbox

• Skills directory — downloaded into the sandbox at startup (cascade resolved per user).

• In-chat uploaded files — every file the user attached in this chat is materialised into the sandbox filesystem, so the harness can read, transform, and compute over them as if they were local.

• Checkpoint zip (if any) — the saved state from a prior turn in the same chat is unpacked into a working code directory.

• On-demand Knowledge Base files — via the Unique CLI, the harness can search and pull additional files out of the Knowledge Base into the sandbox.

8.2 Search style

The harness can navigate the Knowledge Base like a Linux filesystem (ls / cd) and search using both grep-style keyword search and vector search. LLMs are extremely strong at navigating shell-like file hierarchies, which is what makes this style of access more reliable than a single “search” tool call.

8.3 Outputs back to the Knowledge Base

Produced artefacts can be uploaded into any Knowledge Base location the user has access to:

• Files are written back to the Knowledge Base through the Unique CLI.

• New skills are written into the correct cascade folder automatically.

• Knowledge Base writes inherit the invoking user's / agent's access settings — the harness can never write somewhere the user could not.

9. Chat file handling

9.1 Inbound — chat uploads

Files uploaded in the chat are mirrored into the sandbox before the harness runs, with progressive ingestion polling and faster “ready” detection so the harness can start as soon as the files are available.

9.2 Outbound — produced files

When the harness produces a file, the orchestrator uploads it back into the chat. In the chat UI:

• Files appear as rich preview cards rather than forced downloads.

• Clicking a file opens it in a side panel.

• Files auto-refresh in the side panel as the harness re-generates them during a long-running task.

Supported preview formats in the side panel:

• PDF

• Markdown (rendered, not raw)

• Word, PowerPoint, Excel (via LibreOffice conversion)

• Plain text and log files

• Generated images (with the source code that produced them)

• Interactive HTML visualisations (larger size limit, longer cache lifetime, automatic retries)

10. Web search (controlled egress)

Web search is the main controlled escape hatch from the sandbox to the public internet.

• Routed through the search-proxy CLI, which goes through the standard web-search + DLP + allow-list pipeline.

• The harness can use multiple providers — Google, Brave, Vertex AI, and other configured crawlers — depending on what is enabled for the space.

• The agent can elicit consent from the user mid-execution before sending sensitive data outbound, e.g. “Am I allowed to send this snippet to Google to look up X?”

• Web search and web crawl are also exposed as official platform APIs, consumable from assistants-core, node-chat, and unique-api, with SDK and CLI access so any team can integrate.

11. MCP integration

• The set of MCP servers available to a chat is configured at the space level and arrives with the agent invocation event.

• The Python orchestrator assembles MCP connections at sandbox startup.

• Those MCPs are exposed to the harness via the MCP Client CLI (see §7), not via the model's native tool schema.

• This means MCPs can reach full feature parity with files — e.g. taking a sandbox file and attaching it to an Outlook email, uploading it to SharePoint, or moving it between formats — without serialising file content into tool-call JSON.

12. Execution streaming

All harness output is streamed in real time to the chat UI:

13. Checkpointing & resumption

After each run, the orchestrator checkpoints the sandbox state and ships it back to the Knowledge Base and the chat.

• The full working tree (code, intermediate outputs, configuration) is packaged into a zip.

• The zip is uploaded into the chat (so it is visible to the user) and into the Knowledge Base (so it can be restored).

• On the next invocation in the same chat, the checkpoint is unpacked into the sandbox and the harness picks up exactly where it left off.

• The user can opt to start from scratch, in which case the checkpoint is not restored.

• Checkpoints can also be packaged up into skills if a workflow turns out to be reusable.

14. Spaces & configuration

Each space is a self-contained configuration of the harness:

Because every space carries its own combination of harness + skills + MCPs, a single tenant can run, for example, one space with Claude Code on a SharePoint MCP set, and another with Codex on a different set — without any interference between them.

15. Security & hardening

• Per-user sandbox on Kubernetes; never shared between users.

• Allow-listed egress via the managed gateway; no ambient internet access.

• No secrets in the pod; secrets are injected at the firewall layer.

• Prompt-injection guardrails on input that enters the harness's prompt context.

• PII redaction in logs across the sandbox + gateway pipeline.

• Automatic context compaction for long conversations to keep the harness within budget without losing intent.

• Isolated skill discovery per user; cascade is resolved per invocation.

• Token forgery, host-header spoofing, and unauthorized header passthrough are explicitly hardened against on the gateway.

16. User memory

The platform now ships a per-user memory layer that lives alongside the sandbox runtime.

• The assistant remembers each user across conversations — preferences, work context, expertise, ongoing projects.

• Memory lives in the user's own Knowledge Base area, private and editable by the user.

• It is injected at the start of each turn (so the harness sees the user's context as part of its initial setup).

• It is consolidated automatically after each conversation, so memory grows without manual curation.

17. Scheduled / recurring tasks

Because the sandbox is decoupled from the chat session, the harness can run on a schedule rather than only when the user types.

• Cron-based schedules (e.g. “every morning at 8am”).

• Timezone auto-detected from the browser when the schedule is created.

• Full CRUD over the API.

• Dedicated background runner in production with structured execution logs and leak-proof error handling.

18. Data flow summary

20. Glossary