Sidekick
LEI issuance can take seconds — or days. The difference is almost never the work itself. This is the story of where the time goes, and how Sidekick helps get it back.
What is Sidekick?
Sidekick is a an agent augmentation platform. It works alongside existing tools and platforms. It provides a family of tools aimed at RA agents and Vetting agents. The tools gather evidence, and then provide an Overlay on the existing platform’s pages to allow agents to review evidence. It shows the agent which fields would be injected into, should the agent decide to accept the evidence. When accepted, the evidence is ingested into the platform with a single click. If rejected, we record the reason, so we can improve.
Sidekick integrates with the existing workflow engine and case management system. It does not replace them. It adds a layer of structured intelligence at order receipt.
Sidekick is NOT an AI black box, the agent is always in the loop. The evidence sources are recorded and can be ingested with the evidence making it Audit friendly.
Sidekick does not require that staff adopt any fundamentally different processes or tools. It does not become the tool of record, all evidence is still stored in the existing platform. Sidekick can be introduced (or removed) with minimal impact.
The platform has been designed to be highly extendable, and pluggable. If new Rapid API interfaces become available, we can simply switch the ingestion method, the tool does not break. If we need to add new forms or tools we can do that easily. If we want to extend the screen scraping tools, we have the core and diagnostic tools ready. If we want to add real time dashboards or power BI integration that’s straight forwards.
Sidekick measures its own performance with rich telemetry data, so the models on this page stop being illustrative and start being facts.
Benefits
Sidekick produces linked improvements to the LEI operation. They compound.
- Easy cases never wait for an agent. If we need to ask the customer, we aim to do so immediately, regardless of queue length or time of day.
- Freed capacity drains the backlog non-linearly. When a team is at or near capacity, removing a fraction of the inbound volume has an outsized effect on average wait time. Agents have headroom for the cases that need them.
- The expensive long tail shrinks. Hard cases — needing multiple customer contacts — are identified early and staged fully before an agent touches them.
- One customer interaction replaces several. Sidekick composes a single, structured evidence request covering every gap it can identify, rather than letting agents discover them one at a time. First-pass completeness rises; round-trip count falls.
All four effects are modelled on the pages below. Every figure is yours to set.
Features
Observability by default
Every action Sidekick takes is logged with a reason code. The aggregate of those logs is what feeds the models on this page — and what will eventually replace the illustrative assumptions with measured ones.
How it fits in
Sidekick can receive an event when an order is created, runs its assessment, and follows one or more workflows to gather evidence.
One of the key enablers is the use of a small browser extension that runs on the agent’s machine. It is aware of the when the agent is on the relevant page. It presents a small side panel, on which the agent can view and accept or reject evidence.
About Breeze Identity
Sidekick didn’t come from a whiteboard. It came from years inside CA vetting operations — running the queues, owning the performance numbers, and feeling first-hand where the hours actually go. I introduced CRM-based case management to bring order to that work, and I’ve sat on the audit side too, which is why evidence, traceability, and defensible process are built into Sidekick from the start rather than bolted on. Data driven metrics are foundational in making process improvements, so sidekick measures everything. That operational grounding is paired with a genuine care for the people at both ends of a case: the applicant who deserves a clean, un confusing experience, and the agent whose scarce attention shouldn’t be spent on what a machine could have prepared. I build to engineering best practice — properly architected, maintainable, honest about its own limits — and I have a real appreciation for what good tooling does for a team, because I’ve lived the difference between fighting your tools and being carried by them. Sidekick is what I wish I’d had.
Where does the time go?
Most of the time an LEI case spends in the system is not spent being worked. It is spent waiting — in a queue for an agent, or for a customer to reply. Actual agent effort is a small fraction of the total. That gap is the opportunity Sidekick is designed to close.
The sections below model each part of that gap. Every figure is illustrative and framed around the case, not the individual agent — adjust the sliders to reflect your operation and see each effect respond.
A case is three clocks, not one
When we talk about “how long issuance takes,” we’re actually jumbling three very different things, untangling them brings clarity.
There’s the queue — time a case sits waiting for an agent to pick it up. There’s active handling time — the agent actually doing the work. And there’s waiting on the customer time — the ball in their court after we’ve asked a question.
They run on completely different scales: handling is minutes, the others are hours and days. And they answer different questions — customer experience versus the cost of running the operation.
And there is one more thing that we have not even modeled; we talk here about time, but we are really talking working hours time. In reality, agents and customers stop working at Lunchtime, in the evenings and they go away at the weekends, but the case clock is still clicking. Anything that can be done that means that a question is asked of a customer before they loose context, go home or pack up for the weekend has the potential to knock a day or more off the issuance time. Sidekick can do this by making decisons and asking the customer for more information in minutes of order receipt, while the customer is still at their desk and has the LEI order in mind.
Here is a single case, end to end. It’s a “manual director search” — the kind where the registry has no clean API and someone has to do a paid lookup, or find some other equivalent method to prove Empowerment. Toggle Sidekick to see what changes.
Where the time actually goes
A single LEI case, end to end. The same case takes days — but real agent work is a tiny sliver of it. Toggle Sidekick to see the front queue element disappear.
Illustrative figures modelling a "manual director search" case archetype. Segment durations are adjustable to match real cases as data firms up. Times reflect the case, not any individual agent.
The case takes the better part of a week, and the actual agent work is a sliver of it. Sidekick’s first contribution is to act at order receipt rather than at case open — gathering the evidence and running the checks before a human is ever needed, so the call to action reaches the customer without sitting in a queue first.
Notice what we don’t claim. The re-queue after the customer replies is unchanged. That wait isn’t a property of this case — it’s a property of how busy the team is. Which brings us to the second clock.
Why the backlog explodes
Queue time has a nasty habit: it doesn’t rise gently as the team gets busier. At near full capacity it goes vertical. This isn’t a Sidekick claim — it’s the same mathematics behind every call centre and supermarket checkout. Wait time scales with utilisation as ρ/(1−ρ), and that denominator runs to zero as you approach capacity.
Drag the volume up toward “overwhelmed” and watch it happen. Then toggle Sidekick — which adds no agents at all. It simply cuts the effort each case needs, by an amount you set, which slides the whole team back down the curve, away from the cliff.
Why the backlog explodes — and how it drains
Queue time doesn't rise gently with volume. Near full capacity it goes vertical. Sidekick doesn't add agents — it cuts the effort each case needs, sliding the team back off the cliff. Drag the volume; toggle Sidekick.
The curve is queueing theory, not a sales claim. Wait grows with ρ/(1−ρ) — it's the same maths behind every call centre and checkout queue. Sidekick's only move is to slide the dot leftward along it by returning capacity. Near the cliff, a modest effort saving collapses the backlog far more than proportionally. That's the win the single-case timeline couldn't show.
Illustrative model: 8 agents × 360 productive min/day. Effort-per-case is a blended tariff across archetypes. All parameters adjustable to real ops figures. Measures the system, not individuals.
This is the second-order win, and it’s the larger one. Every minute of agent effort Sidekick removes is capacity returned to the queue. When a team is near saturation, a modest effort saving collapses the backlog far more than proportionally — because you’ve moved them off the steep part of the curve. The single-case timeline couldn’t show this, because it’s a property of the whole system under load, not of one case. So we measure the case, and model the system.
But this raises the obvious question: where does that effort saving actually come from? It isn’t spread evenly across every case.
Your cases aren’t one population
Treating cases as a single average hides the truth. The reality is a tall spike of easy cases — clean registry APIs, everything automatable — and a long, fat tail of hard ones where directors must be looked up by hand or whole jurisdictions have no API at all, or there are other snarly complications, like L2 or Trusts and Funds.
That shape is why the average misleads. The mean is dragged to the right by the expensive tail, so “average handling time” overstates the typical case and understates the painful one. The honest move is to tariff each archetype separately.
Sidekick’s effect here isn’t a uniform reduction. It’s a shape change — cases it can resolve at order receipt jump out of the tail and into the clean bucket. Set how many you believe it can resolve, and watch the fat tail thin and the clean spike grow.
Your cases aren't one population
A clean spike plus a fat manual tail. Sidekick doesn't shave every case the same — it moves cases out of the tail into the clean bucket by resolving them at order receipt. Watch the shape change, not just shift.
This is why the average lies. The orange mean sits well to the right of the black median — dragged out by the manual tail. Reporting one "average handling time" hides both the easy majority and the expensive minority. Tariff each archetype separately and the blended cost is just a volume-weighted sum.
Illustrative: 1,000 cases, four archetypes. Reclassification fractions are modelling assumptions — the real ones come from measured probe-success rates per jurisdiction. Distribution is of the case population, not individuals.
The median barely needs to move. It’s the expensive P90 cases — the ones that were dragging the average and consuming scarce agent time — that collapse toward the clean path. That tail-collapse is the effort saving the queue model assumed. The two views are the same fact seen from two angles.
There’s one more force that the forward-flowing story has so far ignored — and it may be the biggest of all.
A re-ask costs days, not minutes
Cases rarely flow forward cleanly. When the customer’s reply comes back incomplete, the case loops: another customer wait, another trip through the queue, another touch. And here’s the cruelty of it — a re-ask costs the agent a minute of extra effort but costs the case days of wall-clock, because each loop re-incurs the slow clocks.
So the most powerful lever on issuance time isn’t handling the case faster. It’s asking the customer the right, complete set of questions the first time, so the loop never happens. Sidekick’s structured, mandatory-field forms exist precisely to raise that first-pass completeness.
Every assumption below is yours to set — nothing is pre-judged. And note the fairness of the comparison: every duration is identical whether Sidekick is on or off. A re-ask costs exactly the same. Sidekick’s only job is to make it rarer.
A re-ask costs days, not minutes
When a customer reply is incomplete, the case loops — another wait, another queue, another touch. Sidekick's structured form raises first-pass completeness, making the loop rarer. Every duration below is yours to set.
Loop maths: a clean single pass needs all items complete (completenessitems); expected customer cycles = 1 ÷ that probability. Durations OFF and ON are identical — Sidekick changes only first-pass completeness. Figures describe the case, not individuals.
What Sidekick is actually doing
Put the four together and the story isn’t “a tool that handles cases.” It’s four linked mechanisms:
- It acts at order receipt, so easy cases never queue for a human at all.
- It returns capacity, which drains the backlog non-linearly when the team is under load.
- It collapses the expensive tail by resolving hard cases up front.
- It raises first-pass completeness, so a single customer interaction does the job instead of three.
None of these replaces the core system, the workflow engine, or human judgement. Sidekick stays quiet when it has nothing useful to add, and measures even its own silence. The win is speed, consistency, and the agent’s scarce attention spent where it genuinely matters.
Next: measurement
These models are only as good as the data behind them. The next step is instrumenting the real workflow — which state transitions we can detect deterministically, and which we must infer — so the figures on this page stop being illustrative and start being measured.