> ## Documentation Index
> Fetch the complete documentation index at: https://alguna.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Agentic Collections
> AI-run collection cases that chase, classify replies, track promises to pay, and escalate — within guardrails you set
**Beta.** Agentic Collections is available in beta to selected organizations. Capabilities ship incrementally and may be enabled or disabled per workspace. To request access, contact your Alguna point of contact or [support@alguna.io](mailto:support@alguna.io).
Agentic Collections replaces the fixed reminder cadence of [Collections](/docs/collections/overview) with an AI agent that works each unpaid invoice as a **case**: it sends chase emails from a mailbox with a persona you choose, reads and classifies what the customer writes back, records promises to pay and notices when they are broken, pauses when there is a dispute or a payment claim to check, and escalates or flags for a person according to a **playbook**. Use it when a one-size cadence is costing you relationships or time, and you want collections that respond to what each customer actually says.
It composes with what you already have. Invoices, payments, statuses, and automations are unchanged; the agent decides what to do about an open balance and records every decision on the case timeline. There are no public API endpoints for Agentic Collections in the `2026-04-01` API — configuration and casework are in the dashboard under **Workflows → AI Collections** and **Control Tower**. The invoices and payments it acts on are readable as usual. See [How Alguna Works](/docs/concepts/how-alguna-works).
***
## Concepts
### Cases
A case is one collection effort. Cases are opened per invoice or per account, depending on the playbook's **consolidation mode** (`per_invoice` or `per_account`), and hold the invoices attached to them.
| Case `status` | Meaning |
| ------------- | --------------------------------------------------------------------------------------------- |
| `open` | Being worked |
| `paused` | Outreach suspended — by an operator, or automatically on a dispute, payment claim, or promise |
| `resolved` | The balance was settled |
| `closed` | Ended without settlement — written off, or closed by an operator |
Within an open case, a **substatus** says where the conversation is:
| Substatus | Meaning |
| ------------------------- | ------------------------------------------- |
| `active_chase` | The cadence is sending |
| `awaiting_customer_reply` | A chase went out; waiting |
| `promise_to_pay` | The customer committed to a date |
| `promise_broken` | That date passed without payment |
| `dispute` | The customer disputes the invoice |
| `payment_claimed` | The customer says they paid; being verified |
| `remittance_received` | Remittance advice arrived |
| `paid_pending` | A payment is in flight |
| `resolved` | Done |
Cases can also be **suppressed** — `snoozed`, `written_off`, or `operator_closed` — which stops outreach without deleting the history.
### Playbooks
A playbook is the policy a case follows. It has a **type** (`ar` for collections; `billing_support` for non-collections billing conversations), versions (`draft`, `published`, `archived`), and:
| Setting | Options | Effect |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Autonomy mode** | `monitor`, `suggest`, `act` | `monitor` observes and records; `suggest` drafts actions for a person to approve; `act` sends within the guardrails |
| **Cadence** | Steps anchored to `invoice_sent`, `first_due_date`, `last_action_at`, or `promise_date`, each with an action: `send_chase`, `check_status`, `escalate`, `flag` | When and what the agent does |
| **Consolidation** | `per_invoice`, `per_account` | One case per invoice, or one per customer covering all open invoices |
| **Promise broken behaviour** | `follow_up`, `escalate`, `flag` | What happens when a promised payment date passes |
| **Bounce handling** | `manual_flag`, `auto_pivot` | Flag a bounced contact for you, or move to the next known contact |
| **Internal reply action** | `notify`, `ignore` | What to do when someone on your side replies on the thread |
| **Mailbox persona tone** | `friendly`, `professional`, `firm` | Voice of the generated emails |
| **Access** | `org_wide`, `restricted` (by user or role) | Who can edit and use the playbook |
### Promises to pay
When a customer commits to a date, the agent records a promise (`active`). It becomes `honored` when payment lands, `broken` when the date passes without it — which triggers the playbook's promise-broken behaviour — or `superseded` when the customer gives a new date.
### Inbound classification
Every reply is classified on two axes before the agent acts:
* **Attribution** — who it is really for: `ar`, `billing_support`, `sales`, `internal`, `noise`, or `unknown`. Only `ar` replies drive the case; the rest are routed or ignored.
* **Intent** — what it says: `paid_claim`, `promise_to_pay`, `dispute`, `deduction`, `doc_request`, `po_update`, `master_data_change`, `wrong_contact`, `recommend_contact_update`, `out_of_office`, `remittance_sent`, `unsubscribe`, `escalation_request`, `invoice_question`, `payment_status_question`, `general_question`, `unknown`.
A `paid_claim` moves the case to `payment_claimed` and pauses chasing until a payment is found; a `dispute` pauses it for a person; a `wrong_contact` or `recommend_contact_update` raises a contact-update task; `unsubscribe` stops outreach to that address.
### Account segments
Playbooks are applied to account segments, built by `filter` (a saved customer filter), `manual` (a hand-picked list), or `hybrid`. A high-value enterprise segment can run a `suggest` playbook with a `professional` tone while long-tail accounts run `act` with a `firm` one.
### Control Tower
Control Tower is the queue of things the agent could not resolve alone. Each task has a kind and is `open`, `resolved`, or `dismissed`:
| Task kind | Raised when |
| -------------------------- | ---------------------------------------------------- |
| `ownerless_case` | A case has no assigned owner |
| `mixed_collection_threads` | Several cases share one email thread |
| `payment_reversal` | A payment on a case was reversed |
| `stale_version_cases` | Cases are running on a superseded playbook version |
| `agent_observation` | The agent noticed something it wants a person to see |
### Case timeline
Everything is recorded as a timeline event with its actor (`system`, `user`, or `agent`): `case_opened`, `invoice_attached`, `substatus_transition`, `cadence_scheduled`, `invoice_email_sent`, `promise_captured`, `promise_honored`, `promise_broken`, `contact_bounced`, `classifier_intent_applied`, `guardrail_violation`, `payment_received`, `payment_reversed`, `paused`, `resumed`, `resolved`, `closed`, and so on. The timeline is the audit trail: what the agent did, why, and on which signal.
***
## What triggers the agent
The agent runs on three kinds of trigger: a **cadence step** coming due, a **broken promise**, and an **inbound message** on a case thread. Between those it does nothing; there is no continuous background activity on a case.
***
## Supervised autonomy
Autonomy is per playbook. In `monitor` the agent only records; in `suggest` it drafts the next action and a person approves it; in `act` it sends within the playbook's cadence, tone, and escalation settings. Whatever the mode, the agent does not:
* Issue invoices or credit notes, or change invoice status.
* Charge a customer's payment method — payment retries remain a [dunning](/docs/collections/dunning) automation step.
* Change subscription terms or pricing.
* Email outside the mailbox and persona configured on the playbook.
A guardrail violation is recorded on the timeline rather than acted on.
***
## Composition with existing flows
| Layer | Responsibility | Source |
| -------------------------- | ---------------------------------------------------------------------- | ------------------------------------------- |
| Signals | Invoice status changes, payments and reversals, inbound email, bounces | Existing invoicing and payment primitives |
| Decisioning | Which case, which step, which tone, whether to pause or escalate | Playbook + agent |
| Execution | Chase emails from the case mailbox; tasks in Control Tower | Agent |
| Recovery of failed charges | `retry_invoice_payment`, billing-info requests | [Dunning](/docs/collections/dunning) automations |
Existing automations keep running. If you enable Agentic Collections on a segment, turn off the **Overdue Invoice Reminder** automation for those customers so they do not receive both.
***
## Getting started
Ask your Alguna contact to enable Agentic Collections for your workspace.
Under **Workflows → AI Collections**, connect the mailbox the agent will send from and choose its tone.
Start with `monitor` so you can watch the classifications and proposed cadence on real cases without anything being sent.
Pick a small account segment, switch the playbook to `suggest`, and approve or edit the drafts from Control Tower.
Once the drafts match what you would have sent, switch to `act`. Keep high-value segments on `suggest` if you want a person on every send.
***
## FAQ
**Does Agentic Collections replace my existing automations?**
No. They keep running. Disable the overdue reminder for segments the agent handles to avoid double outreach.
**Will the agent send communications without my approval?**
Only in `act` mode, and only within the playbook's cadence, tone, and mailbox. `monitor` and `suggest` never send on their own.
**Can I see what the agent did and why?**
Yes. Every action, classification, and guardrail check is on the case timeline with its actor and trigger.
**How does it handle disputes and short-pays?**
A `dispute` or `deduction` intent pauses chasing and puts the case in front of a person, who resolves it with a [credit note](/docs/invoices/credit-notes), a [refund](/docs/invoices/refunds), or by resuming the case.
**Is there an API?**
Not in the `2026-04-01` public API. Invoices, payments, and A/R ageing remain available through their own endpoints.