Overview

Platform docs

What the AIQuity platform is made of, for a developer: Chakras, the CLI, agent tooling and MCP. Public developer access is not open yet, so these pages describe what exists and how it works rather than how to sign up.

Build paths

Key concepts

Chakra

A self-contained React app bundled as one script that implements mount, unmount and getInfo.

Host

The AIQuity web app. It owns the registry, the loader, security and the context a Chakra receives.

Registry

Knows which Chakras exist, where their bundles live and what they are permitted to access. Built-in entries are static; user Chakras are fetched per user.

Loader

Fetches a bundle by URL with retry, integrity checks and a CSP nonce, then calls mount.

Bridge and context

The single object a Chakra receives: user, route, data adapters, MCP tools, events, theme.

MCP tool

A tool exposed over the Model Context Protocol. Connectors bring outside tools in; Chakras expose their own into the same catalogue.

Chakras

The contract

esbuild chakra-entry.ts --bundle --format=iife --global-name=MyChakra --outfile=public/main.js --minify

1import { createRoot, type Root } from 'react-dom/client';2import MainApp from './components/MainApp';3 4export type ChakraApp = {5  name: string;6  version: string;7  mount: (container: HTMLElement, props?: any) => void;8  unmount: (container: HTMLElement) => void;9  getInfo: () => { name: string; version: string; description?: string };10};11 12let root: Root | null = null;13const app: ChakraApp = {14  name: 'My Chakra', version: '1.0.0',15  mount(container, props = {}) {16    root = createRoot(container);17    root.render(<MainApp {...props} />);18  },19  unmount() { root?.unmount(); root = null; },20  getInfo() { return { name: 'My Chakra', version: '1.0.0' }; },21};22export default app;

What the host provides

Once mounted, a Chakra has full platform access as if it were a native feature. The host assembles one context object and hands it over on mount.

User and route

Who is signed in, which space and route the Chakra was opened in.

Data adapters

Read and write the user’s goals, todos and documents through the host, never through a second login.

MCP tools

The same tool catalogue the companion uses, scoped to the user.

Events and RPC

A shared bus so Chakras can react to each other and to the host.

Theme

Light and dark follow the host; no separate styling contract.

Build and bundle

A Chakra is developed as an ordinary React project with its own dev server, then bundled as a single IIFE script that exposes the contract on a global name. Built-in Chakras ship with the product from a static registry; user Chakras are created in Chakras Pro and served from per-user storage.

Registry and loader

The registry is the list of Chakras the host will load: id, bundle URL, permissions and trust level. Built-in Chakras are registered statically and served from the app or a CDN; user Chakras are registered dynamically per user and served from backend bundle storage. Bundle URLs are configured per environment, so a Chakra can be built, deployed and loaded independently of the host.

Security and trust

Trust levels

trusted, partner, untrusted. Built-in Chakras are trusted; a lower trust level narrows what the context exposes and, in future, sandboxes the mount.

Integrity

In production a cross-origin bundle must carry an SRI integrity hash or the loader refuses it. Same-origin bundles are trusted by origin.

Content security

Scripts load with a CSP nonce; the loader retries transient failures and fails closed on a hash mismatch.

Data adapters

Three adapters come with the context: goals, todos and documents. Each talks to the platform through the host with the signed-in user’s session, so a Chakra never stores a token and never asks for a second login. Create, read, update and delete go through the same paths the web app uses.

Events and RPC

The host runs an event bus and an RPC registry. A Chakra subscribes to events (a todo changed, a goal completed, the theme switched) and can call registered host services or other Chakras with a request and a response. This is how two Chakras on one canvas stay in step without knowing about each other.

Embed in a canvas

A Chakra can be placed in a canvas as a card or mounted live inside it, with its own size and views. The registry knows which Chakras exist and what they may access; the loader fetches the script with integrity checks; the security layer decides trust.

Chakras Pro

Chakras Pro is the in-browser workspace for building a Chakra: a code editor, a file tree, git, and a live preview of the mounted result. Creating a project scaffolds the backend, the frontend, the bundle and an agent seed in one step, and can bind a brand kit. The integrated terminal and search are still being finished.

Built-in Chakras

Built by the AIQuity team, registered statically, trusted. A few of the current set:

• Timer Plus

  Focused work sessions with a timer that lives in the canvas.

• Focus Flow

  A flow for getting into and staying in deep work.

• Restore Agency

  A structured reset when a day has come off its rails.

• Narrative Building

  Turn events into a story you can act on.

• Idea Vault

  Capture and revisit ideas without losing them to chat.

Chakra tools in MCP

A Chakra can register its own tools. They appear in the same MCP catalogue the companion uses, scoped to the user, so an agent can act on a Chakra’s data the way it acts on any other tool.

CLI

The AIQuity platform, rendered as a local, scriptable, offline-first control plane.

A client and a control plane at once: a faithful local window onto spaces, todos, goals and canvas, and a place to dispatch work that costs something, such as AI engineering tasks, offline caches that must reconcile, and syncs. A human always holds the trigger.

Auth and profiles

Sign in opens the browser, completes OAuth, and returns to a local callback on the machine. The token is stored encrypted (AES-256-GCM) and refreshed from the stored session. Several profiles can live side by side and be switched with one command.

aiquity auth login      # opens the browser, returns to a local callback
aiquity auth profiles   # list saved profiles
aiquity auth switch     # change the active profile

Offline cache

The cache holds a space’s content on disk, per space, across 25 content types. Files are deduplicated by content hash, conflicts are detected by etag and resolved with a three-way merge, and every write is validated against a schema. Work offline; push when back.

aiquity cache init --space <spaceId> --name "My Space"
aiquity cache pull --space <spaceId>
# work offline, edit content
aiquity cache push --space <spaceId>
aiquity cache status --space <spaceId>

Jobs and workers

The job manager is a daemon that dispatches coding tasks to AI workers (Claude, Copilot, Codex, DevFusion) from one interface, with a priority queue, device registration and heartbeat, and a local HTTP server the desktop app talks to.

Sync

Sync reconciles a git checkout with the canvas: initialise, pull, push, plus custom sync of commands, skills and rules to the tools you use. It is how the platform becomes something you can pipe, cron and commit.

Command groups

The CLI installs from a private registry today; a public install is not available.

Agents

Available to signed-in users as the product opens in stages.

MCP

Inside Juggernaut, a connector picker lists MCP servers by category: productivity, automation, development, e-commerce, social media, media, database, education, smart home, health. Pick one (Notion, Confluence, Jira, Linear, Asana and thirty more are listed), authorise it, and the companion can call its tools in conversation. Chakras expose their own tools into the same catalogue.

Status of every surface

Start reading

• The Chakra contract›
• Security and trust›
• The CLI as a control plane›
• Pattern Studio and registries›
• Status of every surface›