Resources and prompts

Besides tools, the server offers three things the client uses on its own: resources (documents the user attaches to the conversation), prompts (ready-made scripts the user picks) and completions (autocomplete for the arguments of both). And before running a destructive tool, it asks for your confirmation.

None of this opens a new path to your data: everything goes through the same tools, under the same token scope and the same person's role. A resource or prompt that relies on a tool you cannot run simply does not appear.

Resources

A resource is a document identified by a URI. The user picks, say, an execution, and the client reads the document and puts it in context, without the model having to call a tool. All of them come back as JSON.

URI	What comes back	Tool that reads it
`kobana://kadu/me`	The person, organization and scopes of the connection	`kadu_me_get`
`kobana://kadu/repository`	The organization's Kadu Playbook and its skill catalog	`kadu_repository_get`
`kobana://kadu/operation_approvals`	Your approvals by link, newest first	`kadu_operation_approvals_list`
`kobana://kadu/operation_approvals/{id}`	One approval: what was asked, the decision and the result	`kadu_operation_approvals_get`
`kobana://kadu/workspaces/{id}`	A workspace	`kadu_workspaces_get`
`kobana://kadu/activities/{id}`	An activity	`kadu_activities_get`
`kobana://kadu/tasks/{id}`	A task and its parameters schema	`kadu_tasks_get`
`kobana://kadu/executions/{id}`	An execution	`kadu_executions_get`
`kobana://kadu/executions/{id}/events`	The events the agent reported during the execution	`kadu_executions_events_list`
`kobana://kadu/executions/{id}/logs`	The execution logs	`kadu_executions_logs_list`
`kobana://kadu/executions/{id}/todos`	The pending items the execution opened	`kadu_executions_todos_list`
`kobana://kadu/memories/{id}`	A memory of the agent	`kadu_memories_get`
`kobana://kadu/environments/{id}`	An environment	`kadu_environments_get`
`kobana://kadu/schedules/{id}`	A schedule	`kadu_schedules_get`

resources/list returns the fixed URIs and resources/templates/list the templates with {id}.

Permissions. Each resource is read by the tool in the last column. It only appears, and is only read, if you can run that tool; otherwise the read returns -32602 with data.code: "insufficient_permission".
No binaries. File content never comes as a resource: it is downloaded through the presigned URL of kadu_files_download.
Not found. An unknown URI, or a record that does not exist in this organization, is -32002 in the 2025 era and -32602 in 2026-07-28 — see Errors.
No change subscriptions. The server is stateless: there is no resources/subscribe and no list-changed notice.

Prompts

A prompt is a ready-made instruction you pick in the client that becomes the first message of the conversation. In Kadu, every prompt only reads: running, cancelling or changing configuration is always something you ask for explicitly. A prompt appears only if you can run all the tools it relies on.

Prompt	Arguments	What it does
`review_failed_executions`	`since` (optional, `YYYY-MM-DD`; default: seven days ago)	Lists the executions that failed since the date and explains what went wrong in each one, grouping repeated causes, without running, cancelling or continuing anything.
`explain_execution`	`execution_id`	Explains, step by step, what the agent did in one execution: the systems it touched, the result and the pending items left for a person.
`monthly_usage_report`	`month` (`YYYY-MM`)	Summarizes usage and cost of the month's executions, by task and by workspace, and points out the tasks that cost the most.
`check_task_readiness`	`task_id`, `environment_id`	Says whether the task can run now in that environment and, if not, exactly what is missing (plan, cost limit, secrets, repository), without running anything.

The script arrives with the dates already worked out. A missing required argument, or since and month in the wrong format, is -32602.

Completions

completion/complete suggests values while you type an argument:

Ids (execution_id, task_id, environment_id and the {id} of the templates): the recent ids of the matching listing, filtered by what you have typed, under that listing's permission. If you cannot list, there is no suggestion.
month: the last twelve months.

At most 100 values. With no source of suggestions, the answer is an empty list, and you keep typing.

Confirming destructive tools

Destructive tools are marked with destructiveHint:

every delete tool (*_delete, including disabling a task's trigger endpoint);
kadu_tasks_run and kadu_executions_continue, which run the financial agent — and it acts on banking, the ERP and invoices;
kadu_executions_cancel;
kadu_webhook_deliveries_replay and kadu_webhooks_rotate_secret;
kadu_tasks_endpoint_update, which changes who can run the agent;
kadu_webhooks_create, and kadu_webhooks_update when it changes the url — where the organization's data goes.

The server does not rely on the client alone: it enforces the confirmation itself, in one of two ways, depending on the client.

Confirmation in the chat (era `2026-07-28`)

When the client speaks era 2026-07-28 and declares support for elicitation forms:

The first tools/call runs nothing. It returns resultType: "input_required" with a one-question form: run this action, with these arguments?
The client shows the question and re-sends the same call with your answer.
Only an explicit yes runs it. Declining or cancelling returns an isError result with USER_DECLINED, and nothing changes.

The confirmation is valid only for that call: the same tool, the same arguments, the same person and organization, for 5 minutes. An answer cannot be reused for another task or another action; if anything does not match, the server simply asks again. And it is single use: re-sending a call already confirmed returns isError with confirmation_replayed, running nothing — to repeat the action, call the tool again and confirm again.

Client without the confirmation form: approval by link

A client that cannot confirm in the chat — in the 2025 era, or on 2026-07-28 without declaring elicitation forms — can still use destructive tools, through an approval link. The call runs nothing: the server stores the operation as pending and answers successfully (no isError), in a single JSON text:

{
  "status": "approval_required",
  "approval": {
    "id": "6f0c2d1e-…",
    "status": "pending",
    "url": "https://app.kadu.ia.br/approvals/…",
    "expires_at": "2026-10-31T12:15:00.000Z",
    "resource_uri": "kobana://kadu/operation_approvals/6f0c2d1e-…",
    "check_with": { "tool": "kadu_operation_approvals_get", "arguments": { "id": "6f0c2d1e-…" } }
  },
  "message": "… Show this URL to the user … Do not call the tool again …"
}

The assistant shows the URL. Do not call the tool again: that would create another approval.
You open the link signed in to Kadu (without a session, it goes through sign-in and comes back to the link). The screen shows what will happen ("Run the task", "Delete the environment"), who asked, when, through which client, the current data of what the operation acts on and every argument that will run.
Continue runs the operation right away, with the permissions you have now: if you lost the permission or your membership in the organization since the request, or if the token that asked was revoked, the run fails and nothing changes. Cancel ends it without running anything.

The link is valid for 15 minutes and decides only once: two clicks on Continue run once, and an expired or cancelled link does not run. Only you — the person behind the token that made the call — can open the link: for anyone else, even in your organization, it does not exist.

If what the operation acts on changes between opening the screen and clicking Continue (a webhook that changed its URL, a task that was edited), nothing runs (subject_changed): ask for the operation again and review the new link.

Your approvals are listed in Settings › Approvals in the console, with tabs by status (Pending, Executed, Cancelled, Failed, Expired); clicking a row opens the approval read-only — a pending one is decided through the link the assistant showed.

Following the approval

The assistant itself follows the approval it asked for: with the id from the answer, kadu_operation_approvals_get (or the kobana://kadu/operation_approvals/{id} resource) shows the status — pending, then executed, failed, declined or expired — and what the operation returned. check_with is included in the answer only when the caller can run that read (scope kadu/system_events and permission agent.operation_approvals.read). The assistant should check when you say you decided, not in a loop.

Reading never decides: there is no tool and no API route that continues or cancels an approval. If there were, whoever asked for the operation could also approve it.

A secret in the result — the new signing secret from kadu_webhooks_rotate_secret — is shown in clear once, on the screen, right after Continue; the read tool and the reloaded screen show it masked.

When confirmation is not possible

A token with no person of the organization who could open the link returns isError with confirmation_required. If the server cannot record the confirmation or the approval at that moment, the tool is refused with confirmation_unavailable; try again later. In both cases nothing runs, and the other tools keep working normally.

Resources​

Prompts​

Completions​

Confirming destructive tools​

Confirmation in the chat (era 2026-07-28)​

Client without the confirmation form: approval by link​

Following the approval​

When confirmation is not possible​