Peregrine Runs the Data Business Backwards: It Doesn't Collect Data, It Only Connects It
Most public safety companies make money by collecting more data and then selling more collection gear; Peregrine inverts the model — it doesn't move new data into customer systems, it connects the data customers already have, and wins on governance and permission control.
The video won't play here. Listen to the audio instead:
The argument · tap a timestamp to hear it
The direction of the data business has been flipped
Nick describes the business model of the previous generation of public safety companies (the Flocks, the Axons) bluntly: hardware or software goes into the customer, and what's really being sold is "input" — sensors passively collecting, or people manually entering, and then collecting and storing that information. Once data is in their systems, plus distribution advantages, they can keep selling more, and what they sell more of is often more collection systems. Peregrine is the inversion of that model: it's not in the business of bringing more data to the customer, but of connecting the scattered information the customer already has, building a well-governed layer on top of existing systems so answers are more precise. Ben adds the key point: the fundamental problem is that customers can't use the data they already have, or can't use it in a way that's high-trust with the community.
— Nick NooneData belongs to the customer, or it's a surveillance state
Ben on data ownership: every customer, every agency owns its own data — that's the community's data, the agency's data, not Peregrine's data. What Peregrine provides is control and permission capability, so an agency can roll out safely within its own department and, when needed, share only the selected piece of information. Nick gives a very concrete counterexample: without this kind of solution, people put a bunch of data in the trunk of a car and drive across the whole city — that approach actually has weaker control. So their design goal is to let users "not over-share," and to trust what they hand over.
— Ben RudolphFrom "nice search" to analysis nobody has done before
Ben splits the usage curve into two phases: right after deployment, users get only "nice search," like looking up an address without scrolling through rows, with results neatly formatted. Once users are fluent, the floor for the whole department is raised, and deep analysis that was previously impossible starts appearing. He cites a Florida county: in one month they had over a hundred water rescues, and they asked why there had never been this many before. The agent did deep research and the pattern it produced was — this weather pattern had never occurred three days in a row, and three days in a row forms a sandbar trough, a sandbar trough is the perfect condition for a rip current, and the rip current is what got people in the water in trouble. That conclusion is actionable for the agency, and can be layered onto their own terrain maps. Nick adds: sitting at headquarters brainstorming, we could never have come up with this.
— Ben RudolphWhat keywords can't find, semantics can
Another case: a detective investigating a threat against a synagogue wanted to know whether other antisemitic threats had occurred before at these two synagogues in the same area. Ben points out: as a detective, what keyword would you even search? Keywords are actually very bad at finding this kind of information. AI lets the detective do semantic understanding over the information they have access to, and it pulled out a pattern of threats against these synagogues. The point here isn't "AI is stronger," it's that this kind of investigation was simply impossible with the old tools — the problem isn't compute, it's the retrieval method.
— Ben RudolphNinety percent of integration code is written by agents
Nick breaks down what the Peregrine platform is made of: about 50% of engineers spend most of their time on the data platform, letting deployment teams integrate the data customers already have, and they've integrated tens of thousands of datasets cumulatively. They built an agent so the deployment strategy team can do integrations agentically, with an eval set that can deterministically assess these agents' completeness and correctness on integrations. Now about 90% of integration code is written by agents and supervised by the deployment team. These agents run for hours: analyzing databases, understanding the ontology, piecing together what needs to be integrated, then spawning sub-agents to do the work and reporting back to the orchestrator agent. Nick says the nice thing about this problem is that it's verifiable, so it's easier than other agent problems — which is also why coding agents are relatively easy.
— Nick NooneThe cold case agent first reproduced an old case's conclusion
The first end-user-facing agent was the cold case agent. Scale of the background: a high-profile investigation means uploading 200 to 300 GB of data, including video, audio, images and a large number of PDFs, and the detective has to go through it themselves. They first did it together with a customer — that customer had worked a wrongful conviction case and cleared the person's name, and the customer asked: can you use an agent to reproduce this result? They fed in all the evidence and data from that case, built an agent that runs 30 to 60 minutes, and it ultimately reproduced the conclusion the detectives had reached at the time. Now this agent is used in several departments across the US. A Wisconsin county had a similar case, 300 GB of data, and using a small number of cell phone call detail records scattered across a huge amount of data, it located the suspect at the crime scene and at the place where the body was found.
— Ben RudolphAnti-network effect: the more you protect data, the harder you are to swallow
Nick says that putting together the two forces of "centralized authoritarian AI capability" and "surveillance" creates enormous public distrust of AI, and that can't be ignored. He acknowledges these agencies themselves have extremely strong network effects — an organization looking for a shortcut can easily pull data from open source, and whether that data can or should be accessed may be a gray area in laws, ordinances, and departmental standard operating procedures. Peregrine's position is the opposite: data must be protected, and these agencies that by their structure have amazing network effects must be protected. He calls this the "anti-network-effect proposition" — how do you preserve the sanctity, ownership and way of doing things of each agency's data while still building connective tissue and interoperability. And that's exactly why data governance and permission logic become extremely important in the AI context.
— Nick NooneFacial recognition shouldn't have its line drawn by a Silicon Valley company
Asked about morally nuanced technology decisions like facial recognition, Nick's answer is: a Silicon Valley company imposing some general decision on an entire industry is fundamentally wrong. They don't assert for customers whether a technology can be used or how retention policy should be set; instead they help customers understand their own context, lay out considerations the customer may or may not know about, and then help them implement it — which takes patience. The fact he gives: most public safety agencies in the US and their communities choose not to implement facial recognition, some with very hard positions, some just by subjective preference. Drawing a technical red line without understanding the specific texture and context isn't something they can do for the customer.
— Nick NooneTo change a field, someone used comments as a database
Nick talks about how the FDE movement influenced the product, in two categories. The first is what foundational primitives the platform needs. One example: for a long time Peregrine had no ability to edit specific fields and attributes, so a forward deployed engineer worked around it — using the comments people wrote on objects as an integration, which Peregrine read to update attributes, and that's how they implemented "editing." The team saw it and said, we need to implement editing. Nick says the reason that colleague did it that way is exactly how they bring people up: your job is to hit the goal, screw the technology. The second category he calls the innovation lab: deployment strategists build things that are completely unique and most likely never merged back into the product, serving only that one customer. He recently saw a deployment strategist build a hurricane simulator inside Peregrine, and a woman one month into the job build a tool that integrates data from different sources like 911 call times and budgets, so that dropping a fire station into a city estimates how many people it affects.
— Nick NooneIn their own words · checked verbatim
most of the companies that have come before us have built their business fundamentally on the back of data collection
Nick Noone18:21
we are actually not in any shape or form in the business of bringing more data to the customer that they don't already have
Nick Noone19:27
each customer, each institution owns their own data. This is ultimately that organization is serving the community. That is the community's data. That is the organization's data. It's not Peregrine's data.
Ben Rudolph21:35
About 90% of that is written by agents with the oversight of our deployment team.
Nick Noone30:57
we have to protect the data, right? And we have to protect these organizations that by virtue of their structure have astounding network effects, right? It's almost like the anti-network effect proposition.
Nick Noone36:13
the idea of creating, you know, a technological red line without understanding the texture and context is is not not a boundary line that we think that we can assert on top of our customer
Nick Noone39:34
your job is to hit the objective, like to hell with the technology
Nick Noone47:17
Figures
| Peregrine founding date | February 26, 2018 | 11:03 |
| Number of rejections | over two dozen | 10:45 |
| Share of integration code written by agents | about 90% | 30:57 |
| Cold case agent runtime | 30 to 60 minutes | 33:02 |
| Share of engineers on the data platform | about 50% | 29:59 |
| Water rescues in a single month in a Florida county | over one hundred | 23:38 |
Glossary
- forward deployed engineering
- A way of working where engineers go directly into the customer's site, take on the problem together with the customer, and deliver results.
- anti-network-effect proposition
- A strategy that doesn't rely on data centralization to produce network effects, but instead protects the independence of each agency's data.
- ontology
- A structured definition of data entities and their relationships, for agents to understand and integrate.
- rip current
- A strong current flowing from the shore out to sea, one of the main causes of beach drownings.
How to listen
Founders and investors doing AI deployment, public sector, or To B in heavily regulated industries, especially anyone interested in how agents actually run inside real institutions.
The founder background and UNHCR, Dimagi experience from 0:00-8:25 at the start is low density; you can jump straight to 10:45.