Main site

Retail AI agent · Loss prevention

Loss-Prevention & Shrink-Detection AI Agent

Detect shrink-relevant events from transaction and sensor data, hold each observation in an internal queue with its frames and its confidence, and leave every approach to the loss-prevention manager.

Typical delivery
4–6 weeks
Deployment
Your stack
LP manager
Identity-free
After launch
Agent Care

What this agent does

Observes an event, never identifies a person

In

  1. 01

    Ingest point-of-sale exceptions, sensor events and camera observations from supported retail and video sources.

  2. 02

    Keep every observation about the event itself, with no identity attached and no watchlist consulted.

Reason

  1. 03

    Score the event against the shrink patterns configured for that store, and rank the review queue.

  2. 04

    Attach the frames, the model version, the threshold and the measured error rate to each observation.

  3. 05

    Hold the observation inside the retailer's own systems, in an internal queue, and nowhere beyond it.

Decide

  1. 06

    Suppress its own alerting where image quality, confidence or cohort variance breaches its configured limits.

  2. 07

    Route every observation to the certified loss-prevention manager, who decides whether anyone is approached.

Out

  1. 08

    Retain the observation, its frames, its retention clock and the reviewer who closed it.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent describes an event; the loss-prevention manager forms the suspicion, decides any approach, and answers for it.

Example workflow

One observation, event to review

  1. 1Event receivedPoint-of-sale exception, sensor event, camera observation or an inventory variance
  2. 2Signals gatheredTransaction lines, the frames either side of the event, store layout and the retention clock
  3. 3Observation scoredEvent description, frames, measured error rate and confidence
  4. 4Suppression checks runIdentity-free checks, retention limits, cohort-variance limits and the confidence threshold

No human action required

Every stage before the confidence gate runs unaided, and nobody is approached at any of them — the agent is observing, and the manager's lane opens at the gate.

5DecisionBranches at the review threshold
Low ambiguity

Goes to the loss-prevention manager to review.

High ambiguity

Stays in the queue for later review.

Manager review

The observation is held with its frames, its measured error rate and the confidence.

Close · Investigate · Send to legal

Reviewed — closed or escalated

  1. 6Case systems updatedOnly where write access and approval policy allow it
  2. 7Case evaluatedUnfounded observations, reviewer closures, cohort variance and complaints received

Dismissals

Every reviewer closure is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Authorising an approach, stop, question or detention.
    • Confirming a match as the identification of a person.
    • Creating or sharing a suspect record beyond the retailer.
    • Contacting police or furnishing an identity to them.

  • Automation boundary

    Agent acts unaided

    • ✓Detect and log a shrink-relevant event to an internal for the named owner.
    • ✓Run transaction-exception analytics with no person into the review queue.
    • ✓Flag an inventory-to-sales variance for a human.
    • ✓Suppress its own alerting when quality.

    Any write happens inside the boundaries agreed at implementation, never ahead of the manager's review.

    • Issuing a trespass notice, a ban or a court petition.
    • Enrolling anyone into a biometric or watchlist database.
    • Changing a threshold, a model version or a camera location.
  • Resolving a complaint, dispute or reinvestigation request.

Example output

One observation, annotated

Everything the agent reports is attached to the event it was drawn from.

Observation output · single event

Illustrative example
Event
Self-checkout lane
What was observed
An item crossed the scanner unscanned and was bagged, in the frames either side
Subject
Not identified
Source of record
Lane log and lane camera
Confidence
74%
Where it went
Internal review queue

As received

Taken from the lane log and the frames around the event — nothing on this side is decided by the agent.

Evidence used

  • Transaction line
  • Frames either side
  • Lane exception history

Why this is an observation

It says what happened at the lane, not who did it and a person still decides.

What the score decides

Below the configured threshold the observation stays in the queue instead of reaching.

Action

CloseInvestigateSend to legal

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every event

From the lane and the sensor

03Observation

Describe the event

Draw on the transaction log, the frames around the event and the patterns configured for that store — never on a biometric template.

01Approved path

Look at events, not people

Routine exception analytics arrive already scored and already queued.

02Human review

Send review to what could reach

Under a biometric statute a shopper can sue on collection alone, and the count follows the footfall — so observations stay identity-free and the manager's read starts where the harm sits.

04

Build an evidence trail

Every observation keeps its frame, its retention clock and its reviewer.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Exception and shrink analytics

    • Sensormatic Shrink Analyzer
    • Zebra Workcloud Actionable Intelligence

  • Checkout vision

    • Everseen
    • NCR Voyix loss prevention

  • Video platforms

    • Verkada
    • Avigilon

Agent

Loss prevention and shrink detection

  • Reads the event
  • Scores the queue
  • Holds for review

  • Case management

    • ThinkLP
    • Appriss Retail

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and a person

Every layer wraps the next, and the map below names its blind spot.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeStop scoring and hold the queue when evaluation, image quality or cohort variance degrades.Roll back
L5Version monitoringTrack model, firmware, threshold and camera-location changes.Track
L4TraceabilityRecord the frames, the model version, the measured error rate and the reviewer.Record
L3Manager reviewHold observations for the certified loss-prevention manager; an alert is not reasonable suspicion, and only a person forms that.Gate
L2Policy guardrailsTest observations against the identity-free rule, the retention limits and the variance limits; a failure holds the observation.Restrict
L1Confidence thresholdsKeep low-confidence observations in the queue rather than in front of a reviewer.Require review
Model coreObservation produced — event description, frames, measured error rate and confidence
L1 – L2
Test whether an observation may stand
L3
Puts the decision in a trained reviewer's hands
L4 – L5
Preserve the frame, its clock and its reviewer
L6
Stops scoring and holds the queue

How Nestack evaluates it

Evaluate the whole observation path — not only the score at the end of it.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — what the reviewer is shown

  1. E1Final-output evaluationDid the observation describe an event a reviewer found had actually happened?
  2. E2Step-level evaluationDid the agent read the right transaction, the right frames and the right store configuration?
  3. E3Tool evaluationDid it write to the correct store, the correct queue, and nowhere outside it?
  4. E4Confidence calibrationDo low-confidence observations actually close unfounded more often?
  5. E5Slice evaluationHow does the unfounded rate change across specific shopper cohorts?
  6. E6Business outcomeHow many observations closed unfounded, and how many drew a complaint?

Floor — the person who gets approached

Failure modes

Where each failure originates in the agent

Seven modes, from detection to review.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • ZK-03

      Wrong frames attached

      Frames from another lane or another minute are bound to the event.

    Stage gathers

    Transaction logs, frames, with the source each came from

  2. 02 · Reasoning

    2 modes

    • ZK-04

      Assistive movement read as concealment

      A mobility aid, a carer's bag or a garment becomes a concealment signal.

    • ZK-06

      Unrelated events linked

      Separate events are joined into one pattern on a weak signal.

    Stage proposes

    Event description, frames and confidence

  3. 03 · Tool / write

    2 modes

    • ZK-02

      Record written outward

      An observation reaches a system outside the retailer before a reviewer read it.

    • ZK-05

      Alert lands on the floor

      An observation reaches a handset near the shopper instead of the review queue.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • ZK-01

      Score read as certainty

      A ranked observation is read as though it had named someone.

    Stage returns

    The observation the manager reads before deciding

  5. 05 · Change / Version

    1 mode

    • ZK-07

      Threshold moves unannounced

      An update shifts the threshold, and the rise lands on one cohort first.

    Stage tracks

    Model, firmware, thresholds and camera locations

  • Sev-1 · a held act performed by the agent
  • Sev-2 · an unfounded observation reaches
  • Sev-3 · image quality degrades
See the complete Retail failure-mode catalogue

Affected slices

The aggregate number is the problem

An aggregate unfounded rate can look tolerable while one cohort of shoppers carries several times it and another barely registers. Read as a lift on the all-event baseline.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Darker-skinned shoppers9.7%2.7×Review
Shoppers using mobility aids7.6%2.1×Review
Parents, carers and large-bag shoppers4.7%1.3×Watch
Lone adult shoppers, clear lit aisle1.8%0.5×Normal

Bar: unfounded-observation lift vs. the all-event baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Nothing here closes on an apology

Nothing is closed until the miss can be re-run against the next release and fails it That suite is what the following detection is measured against..

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Unfounded observations rise in one shopper cohort.

  2. 02

    Diagnose

    Which of them moved — the threshold, the camera, the image quality, or how the frames were read?

  3. 03

    Improve

    Version, reviewer and the frames behind the change stay together.

  4. 04

    Verify

    The gate is the case, not the reviewer — a fail holds it.

  5. 05

    Learn

    The case sticks, and the review threshold moves with it.

  6. Learn → Detect

    The return edge. The next detection is measured against a suite this cycle lengthened.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, observation workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Store and event-type discovery and boundary definition.Week 1
  2. 02Transaction and camera-source assessment.Week 1, Week 2
  3. 03Threshold, retention and variance-limit mapping.Week 1, Week 2
  4. 04Event ingestion and identity-free.Week 2
  5. 05Scoring logic and frame binding.Week 2, Week 3
  6. 06Confidence scoring and reviewer routing.Week 3
  7. 07Loss-prevention review.Week 3, Week 4
  8. 08Case-system and video integration.Week 5
  9. 09Paired-frame cases.Week 4, Week 5
  10. 10Guardrails and approach controls.Week 4
  11. 11Observation-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne store, one event typeProductionProduction store estateAdvancedMultiple banners / regions
Introduced at Pilot
Observation against your own patterns✓✓✓
Manager review✓✓✓
False-positive baseline✓✓✓
Introduced at Production
Reporting by site—✓✓
Reviewer workflow in your systems—✓✓
Approved internal write-back—✓✓
Case-system integration—✓✓
Introduced at Advanced
Multi-jurisdiction retention rules——✓
Multi-stage loss-prevention approvals——✓
High event volume——✓
Enterprise retention controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your event types and store configurations

    Event ingestion and identity-free normalisation

    Week 1

  2. 02Representative events already reviewed

    Observation baseline and frame binding

    Week 2

  3. 03Your retention clocks and variance limits

    Retention and variance-limit mapping, and automation-boundary definition

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Transaction, sensor and video-source assessment, then integration setup

    Week 2

  5. 05Approaches that were wrong

    Paired-frame cases and the evaluation suite

    Week 4

  6. 06What an observation must reach before anyone acts

    Review thresholds, approach routing and controls

    Week 3

  7. 07A named loss-prevention lead to review events

    Loss-prevention review workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases land on real weeks, so the fifth carries evaluation and pilot together rather than in sequence.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Event-type discovery, retention mapping and the automation boundary

W2Sensor and transaction feeds in place

W3Scoring logic, confidence scoring and review controls

W4Paired-frame testing and approach guardrails

W5Case-system integration, pilot stores and targeted corrections

W6A month of observations reviewed by loss prevention, then handover

Reading the band
Bars are the workstreams, not a smoothing. Week 5 holds two.
At the end of W6
Sign-off against real observations, then Agent Care monitors.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Retail AI agent

Build a shrink-detection agent around the manager who forms the suspicion.

Show us your event types, your camera estate and who is certified to approach a shopper. A stop that should not have happened cannot be withdrawn, and a false accusation of theft is defamation and unfair-practices exposure the moment it is made — so we set what an observation must reach first, and leave whether a shared suspect record is a consumer report to your counsel, because that question is unresolved.

Typical delivery
4–6 weeks
Deployment
Your case systems
LP manager
Identity-free
After launch
Agent Care available

Nestack Agents · Loss prevention and shrink detection

AGT-RT-12 · Agent Care available after launch

Build a shrink-detection agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your stores

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.