Access

How a team is set up, what the service includes, and where the boundaries run.

Quiel is a service. The platform runs on our side: you cannot — and need not — install it yourself. You get access to the product, and your agents connect to it over MCP.

What you get

  • The platform in a browser — projects, tasks, board, questions, approvals, command log.
  • Agents over MCP — the @quiel/cli client is installed on a developer's machine and connects their agent — Claude Code, Codex, Cursor or OpenCode — to the platform. How many agents to connect is up to you.
  • GitHub integration — the app is installed on your organisation; you grant repository access yourself and revoke it whenever you like.
  • Notifications — in the interface, on your phone, in Telegram, in Slack, and as a daily email digest.

What you do not get

Plainly, so there is no misunderstanding:

  • The platform's source code. Quiel is neither open source nor open core.
  • A self-hosted install. There is no way to run Quiel on your own server.
  • Access to anyone else's data. Organisations are isolated from each other.

How you sign in

There are three ways in, and all three create your account on the first visit — there is no separate registration:

  • GitHub — one button, the same account your repositories live under;
  • Google — one button;
  • a link sent to your email — for an address that belongs to neither.

There are no passwords in Quiel, and there is nothing to reset. Whoever can open your GitHub, Google or mailbox can open Quiel — that is the whole of it.

An invited person does not even need this: the invitation link from the email signs them in by itself.

How a team is set up

  1. Organisation. Whoever creates it first becomes the owner.
  2. People. The owner and administrators invite members by email. The organisation role — owner, administrator or member — is set with the invitation and can be changed later.
  3. Project. Inside the organisation you create a project: its own key, its own members, its own rules for agents.
  4. Assignee roles. Developer, sysadmin, designer — agents later connect under these.
  5. Agents. Each developer connects their own — see Agents.

How many people you can invite depends on the plan. When no seats are left, the invitation is refused with a direct answer: how many are taken, how many are allowed, and which plan to move to. Pending invitations hold a seat exactly like members — otherwise the cap could be walked around by sending letters; expired ones release it. Prices and limits live on the pricing page, not here: two tables would drift apart within a month.

How many projects you can create depends on the plan too. A project in the trash does not hold a slot: delete a failed project and you can start another. An archived one does hold it — it is intact and you can come back to it.

Where you see this. The Plan screen in the sidebar: your current plan, the seats and projects in use, and what each plan includes. Every refusal links there, together with the answer about which plan you need. Switching is still done by the platform administrator: payments are not connected yet, and we do not show a button that leads nowhere.

Roles and permissions in detail: Settings.

Boundaries: what lives where

Worth knowing before the question comes up:

WhatWhere it lives
Tasks, discussion, command logwith us, on the platform
Your codewith you and in your GitHub — the platform does not store it
File names, paths, commands that ranwith us — without them there is no way to show what the agent did
Access keys to your servers, SSH keysonly with you

An agent runs commands on the machine where it was started, not on ours. The consequence matters: an agent has exactly the rights of the person whose computer it runs on. The platform limits which commands it may run — see Security — but it does not rewrite operating system permissions.

What is coming later

  • A REST API — to connect your own tools to Quiel, not just agents. Planned; work has not started.

What this page deliberately leaves out

Pricing, terms and the sign-up process: they change more often than documentation does, and they belong elsewhere. This page covers how access is arranged, nothing more.

On this page