Using QUYSS

An agent is one Claude Code instance QUYSS drives on your behalf. The web app never holds an Anthropic API key — a runner on your own machine launches each agent against your local Claude login (see Setup). The agent's token is its identity: everything it does over the API is scoped to that one agent.

Create agents from the Agents screen, or while building a project. For each agent you can set:

• Profile — display name, role, description, tags, avatar and banner.
• Model — the provider/model it runs on; the runner launches the matching backend.
• Runnable — which downloaded runnable (and so which machine) hosts it.
• Config — its CLAUDE.md, context files, memory, and assigned skills/MCP servers/hooks.

Agents can be archived (soft-deleted) and restored. An agent can belong to a project, an organization, or no one (a projectless agent you own directly).

Each agent picks a provider. claude runs on your host's own Claude subscription through the Claude Code CLI — no inference key leaves the machine. API providers (deepseek, openrouter, claude_api) run on a key stored locally on the runner host, never on the server (see CLI for set-key). A provider only becomes selectable for launch once the host actually has it set up.

A project is a shared fleet. Members join by invite or join link, and a per-project capability matrix decides who can manage members, edit permissions, manage the config library, manage the subscription, or delete the project. A project also has its own conversations and config library.

An organization owns agents and projects at a level above any one person, with its own capability matrix and member roles. Org-owned agents can be lent out as scoped, revocable grants. Use a project when a handful of people share a fleet; use an org when ownership should outlive individual members.

Each agent card shows a live status dot derived from the Claude Code hooks the runner forwards: online and working, idle, needs you (an open question), or offline. The card also surfaces what the agent is currently working on and its agent-authored task plan. A runner on a memory-constrained host raises a per-agent warning rather than thrashing silently.

Send a message to an agent from its card or detail view. Messages are a durable outbox: each one shows a delivery status (queued → delivering → delivered → seen), can carry an optional time-to-live, and can be cancelled while still queued. When a message is waiting, the runner spends a Claude turn to handle it.

Agents can ask you a question back; the agent blocks until you answer in the UI (or a timeout elapses). Open questions and message-status changes fan out as notifications to everyone subscribed.

Each agent's turns are captured into an archived conversation history, viewable per agent and across a project, so you can read back what an agent did and said over time.

An agent thread carries a right-hand rail. A render viewport paints whatever the agent draws — markdown, code, images, SVG, PDFs, audio, embeds, 3D models, and graphs — by fencing a quyss block; the newest render opens automatically, and earlier ones reopen from a chip on their message. A read-only context-files view lists the files the agent currently has in context, distinguishing those it has fully read from those it only knows by name. Quick commands in the composer send a canonical message to the agent in one click, separate from the command menu that only inserts a directive.

Skills, MCP servers, hooks, and CLAUDE.md live in a versioned library scoped to your account, a project, or an organization. Assign library items to agents (optionally pinned to a version); an agent's assembled configuration resolves from those assignments plus its own document. The agent's config document is itself versioned, with optimistic locking, so concurrent edits surface a conflict instead of silently overwriting.