For a long stretch of Peregrine's life, its software could not edit a field. Anyone working inside the platform who wanted to change a property on a record had no way to do it.
One of the company's forward deployed engineers worked around the gap. People could still leave comments on objects in the system, so the engineer built an integration that read those comments and used them to update the underlying property. Comments went in; edits came out.
"We saw that and we're like, we need to implement editing," one of Peregrine's co-founders said on the Training Data podcast. In the founders' account, the workaround looked hacky and unscalable, and that is part of what made it useful: "It's great signal for what actually works, and it's like the quintessential rapid prototyping."
Peregrine sells software to American cities, counties and states (police departments, fire departments, emergency medical services). The software pulls together records those agencies already own so staff can search and act across them. The people it sends into those buildings are called forward deployed engineers, or deployment strategists. They are engineers who sit with the customer, learn how the place works and build inside the customer's environment rather than shipping a finished product from headquarters.
Many software companies treat that work as a cost of doing business. Asked about it, co-founders Nick Noone and Ben Rudolph called it something else: "Definitely R&D, definitely R&D and growth."
The lesson from Palantir: own the problem, hand over the win
Before founding Peregrine, Noone ran Palantir's unit serving US Special Operations Command and deployed into the Middle East. He said he had never heard of forward deployed engineering before joining. He watched colleagues leave the office for customer sites and come back with stories, and it looked like "the adventure of a lifetime."
Two things stuck with him. The first is that the team psychologically owns, or co-owns, the customer's problem and gets "all the way to the outcome". Ideally, he said, it gets there three to five times faster than any other person or team could. The second is that the credit does not come home with you: "at the end of the day, it's the customer's win. It's not our win."
In his account, what Silicon Valley gets wrong is the speed at which outsiders think they can absorb a place. One example is sending very smart graduates into an organization like the LAPD to understand thirty years of institutional context: not only the data, but how decisions get made and how teams work together. Assuming they can move fast strikes the customer as implausible, and it reads as ego to people who have spent their careers inside that institution. Suspending that ego, he said, is easy to say and is "such a high-empathy, patient way of working."
Rudolph has described the same work in writing. In a March 2026 piece, Operational AI requires a foundation, he framed deployment as translating local institutional knowledge into the system: learning that a department says "graves" when it means overnight shifts, or that the weekly briefing should be scheduled for Sunday evening rather than Monday morning.
Two dozen refusals, then a desk in San Pablo
The patience was not optional at the start. Noone said more than two dozen people said no ("it's such a blur at this point, but it's definitely over two dozen") before one said yes. He dates the company to 26 February 2018. That was the day the San Pablo Police Department in Northern California let the founders into the building with badges, desk space and access to information so they could get to work.
They got there by researching subject matter experts in municipal public safety. They found an article about a young commander, Brian Bubar, rising quickly through a rigidly ranked paramilitary organization. The article described Operation Red Reach, a cross-jurisdictional gang and narcotics investigation in Northern California. Noone said they simply called him. They told him they did not know much but might have some utility, and asked whether they could come in, ask questions, learn and maybe build something over time.
Earlier, still in what the founders called a deep research phase, they did an overnight ride-along with Oakland PD. Noone said it was eye-opening how difficult these organizations are to penetrate and build trust with. It was one of several signals, he said, that they had to take their time.
Sending people into a dark cave
Asked how Peregrine selects and trains deployment strategists, Noone reached for an analogy. The company sends a person into a dark cave with a tool belt. The tools are hopefully good. There is a rope, and a friend at the entrance who can pull them out if they shout for help. But the instruction is essentially: maintain your integrity, keep your principles, here are the tools, go do good.
Doing that at scale, he said, requires institutional trust and a belief that "innovation actually happens at the farthest fringes of our organization". In that view, the engineering and product teams are fed by what the field team discovers across the country and now in several countries. He paired that with an internal feedback culture he described as sometimes intense, and with what he called trusting the individual contributor.
The commercial version of the same idea is what Peregrine calls within-customer pilots. After landing inside an agency, the team keeps sprinting on additional use cases, so landing and expanding are both led from the front by the deployed engineers.
Rudolph's own origin story for this is a laptop in a moving car. He remembers driving across the Bay Bridge toward San Pablo, typing as fast as he could, with Noone telling him which reports a detective needed. It was not theoretical, he said. It was an extraordinarily urgent request from a named person, Aaron Blaisdell. "Very rarely are we in a room pontificating about" what to build, one of the founders added.
Which improvisation becomes product, and which stays local
One of the co-founders sorts what the field team produces into two categories.
The first is product primitives: basic capabilities the platform has to offer so engineers can hit the objectives they are trying to achieve. The comments-as-editing workaround is the example. The founders said the engineer built it because of how Peregrine coaches: the job is to hit the objective, "to hell with the technology." Building the tools that let people do higher and higher levels of work is the company's job; "your job is to achieve."
The second is what the co-founder calls an innovation lab. There, a deployment strategist builds something so specific to one customer that Peregrine probably will not fold it back into the product. He said he had recently come across a hurricane simulator someone had built inside Peregrine: "How did you do that? I didn't know you could do that." Another deployment strategist built a tool that combined data from several sources, including 911 call times and budgets, and let you place a fire department in the city and get an estimate of how many people that would impact. She had been at the company a month.
What makes that range possible, the founders told the podcast, is that generating software now costs close to nothing. If the platform hands the deployment team security and governance controls plus the APIs they need, the team can build against it directly. "Not every customer needs an agent," one of them said. "Maybe they need a hurricane simulator." Customers can build in the environment too, though most of that motion still comes as a partnership with Peregrine's deployment team.
None of it works without preparation. Certainly 95% of the work, in the founders' account, happens before a user types in a question: getting data into shape so an answer can be accurate and its citations correct. A chart can be completely useless if it is drawing on the wrong information, Rudolph said, and the same is true of agents and of whatever technology comes next.
The number under the argument
The skeptical question the hosts put to the founders was economic. Palantir, as the host described it, notoriously does not take anything less than eight-figure contracts; American municipalities cannot pay that. Near the end of the conversation, one of the co-founders came back to that origin story. There is a lineage of failed business units inside large, astounding organizations that tried to serve state, county and city public safety, he said, because delivering tailored solutions at a price these agencies can afford was never possible.
The founders' claim is that the economics have changed. Supporting the next marginal customer with the handholding Peregrine considers necessary was not possible even five years ago, the co-founder said, "because the marginal cost of doing what we do, to drop it below a million bucks a year, I mean, it's radical." In that account, creating the efficiency to drop the price by an order or orders of magnitude is what earned the company the right to aim at thousands of cities. The answer moves between marginal cost and price, and it does not say whether the million-dollar figure is Peregrine's own cost of serving a customer or what a customer pays.
Asked about becoming the institutional memory layer for 10,000 cities, and the power that would carry, a co-founder separated the outcome from the path. The path, he said, requires serious integrity, moral compass and core values expressed in ways of working and actions rather than words. As for the power: "who are we to think that we hold any power over that? I mean, it's the institution that has the power."