Document AI Feedback Agent
The Document AI Feedback Agent is a chat interface grounded on a single Document AI document. The user describes how extraction should change ("for this vendor, ignore the freight line in the totals") in plain language, and the agent proposes rules they can preview and confirm. Confirmed rules become regular Document AI instructions that apply to future documents.
It's the most direct way to give end users a hand in shaping extraction behavior without you building rule-management UI.
When to use it
- The user is reviewing a document and notices a recurring pattern that should change going forward.
- You want users to be able to try a rule (via preview) before committing it.
- You want surface-level visibility for which rules exist and where they apply, without building a separate management screen.
Component identifier
documentai-feedback-agent
data payload
The session-create request takes a component-specific data payload. For this component:
| Field | Required | Description |
|---|---|---|
documentId | yes | The Document AI document the chat is grounded on. |
userId | yes | Identifier for the end user. Surfaces in audit logs. |
companyName | conditional | Required when the document was uploaded under a company; omit when working at tenant scope. |
partnerId | no | Free-form partner identifier forwarded to the agent for telemetry. |
permissions | no | Per-session capability overrides; see below. |
Permissions
All fields are optional. Omitted fields fall back to the component defaults shown here.
| Permission | Default | Description |
|---|---|---|
canManageRulesAtScope | ["Vendor", "Buyer"] | Scopes at which the user may create, edit, or deactivate rules. Subset of Tenant, Company, Vendor, Buyer. |
Set canManageRulesAtScope conservatively. If a user has no business creating tenant-wide rules, leave Tenant out — the agent will see that scope as off-limits and tell the user it can only act at the scopes the session permits.
Example: minting a session
POST /v1/tenants/05ed0ffa-1bf5-4bd1-9970-df7a78a948fe/embedded-components/sessions
Authorization: Bearer <your-kaunt-api-key>
Content-Type: application/json
{
"component": "documentai-feedback-agent",
"accessMode": "iframe",
"allowedOrigins": ["https://app.partner.com"],
"data": {
"documentId": "227aebd0-36a4-4d17-b96d-c5b5d071abd4",
"userId": "user-42",
"companyName": "acme-logistics",
"partnerId": "partner-acme",
"permissions": {
"canManageRulesAtScope": ["Company", "Vendor", "Buyer"]
}
}
}
The response is the standard create-session shape — see the API reference for the full schema.
Recommended placement and size
The Document AI Feedback Agent is designed to live as a side or detail panel alongside the document the user is reviewing. Minimum recommended size: 360 × 560 px. Below ~420 px wide it switches to a compact layout that drops the helper text and tightens spacing.
What users see inside the chat
- Their own messages appear as user bubbles on the right.
- Progress hints ("Looking at the rules currently in scope…") appear as muted, italic lines while the agent is thinking. They collapse once the agent produces a reply.
- Agent replies appear as bubbles on the left.
- Proposals appear as cards with a plain-language summary, the affected field, when the rule would apply (and when it would not), a confidence indicator, any conflicts with existing rules, and an Apply button. Confirmed proposals turn into committed Document AI rules.
- Previews appear inline when the user asks the agent to "show me what this would change". Previews are read-only — they do not modify the document.
- Permission-denied notices appear when the user asks for something outside their granted permissions, with a suggested alternative when possible.
All chat interactions happen against Kaunt's Document AI chat API. Your application does not need to proxy or replicate them.
Confirming a rule
A proposal is only committed when the user clicks Apply on the proposal card and Kaunt confirms the write succeeded. If requiresElevatedPermission is set on the proposal, the Apply button is disabled and the user is told what scope they would need — the agent will not silently downgrade the proposal.
Once a proposal is committed, the resulting rule is visible to the rest of the Document AI surface (the /v1/.../documentai/instructions API). It applies to subsequent documents in the same way as feedback-driven instructions.
Worked example: a vendor-scoped freight rule
This walkthrough follows one full interaction from session creation to a committed rule. It uses fictional names; substitute your own tenant, document, and user IDs.
Scene. Acme Logistics is an AP automation partner. Their user Mira is reviewing an invoice from VendorX. VendorX always includes a freight line in the line items, but Acme's general ledger expects freight to be excluded from the net total — the freight cost is booked separately. Mira wants this to stop happening for every future VendorX invoice without involving an engineer.
1. Acme's backend mints a session
When Mira opens the invoice review screen, Acme's backend creates a session keyed to the document and to Mira. Mira can manage rules at company, vendor, and buyer scope (but not tenant-wide):
POST /v1/tenants/05ed0ffa-1bf5-4bd1-9970-df7a78a948fe/embedded-components/sessions
Authorization: Bearer <acme-kaunt-api-key>
Content-Type: application/json
{
"component": "documentai-feedback-agent",
"accessMode": "iframe",
"allowedOrigins": ["https://app.acme-logistics.com"],
"data": {
"documentId": "227aebd0-36a4-4d17-b96d-c5b5d071abd4",
"userId": "mira@acme-logistics.com",
"companyName": "acme-logistics",
"partnerId": "partner-acme",
"permissions": {
"canManageRulesAtScope": ["Company", "Vendor", "Buyer"]
}
}
}
The response contains the sessionId, the JWT, and the iframe url. Acme's frontend embeds the iframe and answers kaunt-ready with the JWT — see Iframe Embedding for the handshake.
2. Mira asks for the rule in plain language
Mira types into the chat:
For VendorX, don't include the freight line in the totals.
A muted "thinking" line appears ("Looking at how VendorX's freight lines are being summed…"), then the agent replies:
I can add a vendor-scoped rule that excludes lines whose description matches freight / shipping / delivery from the totals for documents issued by VendorX. Want to preview it first?
…followed by a proposal card:
| Field | Value |
|---|---|
| Summary | Exclude freight lines from totals for VendorX |
| Scope | Vendor — VendorX |
| Affected field | totals.netTotal |
| Applies when | Line description matches freight, shipping, delivery (case-insensitive) |
| Does not apply when | Document is not from VendorX |
| Confidence | 0.86 |
| Conflicts | None |
Because Vendor is in canManageRulesAtScope, the Apply and Preview buttons are both enabled. If Mira had only been granted Buyer, the card would render with the buttons disabled and a "this proposal requires Vendor-scope permissions" hint.
3. Mira clicks Preview
The card shows a Preview running… spinner. A few seconds later it expands inline:
| Field | Current | Previewed |
|---|---|---|
totals.netTotal | 4 820.00 | 4 575.00 |
totals.tax | 1 205.00 | 1 143.75 |
| Line "FREIGHT EU" | included | excluded from totals |
Preview is read-only — Acme's source-of-truth extraction is unchanged. Mira sees what would happen if she applies the rule.
4. Mira clicks Apply
The card transitions to Applying…, then to a committed state with the rule ID:
Rule committed (ID
rule-9f12…). It will apply to future VendorX invoices automatically.
5. What Acme's backend observes
The new instruction is now visible via the Document AI instructions API alongside any other rules and feedback-driven instructions for this tenant:
GET /v1/tenants/05ed0ffa-1bf5-4bd1-9970-df7a78a948fe/documentai/instructions?scope=Vendor&scopeReference=vendor-x
Authorization: Bearer <acme-kaunt-api-key>
{
"instructions": [
{
"id": "rule-9f12a8b1-d7c4-4f80-9a01-2c83f6b6f10e",
"scope": "Vendor",
"scopeReference": "vendor-x",
"fieldAffected": "totals.netTotal",
"summary": "Exclude freight lines from totals for VendorX",
"source": "documentai-feedback-agent",
"createdBy": "mira@acme-logistics.com",
"createdAt": "2026-05-27T13:42:11Z"
}
]
}
Mira (or an admin) can disable or delete the instruction from the Document AI instructions API if business rules change later.
Why this matters
Acme did not build a rule-management UI, a preview engine, or a conflict-detection pass. The only integration code they wrote was the session-create call in step 1 and the iframe + postMessage glue. Everything between Mira's plain-language message and the committed instruction is handled by the embedded component and the Document AI backend.