---
title: "Request Knowledge Recompile"
method: POST
path: "/api/domains/{domain_id}/agent-desk/knowledge/recompile"
tags: ["agent_desk"]
---

# Request Knowledge Recompile

`POST /api/domains/{domain_id}/agent-desk/knowledge/recompile`

## Request

- Base URL: `https://api-v1.unusual.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://api-v1.unusual.ai/api/domains/{domain_id}/agent-desk/knowledge/recompile`
- Auth: OAuth 2
  - Password
  - Token URL: `/auth/login`

Compile (or recompile) the Knowledge Document from current sources, as a
PROPOSAL.

THE ONE COMPILE LANE the customer can reach, and since AGENTDESK-RD(w4) it is the
MANUAL one — the automatic lane is the changed-page watch, which recompiles the
affected sections and publishes them itself. Two affordances land here, the same act
with different framing:

* **"Update from latest website crawl"** on the System prompt tab — the first-run
  and catch-up button, and the only door to a WHOLE-document rewrite (the watch only
  ever recompiles the sections that cite a changed page). Until 2026-07-31 the full
  compiler had no UI trigger at all: a customer could hand-write a document or add
  one page at a time, but the sixteen-section compile that is the actual product was
  reachable only from the changed-pages banner (so, only if the site had changed) or
  from a worker. That was the gap this route filled — and the banner it names retired
  on 2026-08-08, which leaves this the only button.
* an operator applying guidance ("lead with the compliance story").

Everything is validated synchronously that can be — unknown section keys, and
whether there is anything to compile at all — because the alternative is a
202 followed by a silent worker failure twenty minutes later.

RATE LIMIT: one in-flight compile per domain (``autopilot.claim_compile``).
A double-click, or two people on the same account pressing the button, gets a
409 with the start time rather than a second full compile — sixteen agent
calls and a duplicate proposal in the reviewer's queue. The claim is
self-clearing (a TTL, plus "a version landed"), so a dead worker costs one
window rather than a permanently jammed button.

── IT APPLIES ITSELF NOW (Will, 2026-08-10) ────────────────────────────────

"Auto apply updates, don't wait for user approval like you have." So the paragraph
that used to live here — "NEVER activates… a whole-document rewrite is the one change
big enough that a human should see it first" — is retired, and with it the last
propose-and-wait step on this surface (UX constitution §2.1: the human's control is
Undo, not approval). The ROUTE is unchanged in every other respect: it still
validates synchronously, still claims the in-flight slot, still enqueues. What
changed is one kwarg — ``auto_apply=True`` — and everything it turns on lives in the
worker, where the version it would publish actually exists.

Two guarantees survive the change, and they are the ones worth stating:

* The POLICY document is untouchable from here, structurally: the compile lane only
  ever writes ``knowledge``, and ``autopilot.activate`` re-checks the kind at the
  point of writing.
* The per-desk ``hold`` dial still holds. A desk a staff member explicitly stopped
  gets a proposal, exactly as before.

No replay runs anywhere in this flow.

## Path parameters

- `domain_id` string, required

## Headers

- `x-view-as` string, nullable

## Request body

- KnowledgeRecompileRequest
  - `section_keys` string[], nullable
  - `instruction` string, nullable

## Response `202`

Successful Response

- KnowledgeUpdateQueued
  - `status` 'queued'
  - `detail` string, required
  - `compiling_since` string, nullable

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/unusual/apis/dashboard-server.md) - [All operations](https://skmtc.dev/unusual/apis/dashboard-server/llms.txt) - [OpenAPI document](https://skmtc.dev/unusual/apis/dashboard-server/revisions/89f716930ead?raw)