A plan is a proposal, releasable step by step.
For every case the agent lays the possible paths side by side, says which one it recommends and why — and what would become of the reminder either way. Every path is released on its own.
AeroLink GmbH & Co. KG
Case 1 of 62
Draft · 6k / 1k tokens
Content of the reminder in the chosen path: look at it myself
| Document | Status in the chosen path | Open |
|---|---|---|
| RE-8832-2002 | included | €685,699.00 |
| SR-8832-2005 | included | €68,569.00 |
| RE-8832-2001 | stays out — dunning stop (clarification) | €445,420.00 |
| RE-8832-2013 | stays out — dunning stop (clarification) | €635,439.00 |
Today: 8 documents · €1,171,219.00 After: 8 documents · €1,171,219.00
The paths of this case
-
Send
8 documents · €1,171,219.00 · dispatch today
The held document can follow only after 7 days because of the dunning frequency — one level higher.
Release this path
-
Defer Recommended
8 documents · €1,171,219.00 · dispatch on 01/09/2026
Tomorrow's run puts the case right back on top — with today's reason.
Release this path
-
Look at it myself
8 documents · €1,171,219.00 · no dispatch
The case stays and is reassessed tomorrow.
Release this path
A plan starts as one sentence, and the sentences repeat.
The instructions a team gives an agent every day are remarkably uniform — and each of them ends as a plan with steps, an expectation and a release. A selection, worded the way it is worded in practice.
Steps with goals, not a list of clicks.
A plan states for every step what it is meant to achieve, which objects it applies to and how many of them are already released. While a step is open it does not run — and the plan stays a draft.
- A goal per step
- A goal reads "send today's clear cases", not "press the button" — and what the step may do hangs off it.
- Objects per step
- Every step carries the cases it applies to — readable before it runs.
- Release per step
- Releasing two of three steps is a normal state. The third does not come along.
- A draft stays a draft
- Only what is released is executed. The rest stays, visible, with its reason.
All plans › Group today's dunning notices by review need
Dunning agent · less than a minute ago
Re-cut by review group
Send the 3 notices in the “clear case” group, provided they are still dispatchable — an explicit sign-off on the safe bulk send.
and 2 more.
Look at the notice whose dispute block is holding documents back, and decide whether it goes out incomplete today or waits until the block expires.
For every case the possible paths, with their consequences.
That is the difference between a proposal and a recommendation without an alternative: the agent shows the paths this case has, each with the result it would produce — documents, amount, dispatch date.
-
Send
8 documents · €1,171,219.00 · dispatch today
The held document can follow only after 7 days because of the dunning frequency — one level higher.
-
Defer
Recommended8 documents · €1,171,219.00 · dispatch on 01/09/2026
Tomorrow's run puts the case right back on top — with today's reason.
-
Look at it myself
8 documents · €1,171,219.00 · no dispatch
The case stays and is reassessed tomorrow.
One path is marked "recommended", the others stay selectable. And "look at it myself" is not a fallback but one of the three answers.
The route to a recommendation sits beside it, control included.
A recommendation is a chain: what the agent does, what the system computes from it, what is expected of that — and only then the result. The third link matters most, because it makes the action checkable before it happens.
-
Agent
Take two zero-sum documents out via the dunning stop
-
System
The reminder is recomputed
-
System · control
expected: −2 documents, −€0.00
-
Agent
Send the reminder (EUR, dunning group Germany)
-
Dispatch today
1 document · €450.00
Why
Zero sum — two dunned documents sit in a clearing group with a balance of nil. The documents taken out stay out via the dunning stop; the total is only right once they are cleared in accounting.
What runs over many objects accounts for each one.
An action over 200 cases is not a button but a batch: it runs in the background, keeps an account per object and states at the end what went through and what did not — with the reason per object.
- An account per object
- Every object has its own result. "198 of 200" is a statement, not an estimate.
- Failures with reasons
- What did not run is named with its object and its reason — not as one summary line.
- The result stays
- A batch leaves an artefact that is still readable after the session.
Session balance
Session running 36 minutes · 14 actions
Balance
This session analysed and annotated 5 customers carrying 18.58m EUR in overdue volume; the group was rated critical. The standout is Becker Industries SE (no. 64618837), where a dunning block over 4 open disputes is holding 4.29m EUR of overdue receivables. The run produced 3 letters, created and sent — 14 actions across 8 objects over 2 analyses.
Analyses in this session
Session results
5 customers analysed and annotated, 3 letters created and sent.
A selection that outlives the session.
What you noted down is rarely finished within one session. A list holds the selection — as a set of objects or as a saved view — and is afterwards as usable in the interface as it is in the chat.
A plan is one layer. Here are the others.
- 01 Data & Context One shared record every agent uses
- 02 Agentic Core It plans, explains itself, and waits
- 03 Governance & Audit Release, ledger, traceability
- 04 Integration Layer Connect ERP, CRM and credit agencies
- 05 Data security ISO 27001, SOC 2, Frankfurt
- 06 Workflows & Scheduler Rules, schedules and dunning runs
- 07 Skills & Tools What an agent can do, and can't
- 08 Analyses & Reporting Fixed reports, and analyses on demand
One set of data, one release path, one log. The rest is your decision.
What a plan explicitly may not do.
A plan is where an agent could do the most. Which is why the boundaries matter most here.
- No step runs without a release. The plan stays a draft while anything is open.
- No path is chosen for you. One is recommended; a person chooses.
- No action outside the declared ones. A plan can only order what is permitted anyway.
- No figure from the model. Documents, amounts and deadlines come from the database.
- No silent deviation. If the result differs from the expectation, nothing happens.
- No plan that starts itself. A schedule or a person triggers it.
What gets asked about plans.
No — you can release per case, per path or a whole bucket ("release bucket (30)"). What you cannot do is switch the release off: only what is released is executed, and who released it is recorded on the object.
From the chain beside it. Every recommendation names the action, the system's recomputation, the expected result and only then the outcome — plus a "why" sentence restating the finding. None of it is the model's prose: documents, amounts and deadlines sit beside it, from the database.
It is a full path rather than the absence of a decision: the case stays, nothing goes out, and tomorrow it is reassessed — with today's reason. The run then puts it back on top.
It becomes a batch: it runs in the background, keeps an account per object and reports at the end what went through and what did not — with the reason per object. The result stays readable as an artefact, after the session too.
Yes, as a list — either as a set of concrete objects or as a saved view, which is a query that recomputes when opened. Both are afterwards as usable in the interface as in the chat.