ExpertsFMMaking Cities Awesome: Peregrine’s Nick Noone & Ben Rudolph
Training Data · September 1, 2026
5 Selected Lessons:
case · 3 framework · 1 priority · 1
Infrastructure that preserves local uniqueness over centralized institutional power
Source
Training Data — Making Cities Awesome: Peregrine’s Nick Noone & Ben Rudolph (September 1, 2026) · at 47:49 ▸
When this applies
when a company builds infrastructure that will accumulate outsized long-term power over many independent institutions
The takeaway
When your long-term vision involves holding outsized power over many institutions, prioritize an operating model where that power remains distributed as infrastructure serving local control, not centralized in your hands.
Why it works
Framing the end-state as 'infrastructure' that empowers each customer to use their own data as they choose (rather than a centralized service the company controls) limits concentration of power even as scale grows, because responsibility and control stay distributed to each jurisdiction.
One level up
Great accumulated power should be deliberately designed to preserve the independence of those it serves, rather than consolidate control for the provider.
Where it stops holding
This stops working when the speaker's aspiration proves undeliverable in practice — the claim is a stated intention about the future, not yet validated by outcomes.
Detail
hierarchy:
- 1. Infrastructure that empowers institutions to control their own data as they choose/are required to
- 2. Preserving each city/jurisdiction's uniqueness
- 3. Scale (10,000 cities) as a byproduct of the above, not a goal pursued at their expense
rationale: The founders explicitly frame 'great power' at scale as requiring 'great responsibility,' and their answer is to design the operating model around infrastructure and distributed control rather than central authority.
In their words
The end game of 10,000 cities, I think, requires an operating model that is fundamentally about infrastructure, actually. It's like we as a technology organization are delivering technology infrastructure that empower these organizations do with their data as they would like and as they are required to do.
Forward-deployed engineering as co-ownership of the customer's problem
Source
Training Data — Making Cities Awesome: Peregrine’s Nick Noone & Ben Rudolph (September 1, 2026) · at 1:54 ▸
When this applies
when deploying any technical team directly into a client's operating environment to solve a problem they can't solve alone
The takeaway
Take deep ownership of the client's outcome, not just delivery of your product, and measure success by speed-to-outcome relative to any alternative.
Why it works
Psychologically co-owning the problem (rather than treating it as a vendor transaction) makes the engineer optimize for the customer's actual outcome instead of for shipping a feature, which speeds delivery because effort concentrates on the real bottleneck.
One level up
Whoever is willing to own outcomes rather than deliverables earns durable trust and repeat access.
Where it stops holding
This stops working when the provider cannot actually sustain that level of ownership at scale or when the customer wants a hands-off vendor relationship rather than embedded partnership.
Detail
procedure:
- Embed engineers physically/virtually inside the customer's environment
- Psychologically co-own the problem as if it were your own
- Target getting the customer all the way to the outcome, 3-5x faster than alternatives
- Credit the win to the customer, not yourself
benchmarks: {"speed_multiplier":"3-5x faster than any other team"}
rationale: Ownership mindset reorients effort toward outcomes rather than technology for its own sake.
In their words
Technology and all of the skills and ways of delivering our tech is part of the answer, but the real answer is just getting to the outcome at all costs, ideally three to five times faster than any other person or team could do.
Earning access to San Pablo PD by leading with trust, not credentials
Source
Training Data — Making Cities Awesome: Peregrine’s Nick Noone & Ben Rudolph (September 1, 2026) · at 8:25 ▸
When this applies
when trying to break into a closed, high-trust market as an unproven outsider
The takeaway
To gain access to a closed institution, approach a specific respected insider with genuine curiosity and humility rather than a generic sales pitch.
Why it works
Cold-calling a specific, respected practitioner and asking to learn rather than sell lowered the perceived risk and appealed to the practitioner's pride in their own expertise, making a 'yes' low-cost for them.
One level up
Access to gatekept domains is won through demonstrated respect for existing expertise, not through asserting your own.
Where it stops holding
This stops working when the institution has no individual champion willing to take a personal risk on an unproven outsider, or when over two dozen attempts before success is not financially sustainable for the startup.
Detail
situation: Two founders with national security and humanitarian backgrounds wanted to build city-safety technology but had no credibility with police departments; over two dozen agencies said no.
decision: They researched a specific respected commander (Brian Bubar) known for a landmark investigation and cold-called him, explicitly asking to learn rather than sell, offering to build something over time.
outcome: San Pablo PD granted them badges and desk access on Feb 26, 2018, which the founders mark as the company's true start date.
lesson: Leading with humility and specific respect for an individual's expertise, rather than a generic pitch, was what finally won access after dozens of failures.
In their words
We just called him and said, Brian, we don't know that much. We may have some utility, but I don't know. Can we come in, ask you some questions, learn from you, try to understand some of the awesome things you've done, including some of these amazing prior investigations.
Agentic integration pipeline writes 90% of data-integration code under human oversight
Source
Training Data — Making Cities Awesome: Peregrine’s Nick Noone & Ben Rudolph (September 1, 2026) · at 29:00 ▸
When this applies
when a company needs to scale a repetitive, verifiable technical task (like data migration/integration) across many customers
The takeaway
Autonomous agents can take over large fractions of a technical workflow when the task's correctness is deterministically verifiable, freeing humans to supervise rather than execute.
Why it works
Because data integration correctness is deterministically verifiable via an eval set, long-running autonomous agents with sub-agent orchestration can be trusted to do most of the work, with humans supervising rather than authoring.
One level up
Verifiability is the gating factor for how much autonomy you can safely hand to an AI agent in any workflow.
Where it stops holding
This stops working when task correctness cannot be deterministically evaluated, making agent output unverifiable and unsafe to trust at scale.
Detail
situation: Peregrine needed to integrate tens of thousands of data sets across customers using Python-notebook-based ETL work, previously done manually by deployment strategists.
decision: Built an agent with a deterministic eval set for completeness/correctness, allowing long-running (hours), multi-sub-agent autonomous integration work with human oversight.
outcome: About 90% of integration notebook code is now written by agents under deployment team oversight.
lesson: Verifiable, bounded technical tasks (like coding migrations) are prime candidates for handing to long-horizon autonomous agents.
In their words
At this point, we're seeing about 90% of our, we use a version of Python notebooks to do a lot of our integrations. About 90% of that is written by agents with the oversight of our deployment team.
Innovation-lab builds by deployment staff that never ship back to core product but still create massive customer value
Source
Training Data — Making Cities Awesome: Peregrine’s Nick Noone & Ben Rudolph (September 1, 2026) · at 47:49 ▸
When this applies
when frontline staff build highly customized one-off solutions using a flexible platform that won't generalize to other customers
The takeaway
Not all frontline innovation needs to generalize into the core product; some of the highest-value work is bespoke, one-off tooling enabled by a flexible underlying platform.
Why it works
A flexible platform with the right primitives (data integration, APIs, governance) lets even very new or junior staff build complex bespoke tools (e.g. a hurricane simulator) tailored to one customer's unique needs, generating value even without becoming reusable product features.
One level up
A platform's real power is measured by what non-expert frontline staff can build with it, not just what the central product team ships.
Where it stops holding
This stops working when one-off bespoke builds consume disproportionate engineering resources relative to the value delivered to a single customer, or when the platform lacks sufficient flexibility to support such builds safely.
Detail
situation: Deployment strategists, including someone one month into the job, built one-off tools: a hurricane simulator and a tool estimating impact of placing a fire department in a city based on integrated 911, budget, and other data.
decision: The company let these bespoke builds happen on the flexible platform without requiring them to generalize into core product features.
outcome: Highly novel, customer-specific capability was delivered rapidly, surprising even the company's co-founder ('I didn't know you could do that').
lesson: A sufficiently flexible underlying platform allows even very junior staff to create high-value bespoke tools, and not all valuable innovation needs to become a reusable product feature.
In their words
There was another deployment strategist who built this thing where you could, you could, it integrated a bunch of data from all these different sources, 911 call times, like budgets, and you could place a fire department in the city, and it would give you an estimate on how many people that would impact. Unbelievable. And she was at the company for a month.