Servicing Workspace overview

The servicing workspace is the operating layer for loan and merchant-advance servicing — coordinating cases, work, compliance, people, and the named AI workforce natively on the LendEasy Lending Core, with every contact and account change checked against live policy at the moment it happens.

The servicing workspace is where the operational work of servicing happens. It coordinates cases, tasks, and channels across the AI workforce and the people who supervise it — the voice agent, the copilot, the document agent, and the communications agent — applies current-fact policy at owning borrower-contact and governed-operation boundaries, and drives each matter to an outcome. It runs natively on the LendEasy Lending Core, a system of record the workspace reads and checks against but deliberately does not own — and, the same workflows can run on a core you already operate. Consumer installment, BNPL, and merchant-advance servicing run on the same model.

287servicing operationscallable in the current build

4AI agents on the rostervoice, communications, documents, and the case copilot

5life events watchedcourt, federal and list sources

9domains of case typefrom account service to merchant servicing

Counts come from the build’s own route manifest — see API availability for the exact boundary, which is the one page that tracks implementation truth.

What the workspace holds

The workspace holds the operational state you are trying to reach, not just a log of what happened. The servicing workspace tracks the outcome you are trying to reach: it holds the operational state you want, submits approved requests to the system of record, verifies the core actually reached that state, and creates work when reality does not match. Divergence surfaces as drift and becomes prioritized work — never hidden behind a completed task.

Who owns what

system of record

The Lending Core answers

What is owed, and as of when
What was disclosed and what was posted
Whether money actually moved

the operating layer

The Servicing Workspace answers

Why this work exists and who owes it
Whether this contact is permitted right now
What was decided, by whom, on what evidence

Neither side keeps a copy of the other's answer. The workspace asks the core what is true and the core asks nothing of the workspace — which is why a balance quoted on a call is the same balance the books close on.

How work moves

From a fact about a loan to a decision somebody made

Signalthe core reports something changedautomatic
Caseopened, or linked to one already openautomatic
Taskrouted to the queue that owns the workautomatic
Offeredto somebody eligible to take ita person
Checkedpolicy read at the moment of actingwaits
Outcomerecorded with its evidencea person

Every step leaves a record naming who acted and on which facts, so the question a complaint actually asks — why did this happen, and who decided it could — has an answer that does not require listening to a recording.

Automation comes in two forms

The workspace draws a hard line between two kinds of automation. Deterministic, policy-gated automation — reminders, notices, and routing — is templated and rule-bound, and each instance still passes a per-recipient compliance check. AI autonomy is different: an agent exercises judgment, bounded by its work packet and the autonomy ladder. You can run substantial deterministic automation well before AI autonomy rises.

Deterministic automation and AI autonomy must never be conflated. Templated, rule-bound work carries no AI judgment and stays compliance-checked per recipient; any work where an agent decides is governed as AI autonomy.