Skip to content
MirrorFirm

Why can't a general agent just recalculate dates and amounts?

A direct answer on why recalculating a schedule is the easy part, and why policy, approvals, history and downstream records decide whether an agent's change is correct.

**Q: Isn't a schedule change just a calculation?**

The calculation is the smallest part. A competent model can compute new dates. What it cannot know without the right context is whether it is allowed to, and what else must change.

**Q: What else is involved?**

- **Policy.** Some products allow one deferral per year; some require a hardship assessment first; some forbid changes within a number of days of a due date. - **Approval.** A change within a threshold may be self-service, while a larger one needs a credit officer or team leader to sign off. - **History.** A customer who has already deferred twice is a different case from a first request, so the agent must read prior adjustments. - **Linked records.** Fees, reminders, direct debit instructions and ledger entries all depend on the schedule. - **Calendars.** Business days, public holidays and cut-off times differ by region and payment rail.

**Q: Where do agents typically go wrong?**

They produce a plausible schedule and skip a check: they apply a change that policy would have refused, or they update the schedule and leave a stale reminder or debit in place.

**Q: How does generated data help?**

A task pack can pair each request with the policy, history and linked records an agent should consult, plus the outcome a careful operator would reach. That lets a team measure the decision, not only the arithmetic.

Evaluate agents on the decisions and side effects around a schedule change, because the calculation itself is the smallest part of the task.

Audience:
Agent developers
Content type:
FAQ
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Repayment scheduling