AI Apps and Agents
The IndoAI App Catalogue
IndoAI AI camera apps are installable computer vision models that run on IndoAI cameras or the Edge Box. An agent bundles models with orchestration rules, SOP workflows and reporting, so it does not merely detect an event: it routes it, tracks it to closure, and reports on it weekly.
Three words that get used interchangeably, and should not be
- Model
- A single trained network that answers one narrow question about a frame. Is there a person. Is that person wearing a helmet. What are the characters on that number plate.
- App
- A model packaged so it can be installed, updated and removed on a specific piece of hardware without a site visit. IndoAI calls this Appization.
- Agent
- Models plus orchestration rules, plus the SOP workflow for what happens after a detection, plus the reporting that closes the loop. An agent is scoped to an outcome, not to a detection.
Why the distinction matters more than the model count
Vendors compete on model counts. IndoAI's platform runs 65 or more models, and that number is genuinely useful shorthand for breadth. It is also, on its own, close to meaningless as a purchase criterion.
A model produces a detection. A detection produces a notification. A notification that nobody acknowledges is not security, it is noise, and a system generating hundreds of unacknowledged notifications per day is worse than no system at all because it teaches your team to ignore the screen.
The operational question is not how many things the platform can detect. It is what happens in the ninety seconds after it detects something. That is the gap an agent fills: detect, package the evidence, route it to the person who owns the response, track it to closure, and summarise the week so thresholds and routing improve.
The agents
Agents are assembled around a situation rather than a technology. Each one bundles the models that situation needs, the rules for when a detection matters, the workflow for who is told and in what order, and a recurring report.
Retail Loss Agent
Built for shrinkage in stores where the loss is distributed across many small events rather than one dramatic one.
- Theft cues
- Staff movement anomalies
- Queue spikes
- Evidence packs
- Weekly shrink report
Factory Safety Agent
Built for sites where a safety lapse is both a human risk and an auditable compliance failure.
- PPE compliance
- Restricted zone entry
- Fire and smoke detection
- Incident capture
- Compliance reports
School and College Operations Agent
Built for campuses where the concern spans attendance, gate control and student welfare at once.
- Group attendance capture
- Visitor and gate tailgating alerts
- Corridor fight and violence cues
- Fire and smoke detection
- Weekly safety and exception report
Housing Society Safety Agent
Built for gated communities where the security team is small and the traffic through the gate is constant.
- Resident, staff and vendor recognition
- Visitor approval workflow
- Vehicle entry watchlist
- Perimeter after-hours intrusion
- Daily security summary report
Every agent above includes evidence packs and a recurring report, because those two components are what turn detections into something a manager can act on and an auditor can accept.
The underlying model categories
Agents are assembled from a common catalogue. If your situation does not match one of the packaged agents, the models are still available individually and can be combined into a configuration specific to your site.
| Family | What it answers | Typical use |
|---|---|---|
| Object and person detection | Is something present, where, and for how long | Intrusion, loitering, restricted zones, occupancy |
| PPE and compliance | Is the required equipment being worn | Helmets, vests, gloves, footwear on shop floors |
| Fire and smoke | Is there visible flame or smoke, now | Warehouses, plants, corridors, server rooms |
| ANPR | What are the characters on that number plate | Gate control, parking, logistics yards, tolling |
| Face and identity | Is this a known person from an enrolled set | Attendance, access control, watchlists |
| Counting and flow | How many, in which direction, at what rate | Footfall, queue management, throughput |
| Behaviour and anomaly | Is this pattern unusual for this place and time | Theft cues, fights, unusual dwell, process deviation |
| Vehicle and asset | What class of vehicle or asset, doing what | Yard management, forklift zones, dock scheduling |
Terminology used above is defined in the IndoAI glossary, which covers ANPR, RTSP, ONVIF and the rest of the vocabulary buyers encounter in tender documents.
How AI camera apps get onto your hardware
The reason this catalogue is usable rather than theoretical is the delivery mechanism. Apps are containerised and installed over the air onto hardware already deployed at your site: an IndoAI camera, or the Edge Box handling streams from cameras you already own.
Adding a capability is an install, not a procurement cycle. No engineer visit, no rack change, no new tender, and no replacement of the capture layer. A site running PPE detection that later needs fire and smoke detection adds the second app to the same box.
This is what the term Appization describes: treating vision models the way a phone treats applications, with an install, an update path and a removal, rather than the way the industry has historically treated them, as firmware baked into a device at manufacture.
| Conventional | Appization |
|---|---|
| New analytics means new hardware or a new server | New app on hardware already installed |
| Site visit and reconfiguration | Over-the-air install |
| Fresh procurement approval | Addition to an existing platform |
| Capability fixed at purchase | Capability changes as the site's needs change |
Choosing apps by outcome rather than by feature list
The most common procurement error is specifying a feature list rather than an outcome. A tender asking for twelve named analytics will get twelve named analytics, most of which will be switched off within a quarter because nobody owns the alerts they generate.
A more useful sequence is: name the outcome, identify who acts when it occurs, define what evidence that person needs, and only then select the models. An agent that fires accurately but routes to a mailbox nobody reads has failed, regardless of its detection accuracy.
The AI Advisor works in this order deliberately. It starts with the business risk described in plain words, maps that to what the cameras must resolve, and arrives at models last.
A worked example
A 40-camera factory wants to reduce recordable safety incidents in the loading bay. The feature-list approach specifies PPE detection across all 40 cameras, generating alerts nobody has time to review.
The outcome approach observes that incidents cluster where forklifts and pedestrians share space during shift change. That narrows the requirement to six cameras covering two zones, running PPE detection and restricted-zone entry, with alerts routed to the shift supervisor's phone rather than to a central mailbox, and a weekly exception report to the safety officer.
Fewer cameras carry the analytics, alerts are few enough to be acted on, and the weekly report gives the safety officer something to take to a review meeting. The first approach produces a larger invoice and a system that gets ignored by month three.
What runs where
Two deployment surfaces exist, and the choice between them is usually decided by what is already on site.
On the IndoAI camera
Inference runs on the camera itself. Suits new deployments and situations where you want intelligence at the point of capture with minimal additional infrastructure.
On the Edge Box
The 16-channel Edge Box ingests RTSP and ONVIF streams from cameras already installed, whoever made them, and runs the models centrally on site. Analog estates connect through an encoder.
Both surfaces feed the same dashboard at app.indo.ai, and both keep video on the premises. The full sequence from site description through to a running system is set out in how IndoAI works.
Data protection considerations by app family
Not every model carries the same regulatory weight. Counting people crossing a line is a materially different processing activity from identifying a named individual, and the two should not be procured with the same casualness.
DPDP Rule 4 commences on 13 November 2026, and organisations will need to be able to describe what they collect, why, for how long, and on what lawful basis. Face and identity models generally warrant a documented impact assessment before deployment. Running inference on site narrows the exposure considerably, because the hardest questions concern personal data replicated to infrastructure you do not control, but it does not remove your obligations around notice, retention, signage and lawful basis.
If an app can attach a name to a person, treat it as a separate procurement decision with its own assessment, its own retention policy and its own sign-off. If an app produces counts, classes or events without identifying anyone, the obligations are lighter. Mixing the two into a single blanket approval is how organisations end up with commitments they cannot evidence.
The honest limits
Models cannot fix placement. No app recovers detail the sensor never captured. A camera under-specified for its distance, or aimed into glare, produces footage no model can rescue. Placement is decided before any app is chosen.
Accuracy is site-specific. Any vendor quoting a single accuracy percentage without naming the conditions is quoting a benchmark, not a prediction about your site. Lighting, camera angle, occlusion and the base rate of the event all move the number.
More apps is not better. Every additional app adds alerts. Beyond the number your team can genuinely act on, each addition reduces the system's effectiveness rather than increasing it.
Behaviour models produce cues, not verdicts. A theft cue is a prompt for a human to look, not a determination that theft occurred. Treating cues as conclusions creates both operational and legal risk.
Channel capacity is finite. Each box has limits on how many streams can run how many models concurrently. Adding apps to a saturated box means adding capacity, and the design should say so before you order.
Frequently asked questions
What is the difference between an AI model, an app and an agent?
A model answers one narrow question about a frame, such as whether a person is wearing a helmet. An app is that model packaged so it can be installed, updated and removed on your hardware without a site visit. An agent bundles several apps with orchestration rules, an SOP workflow for who responds, and recurring reporting.
How many AI models does IndoAI offer?
The platform runs 65 or more models across detection, recognition, counting, ANPR, fire and smoke, PPE compliance, behaviour and vehicle categories. The count is useful shorthand for breadth, but it is a poor purchase criterion on its own. What determines value is which models match your outcome and what happens after they detect something.
Can I add a new capability after the system is installed?
Yes. Apps are containerised and installed over the air onto hardware already on site. Adding a capability is an install rather than a procurement cycle, with no engineer visit and no change to the capture layer. The practical constraint is channel capacity on the box rather than the addition itself.
Do the apps work on cameras IndoAI did not supply?
Yes, through the Edge Box. It ingests RTSP and ONVIF streams from cameras already installed regardless of manufacturer, and analog systems connect through an encoder. Models then run centrally on site. Apps can alternatively run on the IndoAI camera itself for new deployments.
How accurate are the models?
Accuracy is site-specific and depends on lighting, camera angle, occlusion and how frequently the event actually occurs. A single headline percentage quoted without those conditions describes a benchmark rather than a prediction about your premises. Realistic expectations come from the design stage, where placement and conditions are assessed.
Should I install every app that looks useful?
No. Every app adds alerts, and beyond the volume your team can genuinely act on, additional apps reduce effectiveness rather than increasing it. The useful test is whether a named person will act on each alert type within a defined time. If not, that app should wait.
Which apps need extra data protection consideration?
Any app that can attach a name to a person, principally face and identity models. These generally warrant a documented impact assessment, their own retention policy and separate sign-off. Apps producing counts, classes or events without identifying individuals carry lighter obligations, and the two should not share a single blanket approval.
Can IndoAI build a model for something not in the catalogue?
Custom and build-to-suit models are part of the platform. Whether a custom model is the right answer depends on whether the requirement is genuinely novel or whether an existing model configured differently would serve. The design stage is where that gets established, because a custom model carries longer timelines than an install.
What is included in an agent beyond the models?
Orchestration rules determining when a detection matters, an SOP workflow defining who is notified and in what order, evidence packs assembled automatically around each event, and a recurring report. Those components are what convert detections into something a manager can act on and an auditor will accept.
How many apps can run on one Edge Box?
It depends on the number of streams and the models involved, since concurrent inference across many channels consumes finite capacity. The design stage sizes this explicitly, and where a requirement exceeds what one box can handle, the design states that additional capacity is needed rather than leaving it to be discovered after installation.
Do apps update automatically?
Apps are delivered and updated over the air, which is the core of the Appization approach. This means model improvements reach deployed sites without a truck roll, and a site installed two years ago is not stuck with the models available at the time of purchase.
Where do I start if I am not sure which apps I need?
Start with the outcome rather than the app list. Describe the site and the concern to the AI Advisor in plain language, and the design works backwards from the outcome through camera placement to the models required. Selecting models first, before placement is established, is the most common and most expensive sequencing error.
Describe the outcome. The apps follow from it.
Tell the AI Advisor what your site looks like and what concerns you. You will get camera placement, the models each camera should run, and an installation plan, in that order.
Open the AI AdvisorRelated reading: how IndoAI works, end to end, Appization explained, the IndoAI Edge Box, and the AI vision glossary.
Chief Strategy Officer at IndoAI. He holds a PhD alongside an MBA and a B.Tech, and has spent more than two decades in business development and IT security across technology and non-technology sectors. He reviews IndoAI's published technical claims.