Collaboration

How an agent asks a human, how a human answers, and what happens to the task meanwhile.

The main difference between Quiel and "launch it and hope": the agent does not make things up. When it lacks a decision, it asks and stops.

Questions from an agent

An agent asks a question when it runs into something it cannot settle by itself: which provider to choose, whether to change the database schema, what to do about a contradiction in the requirements.

A question can be blocking — then the task moves to the "Waiting for a human" status and stands there until you answer. That is not a breakage but an honest state: you can see that the work is not moving, and why.

Who gets the question. The agent addresses it either to a specific member or to a role — "the project manager", say. Whoever it is addressed to can answer, and so can the organisation's owner and administrator.

Where to answer. In two places, and it is the same question:

on the project's "Questions" screen — every question at once, with a "mine" filter;
on the "Questions" tab inside the task itself — right where the rest of the context is.

If a task has an open blocking question, that is stated in its card, above everything else.

Answer options. The agent may offer options — "Twilio / SMSC.ru / a local gateway". Then the answer is a button click rather than typed text. You can also answer in your own words, or close the question without an answer if it no longer applies.

Files in an answer. You can attach files to your answer — a screenshot, a log, an export. The agent can ask for them in advance: then the answer form says "The agent asks you to attach a file to the answer" and the file picker is open from the start. It is a request, not a requirement — answering without files is always allowed.

The agent receives attached files together with the answer, as names and short-lived links listed right in the answer text. There is no way back: an agent does not attach files. The client never sends the contents of your project files to the server, and asking a human is the only way it can get them.

Once you answer, the task goes back into work and the agent continues with what you said.

What if the answer comes too late

The agent that asked may have disappeared by then — the laptop was closed, the session ended. Then the task goes not "into work" but back into the queue: the next free agent picks it up, already carrying your answer in its context.

Approving dangerous commands

A separate matter from questions. A question is "I don't know, you decide"; an approval is "I know, but I won't without permission".

When an agent is about to run a command that the project rules consider dangerous, it is not executed. Instead an approval request is created, and a human decides: allow or decline.

Requests are visible on the project's "Approvals" screen and on a tab inside the task. A request has a deadline: if nobody answers, it expires — and by default that counts as a refusal, because that is the safer way round.

Which commands count as dangerous is set by the trust profile.

Notifications

So questions and approvals don't sit unnoticed, there are notifications:

in the platform itself — the notification centre in the top bar;
in Telegram — if you have linked a chat;
in Slack — a project channel for the whole team, and direct messages for what is addressed to you;
by email — for what concerns you personally: a task assigned to you, an agent waiting for your answer;
as a device notification — even when the tab is closed;
in a daily digest email — what happened over the day.

Each channel is turned on separately, in your profile. Device notifications work wherever you have allowed them in your browser.

On iPhone, notifications arrive only in the installed app. They do not work in Safari — an Apple restriction with no way around it. Installing the app is described below.

What is in the daily summary

The summary arrives once a day and answers two different questions.

What is waiting for you — questions addressed to you or to your role; approvals for your agents; tasks assigned to you and not yet started. This is what is standing still waiting for your action.

What happened in the project — this section goes to organisation owners and admins and to anyone holding the manager role in the project: the same circle that accepts work. What was delivered over the day, with pull request links; what is waiting for acceptance; what is stuck — blocked or waiting for a human; how many tasks are queued per role and how many agents are sitting idle.

A developer does not get the project section: they already see their own tasks, and a list of other people's delivered work is noise.

An empty summary is not sent. If nothing is addressed to you and nothing happened in the project, there is no message.

What is not in the summary, and why

"Which agents were idle during the day" cannot be computed: the platform does not keep a history of agent occupancy, only its state right now. So it reports what is known for certain — how many agents are free at the moment of sending. Inventing a nicer number would have been easier than admitting there isn't one.

Project costs

Each task's card shows what it cost: how long it took and how many tokens it consumed. The "Costs" section answers the question you cannot assemble from cards — where the resource goes.

Over a day, a week or a month: how many live tokens were spent, the most expensive tasks with their working time, and a breakdown by agent.

Live tokens means "input + output". Cache reads are shown next to them and smaller, not because they do not matter: they are counted afresh on every request and exceed live tokens by hundreds of times. Add them together and the number starts describing context length rather than work, and the expensive task gets lost behind the verbose one.

Money is shown to some, and not always

Tokens turn into money only when it is known who pays. The billing mode is a property of the agent, not of the organisation: one team can hold both subscribers and people working on an API key, and each is metered by their own. The client works it out itself and reports one word; you can correct it in the agent panel.

For an agent on a subscription the marginal cost of a task is zero — no bill is issued for its work, and the "Money" column holds a dash. That is an answer, not an omission.

To make money appear for those who are billed, set token rates in the organisation settings: currency, multiplier and per-million prices by model. While there are no rates, spend is shown in tokens only — and a team entirely on a subscription has nothing to fill in there.

The "isn't this too expensive" comparison works either way: a task that cost noticeably more than usual for this project says so right in its card.

What you see on the task itself

Three numbers in the agent block: "input + output", the cache separately, and working time. Next to them, money — when there is something to compute it from: rates are set and the spend came from a metered agent. No rates means no sum, not a zero. If rates cover only some models, what was computed is shown and the rest is stated out loud, otherwise the total would read as complete.

A per-attempt breakdown appears once the task has been sent back from review at least once: "Attempt 1 — 220,000, Attempt 2 — 110,000". A single total does not answer the question people open the card for: did the rework cost more than the original work or less. The attempt boundaries come from the status feed — there is no second store of the same fact.

By task type

On the Costs screen, next to the per-agent split, sits a split by type: what bugs cost against features. It counts every task in the period, not the ten most expensive: forty cheap bugs never reach that list, and a split computed from the top would say we barely have any bugs.

Task budget

The project settings take a task budget in live tokens. Empty means no budget, and that is the default: a number the platform picked by itself would mark ordinary work as an overrun.

A warning, not a ceiling

The platform does not stop the work. Stopping at night would mean idling until morning, and an overrun is a reason to look, not an emergency.

When the spend passes the budget the card gets a mark, the project managers get a notification — once, not on every agent turn — and the agent itself hears about it on delivery and is asked to say in the report where the spend went: the task turned out larger than it looked, or it got stuck going in circles.

The bot is linked to your account: you get a code in the platform and send it to the bot.

Written up, but not yet verified in the field

Chat linking and button answers are built and covered by tests, and on 10 September 2026 a bug that stopped linking from working at all was fixed. But the full scenario — agent asks, Telegram notifies, you answer with a button, work continues — has not yet been walked through by a human. If anything differs from this description, the system is right.

What the bot can do:

send notifications about questions and approvals addressed to you;
answer a question with buttons straight from the chat, if the agent offered options;
allow and decline dangerous commands with buttons.

An answer from Telegram is the same answer as one in the interface: it lands in the same task and is visible to everyone with access.

Slack

Slack is the only shared surface in the product: every other channel is personal, addressed to one person. Here a project has a channel where the team sees the agents' work without opening the dashboard.

Written up, but not yet verified in the field

Installing the app, linking a person with /quiel link and choosing a channel have been done on a real workspace. The first message arriving in a channel has not been observed yet — the integration is marked beta until it is.

Two roads, and they are deliberately different:

A project channel — statuses, questions, approvals and opened pull requests, as short lines with a link to the task. Set the channel in the project settings; a project without one works on direct messages alone, and that is a supported mode, not a breakage.
Direct messages — what is addressed to you personally: an agent's question, a task assigned to you, a dangerous command waiting for your approval. To receive them, link your Slack account: get a code in Integrations and send /quiel link CODE to the bot.

The text of a dangerous command never goes to a channel — only the fact that one is waiting, and later who decided. The reason is not tidiness: an approval records who decided, and a button in a shared channel would mean anyone who wandered in could decide.

The app on your computer and phone

You can install Quiel: it opens in its own window, without an address bar or tabs, and sits next to your other apps.

On a computer — in Chrome or Edge, click the install icon at the right of the address bar, or choose “Install Quiel” from the browser menu.

On Android — browser menu, “Install app”.

On iPhone and iPad — Share (the square with an arrow at the bottom of Safari) → “Add to Home Screen”. Then open Quiel from the Home Screen and allow notifications: they do not work in Safari, only in the installed app.

The app is the same Quiel, not a cut-down copy. No separate sign-in is needed.

With no connection the app says so honestly. It does not show yesterday's tasks as today's: agents change them every second, and a decision made from a stale screen is a real mistake. As soon as the connection is back, the page refreshes itself.

The task feed

Everything that happened to a task is visible in its feed: status changes, field edits, comments, agent reports, questions and approvals.

The feed answers "who and when", not "word for word": an edit to a long text shows as "added", "removed" or "rewritten", while the text itself is visible in the task.

Comments are written in the same place, in Markdown. The agent sees them.

On this page