Agents
Call one in a comment and it answers in the thread — on your access, reading only that project, and never deciding anything itself.
What an agent is
Recorded inside the product, on a board made up for the camera. The answers are scripted; everything around them is the product. Sound on for the commentary.
An agent is a role of your workspace, not an account and not a seat. Two are there from the first day — Product and Analyst — and a workspace may add its own. They have no password, no token and no access of their own; what they can reach is what the person who called them can reach, and less.
You call one the way you call a colleague: by name, in the comment thread where the question already is. It reads the issue, and then either answers in the thread or puts a decision to you as a question with options — which you answer, or do not.
An agent never decides. Its proposal is recorded as a question addressed to you, and the issue keeps who chose and what they chose. A proposal nobody answers stays unanswered — a resolution is put with no default, so silence decides nothing.
Calling one
- Write a comment on the issue and mention the role:
@product— the picker offers the workspace’s agents in a section of their own, under the people. - The comment is posted as yours. A line under it says the agent was called and is working.
- The answer arrives in the same thread, as a comment with no author of its own: it is signed with the role and with who asked for it.
- A mention inside
codeor a code block is text, not a summons. - Agents do not call agents. A mention in an agent’s own words summons nobody: there would be no honest answer to «on whose behalf», so the situation is not created.
- The same question can be put to two roles at once; each answers on its own, and the thread says which is which.
- You can take a call back while it is queued or running.
Whose access it runs on
The whole design rests on one sentence: an agent can do nothing you cannot. It is not a promise about a prompt — it is where the code reads its permissions from.
- It runs as you, and your access is read again when the work actually runs — not as it was when the comment was written. Someone who has lost the project in between has nothing done on their behalf.
- It is clamped to the issue’s project. An issue linked from another project shows as its key and nothing more, so asking about one project never ships the other nine to a model.
- Its tools are reads only, from a fixed list. There is no write tool it could be talked into using.
- The comment, the proposal and the journal row are written by Kaiku from the agent’s structured answer — the model never writes to your workspace itself.
- Every call is a row: who called which role on which issue, what came of it, and what it cost. The workspace’s owner and admins can read all of them; everybody can read their own.
The answer, and what it read
An answer carries the list of what it actually read — the issues and pages its tools returned — so the reasoning can be checked against its sources rather than taken on trust. A proposal carries the same list, plus the argument for the options it offers.
A proposal is an ordinary question with answer options: it appears in Questions beside every other question waiting on you, and answering it records the decision on the issue.
When an agent will not come
When a call is refused, nothing is written to the thread and the refusal says which of these it is:
agent_unknown— no role with that handle in this workspace.agent_off— that role has been switched off by an administrator.agent_plan— the plan does not include AI.agent_budget— the workspace’s agent allowance is used up for now.agent_user_budget— your own allowance is used up for now.agent_credit— on a plan that runs on the company’s own AI key: the key is missing or was refused.agent_unpaid— the workspace’s bill is unpaid and AI is stopped until it is settled.too_many— too many calls at once on this issue.
An issue too long to read in one go is refused as well, and says so. It is the one refusal you fix by shortening the description rather than by paying or waiting.
Switching them on, and what they cost
Settings → Agents, for the workspace’s owner and administrators: a switch per role, the guidelines each role carries, and what everybody has spent. Everybody else sees their own calls there.
- A role can be switched off without switching the feature off.
- The guidelines are plain text the role carries into every call — what to always leave to a person, what never to promise, how much detail to give.
- The allowance is per workspace, and may be split per person, so one enthusiastic reader cannot spend the month.
- What a call cost is on the call, and the totals are on the journal.
Which plans have them
| Plan | Agents |
|---|---|
| Trial | No. The trial has every other feature; AI is not in it. |
| Team | Yes, on our key, out of the plan’s included allowance. |
| Team, own AI key | Yes, on your key: the plan costs less and the model’s bill is yours. |
See Billing and read-only for what the allowance is and what happens when a period lapses.
Through MCP
An agent of your own can call one of these agents, on the tools of Kaiku’s own MCP server:
ask_agent— exactly a comment[~agent:<role>] <text>written by you: the comment is posted, the call is queued, the answer arrives in the thread.get_agent_request— where that call stands, what it read and what it cost.list_agent_requests— the calls, newest first; your own by default.cancel_agent_request— take one back while it is queued or running.
A proposal still arrives as an issue question, which an MCP client answers with answer_issue_question. The decision lives on the issue whichever door it came through — that is the point of putting it there.
Something missing, or not as described here? Write to hello@kaiku.tech