Nothing runs that nobody released.
Letting an agent write into real receivables data calls for evidence rather than assurances: one write path, a release given by a person, and a ledger that stays with the object. This page shows where the boundaries run — and that they sit in the architecture rather than in a setting.
A click and a sentence take the same road. That is why they cannot act differently.
Every change to real data goes through a declared action and its executor — the click in the toolbar, the sentence in the chat and the step inside a plan all end up in the same place. No tool builds a path of its own beside it, and the agent can propose and rank the declared actions but not extend them. What is not declared does not exist for it.
Ask for an action this object does not have and the platform answers with a sentence rather than an error. A test fails any write path that does not write its ledger entry.
Three ways in
Declared action
The permission required, whether it must ask, and what it records all sit on the action — once, not per caller.
The consequential steps ask beforehand.
Sending a Mahnung (dunning letter), opening or closing a Klärfall (clarification case), handing a document to debt collection: those three come back as a release card before anything happens — over one document exactly as over five hundred.
Release 1 of 3
Draft a letter to Mustermann AG covering all open items?
Release 2 of 3
Draft a letter to Schmidt Logistics GmbH covering all open items?
Release 3 of 3
Draft a letter to Becker Industries SE covering all open items?
- A recorded intent
- The card reads what it is to do from the stored instruction rather than from the call. You release exactly what was phrased.
- No input field on the card
- Editing after the fact would reopen the intent. Where a value is missing, a short form asks instead — fixed subject, and exactly the fields the action provides for.
- No phrasing gets around it
- There is no sentence that sends without the card, whatever the number of documents. A plan never sends letters at all.
Credit decisions have a release of their own — and it applies to the agent just the same.
The credit process's release chain predates every agent, and the agent does not change it: a limit suggestion is validated, submitted for release, and released or declined by the responsible person — with approval ranges, thresholds and named owners. Where the suggestion came from makes no difference to any of that.
-
Suggestion
Credit-agency data, payment behaviour and utilisation produce a credit limit suggestion — prepared by the team or by the agent, with the calculation recorded beside it.
-
Validated
The suggestion is checked and submitted for release. The assigned user is responsible, by default the customer's own.
-
Released
Released or declined — either way with a time and a person. Whoever does not own the range cannot release it.
-
Published
Only after the release is the limit set and effective at the customer.
- Approval ranges with thresholds
- The credit policy decides which amount may be released in which range — in a fixed currency, absolute or relative, and where both are set both conditions must hold.
- Securities reduce the amount to be released
- Active securities of the selected type are deducted from the suggested amount. The range a suggestion falls into follows the remainder, not the gross figure.
- Every suggestion has an owner
- Suggestions go to the customer's own user, otherwise to the configured default. It can be changed per suggestion.
- Changes stay readable at the customer
- Risk classes carry their history, a manually set class stays put, and credit blocks, securities and insurance cover keep their evidence at the object.
It surfaces in Risk Insights — total limit, secured share, uninsured limit and credit limit utilisation by risk class. And in the risk alerts from the connected credit agencies and trade credit insurers, which report a deterioration before it reaches an invoice.
Only a person can release. The agent has no tool for it, by design.
Bilendo has releases in abundance: the release card in the chat, the release chain in the credit process, the approval ranges of the credit policy. What it does not have is a tool with which the agent grants a release itself. Releasing a case, withdrawing a release, releasing a whole group — those three gestures exist only as a click on the case card or the board. Nor is it a setting anyone can loosen: the tool list does not know the gesture, and the tool descriptions say so, so the model does not try.
What the agent may steer instead
Its own work: list, read, open, cancel and resume plans and Vorgänge, answer the question a waiting one is asking, halt or re-order a running bulk write. Anything that stops or restarts work comes back as a card first.
What stays closed to it
Releasing a case, withdrawing a release, releasing a whole group. Three gestures that stay with a person, on the concrete customer.
Nothing runs unattended today. What a schedule changes about that — and what it does not.
No plan runs unattended today: every proposal waits for a release, and a Mahnlauf ends with the day it was computed for. Scheduled plans and an automatic mode — in which released rules take effect without individual confirmation — are planned and not yet built. What will not change is already settled.
-
01 Available
A release per case
The agent submits a plan, a person releases case by case or by group, and only what was released runs. Actions a plan may not run unattended are already marked as such.
-
02 Planned
A schedule instead of a start
A plan begins at the time set for it rather than being started by hand — with the same verdict per reminder and the same prediction per strategy as today.
-
03 Planned
A frame released in advance
Instead of releasing each case, a frame you set beforehand: up to which amount, up to which dunning level, for which customer groups. Whatever falls outside stays lying and keeps waiting for a person.
What does not move either way
- The same write path. A schedule is a trigger, not a second way into the data.
- The same permission check, at the moment of execution.
- The same ledger entry at the object, naming the schedule as the trigger instead of a person.
- The same two kill switches, at the same two checkpoints.
What we still have to decide
- Who may set the frame, and whether the four-eyes principle applies to setting it.
- How a run with no audience reports itself — and how it recognises that it had better do nothing.
- How long a frame released in advance holds before somebody has to confirm it again.
The agent sees nothing you are not allowed to see.
Tools act as the person who triggered them: their company, their area and business-unit rights, their data scope. What is not visible in a classic view is not visible here, and an invented or out-of-scope object id produces no hit.
- Declared once
- The permission a change requires sits on the action — not in a controller, not in a form. A test proves the declaration and the executor agree, and the refusal is phrased in exactly one place.
- Checked twice
- Before the work, so a tool does not compute for nothing, and again at execution. A permission withdrawn between proposal and release therefore still takes effect.
- No reversal
- An executed action stands in the real data. That is why the plan is where reading happens — not a rollback that does not exist.
- No silent limit
- Every limit is named — "281 of 284 processed" rather than an inconspicuously shorter list. A refusal names the number it is about too.
Ledger · Becker Industries SE
-
Dunning level 2 sent — released by M. Weber14 Aug 2026, 09:12
-
Klärfall closed — released by M. Weber14 Aug 2026, 09:11
-
Dunning block set — Vorgang 419202 Aug 2026, 17:40
-
Comment proposed, discarded28 Jul 2026, 11:05
-
Analysis created12 Jul 2026, 08:30
An excerpt as it stands at the debtor.
Readable at the object, months later.
Every object the agent touched keeps a row: when, what, and the person who released it. The ledger is only ever added to and never edited — that is what makes it readable as a history — and it has exactly two writers: the end of every write, and the analysis run. A write path that had to remember to record would eventually forget.
- Fixed terms
- What has a word is recorded. New kinds of entry are added in one place; what is missing there cannot be written.
- It stays beyond the session
- A deleted session does not take the object's history with it. Support reads the same history per company in the internal area.
- Recording breaks nothing off
- A ledger row that cannot be stored does not turn a successful write into a failure. It is reported, not swallowed.
What a session achieved and what it cost.
The Sitzungsbilanz — the product's own term for the summary of a working session, not an accounting statement — counts from the ledger and puts the result into sentences, as a surface and as a PDF. The figures come from the database; the model only writes the prose around them and cannot invent a number.
A summary with a fixed state
A statement that reads differently on the second look is not a summary. "Create again" writes a new state rather than overwriting the old one.
Consumption as a current reading
A meter reading is only useful if it shows the state right now. The second tab is recomputed on every open, stored nowhere, and belongs to no document.
Effort per result
Every plan, analysis and summary states its own consumption. Support can read the accounting per result — and, where a company asked for the recording, the technical history behind it.
Over five hundred documents what counts is which three did not go through.
Where an action costs real work per object it runs as a Vorgang: the target set is fixed when it is triggered, a progress bar shows where it stands, and at the end there is a list of the objects that did not go through — with the reason. It can be cancelled while it runs, and afterwards the failed ones can be triggered again — exactly those.
A fixed target set
A Vorgang works off the set it was triggered for. An object that would only join afterwards needs a new one rather than a silent addition.
Vorgang 4192 · 3 of 284 failed
Retry the failed onesA Vorgang's failure list, as it unfolds in the activity strip.
Two switches, each with exactly one checkpoint.
For the incident there are two switches: one refuses every change to domain data, the other lets no further subagent start. Both are wired so that their absence permits the capability, and each takes effect at exactly one place. A second checkpoint would be a second rule.
-
Changes off
The switch sits where every change already passes through. It refuses with the ordinary error rather than an abort.
-
Subagents off
It sits at the three starting points. Work already running is not aborted; new work does not begin.
-
Settings are written by people
No tool creates, changes or deletes a setting or a Vorlage. The agent can name which ones exist, and works within them.
-
A Vorlage is a commitment
Two colleagues asking for the same thing receive the same plan. That is why a template is a frame the agent works inside — not one it may move.
What the agent explicitly does not do. In full, not curated.
This list is not small print. It is the part against which the rest can be checked. It stands the same way in the product documentation, there alongside seventy-three further recorded limitations.
- It sends nothing of its own accord. Mahnungen and customer letters go out only after the release card.
- No reversal. An executed action stands in the real data.
- It creates, changes and deletes no setting and no template. The frame it works inside is set by people.
- It never writes a comment unasked and never changes a note field.
- It opens and closes Klärfälle. Answering, escalating and reassigning stay in the service portal.
- No number comes from the model. Counts, sums and rankings come from the data.
- Only a person can release, on the concrete customer.
What the audit asks before it agrees.
No. Sending is the most consequential single step in the application and always comes back as a release card — over one document exactly as over five hundred. No phrasing gets around it, and a plan never sends letters at all.
No. Every tool acts as the person who triggered it, with their company, their area rights and their data scope — by the same route the classic list views take. Every write permission is checked again at execution.
No, and that is a decision. An executed action stands in the real data, and a reversal that only mostly works would be more dangerous than none. Reading happens beforehand: in the plan, which shows every step with its expected consequence, and on the release card, which repeats the intent unchanged.
On three levels that support each other. The ledger row at the object is readable at the debtor months later and stays beyond the session. The Sitzungsbilanz counts from that same ledger. And a Vorgang's history names, per bulk run, which objects did not go through and why.
No plan runs unattended today. For the planned automatic mode, what holds today holds in advance: the same write path, the same permission check at the moment of execution, the same ledger entry at the object, and the same two kill switches. What has to be decided is the frame — amount limit, dunning level, customer group — and who may set it. Whatever falls outside stays lying and keeps waiting for a person.
Yes, and there the chain is older than the agent. A limit suggestion is validated, submitted for release, and released or declined by the responsible person — within the approval ranges and thresholds of your credit policy, and regardless of whether the suggestion came from a credit agency, from the team or from an agent. The agent prepares and reasons; it does not decide. Active securities reduce the amount to be released, and every decision stays readable at the customer with its time and its person.
Yes, with two switches: one refuses every change to domain data, the other lets no further subagent start. Each takes effect at exactly one place — the one every change passes through anyway — and refuses with the ordinary error rather than an abort.
No. No tool creates, changes or deletes a setting or a Vorlage; it can only name which ones exist and work inside them. A template is the commitment that two colleagues with the same question receive the same plan — and a commitment a model may move is not one.