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.

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.

Sidekick high-level topologyBrowser extension and admin panel connect to a central server, which exposes a pluggable connector layer in two rows: live connectors are Rapid GUI, LEI plugin, Cognito Forms (send and ingest), company registries and web search and scrape; future connectors are Rapid API, email sensing and Zendesk.Browser extensionOperator workspaceAdmin panelConfig & oversightServerOrchestration coreConnector layerPluggable interfaces — extend as neededRapid GUIDOM read / writeLEI plugin (WP)New order detailsCognito FormsSend / ingestRegistriesLookup sourcesWeb search & scrapeFind, screenshotRapid APIFuture uploadEmailFutureZendeskFuture — vettingSolid = live · dashed = future
Sidekick functional hierarchyPlatform at the top, two applications (RA Assist live, Vetting Assist planned), MVP tools plus future registry scraping and guidance, an ECI use-case row beneath evidence collection and ingestion with trust/fund future, and shared platform components including DOM read/write paired with the per-application DOM map.PlatformApplication-agnostic — RA Assist is one of severalRA AssistMVP targetVetting AssistPhase 2ToolsTyped interfaces on the platform — more can be addedRegistry lookupSigning authorityEvidence collection & ingestionWebsite associationRegistry scrapingGuidanceECI use casesEvidence collection & ingestion runs the ECI pattern — more can be addedLOA / POAL2 / UBOTrust / fundPlatform componentsShared infrastructure — every tool and application builds on theseDOM read / writeDOM map — 1 per appTool engineCaseTriggerPolicyQuiet-by-default filterContribution telemetryCaseEventLogExtension frameworkConfiguration layerSolid = live · dashed = future

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.

Sidekick · Case Issuance Analysis

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.

Sidekick OFF
Manual workflow
Standard workflow
Total issuance
4.5 days
2 days
1.5 days
1 days
In queue· waiting for an agent
Active handling· agent working the case
Awaiting customer· ball is in their court
Final QC· internal checks
Total issuance
4.5 days
Agent handling
16 min
Queue time
3 days
The point
0.2%
of total time is real agent work

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.

Sidekick · Capacity & Backlog

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.

Sidekick OFF
9 min effort / case
01d2d3d4d100250400550Case volume (per day)Avg backlog waitbacklog growing faster than the team can clearunbounded
Avg backlog wait
Team utilisation
138%over capacity
8 agents, unchanged. Sidekick adds no headcount — it cuts effort per case from 9 to 4.5 min.
Case volume440 / day
quietbusyoverwhelmed
Effort reduction from Sidekick — set your own assumption50%
9 min → 4.5 min per case. Drag it to a figure you'd defend — the curve responds honestly.
nonemodestaggressive

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.

Sidekick · Case Mix

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.

Sidekick OFF
48% of cases clean
How many tail cases does Sidekick resolve? — your assumption100%
Scales how often a "maybe-available" registry actually resolves cleanly. At 100% the full model applies; drag it down to a rate you'd defend and watch the tail respond.
no effectcautiousfull model
0369121518Agent effort per case (minutes)Number of casesmedian 2.8mmean 5.0m
Clean — full API· 480
Partial — officer API only· 220
Manual director search· 200
Scrape-only jurisdiction· 100
Typical case (median)
2.8 min
Average (mean)
5.0 min
The expensive tail (P90)
11.8 min
Cases on clean path
48%

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.

Sidekick · Round-Trip Cost

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.

First-pass completeness (per item)90%
Sidekick completeness uplift+7 pts
Items asked of customer1 item
Customer wait (per cycle)1.5 days
Queue wait (per episode)1.5 days
With 1 item, a clean single pass needs every item complete: 90% likely (OFF), 97% (ON).
Expected issuance · OFF
4.8 days
1.11 customer cycles avg
Expected issuance · ON
4.6 days
saves 5.8 hr on average
Re-asks avoided
72%
fewer expected round-trips
How often each scenario happens
OFF
90%
9%
ON
97%
Clean pass1 re-ask2 re-asks3+
What a single case looks like
Clean pass · 4.5 dayshappens 90% OFF · 97% ON
1.5 days
1.5 days
1.5 days
In queue
Active handling
Awaiting customer
Final QC

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:

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.