San Francisco has long been known as a center of innovation. The opportunity now is to apply that identity to the city itself, so it can better meet the needs of residents. This means improving how it learns, how it decides what work to do, and how it evolves over time.
That requires a transformation. Not just in what the city does, but in how it operates. And it starts with a single shift in principle: from work-first to learn-first.
What Learn-First Actually Means
A learn-first approach is not a phase in a process. It is an operating principle that produces a different starting point for everything the city does.
Today, most city systems start with executing work. A resident arrives with a request, the system processes it, and the work gets done. This is good for delivering predefined services, but it assumes the resident already knows what they need and that their request maps cleanly to the right response.
That assumption is often wrong, and the consequences compound over time.
A learn-first system starts differently. It begins by understanding what someone is trying to do or what they are experiencing, then determines the appropriate response from there. The system takes on the responsibility of figuring out what work is needed, rather than expecting the resident to define it correctly and coordinate it themselves.
This is not about replacing work with learning. It is about sequence. The city learns first, then determines what work should be done. The work itself becomes part of the learning where the city applies its depth of knowledge, producing an output that residents can evaluate.
Designing Around Learning Instead of Work
The difference between these two approaches becomes most visible in how systems are designed.
In a work-first system, complexity is pushed onto the resident. Instructions, FAQs, guides, and categories exist to help people navigate the system because the system cannot understand their situation and respond to it. The resident is expected to figure out how the city is structured and how their need fits within it.
In a learn-first system, that burden shifts. The city asks questions, gathers context, and determines the right path forward. The system is designed to first understand what is needed, then act to serve that need.
Two of the city’s most visible systems can be used to illustrate what this shift looks like in practice.
PermitSF
PermitSF starts by asking the resident to select a department, then choose a permit type, or search for one. Every entry point assumes the person already understands how the city is organized and what category their situation fits into. The system was designed to process permit applications, not to first understand what someone is trying to build or whether building it is the right outcome. The information gathered in an application is primarily for code compliance to ensure it meets the technical requirements. It is not designed to answer a different and equally important question: what experience does this create for a broader set of residents, and does it align with the vision for the city we are trying to build?
A learn-first design moves that conversation to before the application ever gets submitted. Thought the conversation, critical context is gathered about what is being done, why, who will be affected, and what experience will this create. For things like metal planters in public spaces, it can include information about a plan for maintaining them and funding to do so.
That conversation does several things at once. It prepares both parties: the applicant is prepared and arrives with the right permits identified, and the city starts the process with better context for the decision. It reduces back-and-forth by catching incomplete or misaligned applications before they enter the process. It surfaces situations that shouldn’t go through the process at all by identifying them early, before anyone wastes time on them. And it captures gap needs — situations the city’s current permit system doesn’t serve — that currently get buried inside departmental application databases rather than flowing into the innovation process where they could inform what gets built next.
The resident experience improves because they know earlier, with less friction. The city’s decision-making improves because the inputs are better. The same conversational entry point serves residents affected by permitted work too — a tenant trying to understand what construction is happening in their building, a neighbor wondering why their parking disappeared — routed just as naturally as any applicant’s situation.
The same conversational entry point serves residents on the other side too, like a tenant trying to understand what construction is happening in their building or a neighbor wondering why every parking spot on the block is reserved. This is handled just as naturally as any applicant’s situation.
311
SF311 illustrates the same principle at the service level. Today, 311 is designed around individual tasks. A resident selects a category, provides a location, and submits a request. The system captures the task. It does not capture the experience.
Is this a one-time incident or part of a recurring pattern? Are there other conditions on the block — broken sidewalks, poor lighting, overgrown shrubs, accumulated debris — that combine with this one to form an experience no single work order will resolve? Those questions don’t just improve the immediate response. They add context and generate the pattern data that makes diagnosis possible. Diagnosis is what determines whether a dispatch is the right response or whether something systemic needs to change.
A learn-first design starts with a story or conversation to understand the experience. What is happening on your block? How often? What else is going on around it? The system receives the information and routes it accordingly. Some might be used to trigger immediate service, while some of it might go through the innovation path to solve problems and improve conditions that are causing the experience.
Who Does the Learning
This shift reflects a deeper change in responsibility.
In a work-first system, the resident does the learning. They learn the city organizational structure. They figure out the right category, the right request, and the right process. The city executes what they submit.
In a learn-first system, the city — the system — does the learning. The resident describes their situation, and the city takes it and decides what should happen next.
That is what it means to serve.
Innovation as a Continuous Learning System
Innovation is often described as a process that moves from research to execution. In practice, it is a continuous system of learning.
It begins with information exchanged between residents and the city about what is being experienced, what is being attempted, and the context around both. This requires focused, active engagement within a learning conversation, leveraging follow-up questions to deepen understanding.
That information is then interpreted to build understanding as patterns emerge, causes become clearer, and gaps in knowledge are identified. This stage is iterative, as deeper understanding often requires returning to gather more information.
Work is the application of what has been learned. It reflects the depth of understanding and serves as its demonstration. The city shows, through what it builds and delivers, how well it understands what residents need.
The results are then experienced and evaluated. Residents signal whether their experience improved and their level of satisfaction, and that evaluation becomes new information that feeds the next cycle.
Learning continues as the system operates. It does not stop when work is delivered — it deepens.
Different Types of Learning
Not all learning serves the same purpose, and understanding the difference between types matters for how the city captures and uses it.
Feedback helps the city understand how well it is performing. It provides signals about satisfaction, quality, and effectiveness after work is completed. It also surfaces improvement areas within existing products and services.
Stories help the city understand what residents are experiencing. They provide the context needed to determine what work should be done in the first place, often leading to changes in capabilities, not just improvements to what already exists.
Both are necessary but play different roles. Conversations often contain both types. When conversations are treated as learning opportunities rather than service transactions, they add depth of learning that no form or survey can replicate.
The Innovation Process: The 5 Ds of Problem-Solving
A learn-first system needs a structure for turning continuous learning into coordinated action. The innovation process provides that structure by organizing learning into work that can be delivered, evaluated, and improved over time to solve problems that surface within the experience.
Discover problems residents are experiencing. What is happening? How does it connect to other problems? How long has it been happening and how often? How does it make them feel? What impact does it have?
Diagnose underlying causes by identifying patters. Move from individual incidents to systemic understanding. Why does this keep happening? What conditions or capability gaps are producing this experience?
Define what needs to change and within what constraints. Clarify the opportunity. What would a meaningful improvement look like, and what is the city capable of delivering?
Design solutions that address the defined need. Validate with the residents who surfaced the problem. Does this address what you described? Would this improve your experience?
Deliver and implement, evaluate, and continue learning. Ask the resident: did your experience improve? Their answer is the grade, and the input that starts the next cycle.
Each phase produces outputs that become inputs for the next. Within every phase, the same learning cycle is at work: information is gathered, understanding deepens, learning is applied through work, and results are evaluated. This is how learning becomes coordinated action. It is also how the city evolves.
Where We Are Today and Why It Has to Change
Today, much of the city operates in a work-first model. Systems are designed to process requests and complete predefined work as efficiently as possible. This can deliver services, but it assumes the work being requested is the right work. It does not consistently capture the broader context in which that work exists, and it does not enable the city to learn at scale.
As a result, the same problems reappear. The same requests are submitted. The same work is carried out repeatedly. Effort increases, but outcomes do not meaningfully change. The city becomes more efficient at doing that work without ever asking whether it is doing the right work.
This pattern is not just ineffective. It is unsustainable. The city pays repeatedly to treat the same symptoms while the underlying causes remain unchanged. These are band-aids, some of which do not stick for more than a few hours. As more problems go unresolved, more work is required to manage them at the surface.
Meanwhile, trust erodes. Residents see the same issues return, report them again, and experience little meaningful change. They often start doing the work themselves. Over time, confidence in the system declines.
The budget deficit and the trust deficit grow together.
Both are symptoms of the same underlying problem: a city that executes without learning cannot improve. It can only repeat.
What Has to Change
To become a learn-first city, the system itself must change — not in one place, but across all four dimensions through which a system operates.
People must have responsibilities that include learning, not just execution. The employees who interact with residents every day are the city’s most valuable source of insight. Treating interactions as learning opportunities, asking questions to get depth of knowledge, then capturing and bringing that into the organization must be part of the job, not an exception to it.
Processes must define how information is surfaced, analyzed, and acted upon. Learning must lead to decisions. It cannot remain isolated within individual interactions or departments. Work must flow through a decision-making process to route information to execute work and evolve capabilities.
Policies must reinforce that learning is expected and necessary. What gets measured, resourced, and recognized must reflect the value of learning, not just the volume of work completed.
Products must be designed to understand intent and context, not just process predefined requests. A system designed around executing work more efficiently will reinforce the work-first model regardless of how modern its interface. A system designed to receive stories or conduct conversations, process them, and route information accordingly to drive downstream work. New capabilities — particularly those being built now — must be designed around this principle from the start. Rebuilding the current model on a modern platform improves efficiency rather than effectiveness. It does not change outcomes.
Enabling a Digital Workforce
Changing all four dimensions simultaneously across people, process, policy, and product raises an immediate and legitimate question: how does a city already under budget pressure, with constrained staffing and finite hours in the working day, actually execute this transformation? The honest answer is that it cannot do so through human capacity alone. The volume of conversations required to learn from a city of 800,000 people, across dozens of services, in dozens of languages, at all hours, exceeds what any human workforce could sustain. A learn-first system that only works at the scale of its staff is not a city-scale system. It is a pilot.
The answer is a Digital Workforce of AI Agents that conduct online conversations, transcribe and structure what is shared, analyze patterns, route inputs to the right places, and assist with escalations and exceptions, while operating continuously, in parallel, and across every service the city offers. This is not a replacement for human judgment or human connection and may require follow-up conversations with humans. Residents who want to speak with a person can and human resources are freed up to have those conversations, learn, and build relationships. Offline channels, like phone, in-person, and community liaisons, remain essential for older residents, those without reliable internet access, and anyone who simply prefers human interaction. But for the majority of residents engaging digitally, AI Agents become the primary interface through which the city learns, and they are available at any hour, at any volume, and, over time, will show limited to no degradation in quality as demand scales. They may improve quality.
The Digital Workforce also resolves one of the most persistent equity failures in city services: the language barrier. San Francisco is one of the most linguistically diverse cities in the country, and a meaningful portion of the residents most dependent on city services are those for whom English is not a primary language. Current systems accommodate this to some extent with a translated form or bilingual hotline there, but the deeper and more contextual the interaction needs to be, the more the system defaults to English, and the more residents who don’t speak it are disadvantaged. They receive shallower service and have less ability to share the full context of their situation. Their experiences are therefore less likely to surface in the data that shapes how services improve.
AI Agents remove that barrier by default. A resident converses in Cantonese, Spanish, Tagalog, Vietnamese, or any of the languages spoken across the city and receives the same depth of engagement as an English speaker. The conversation is transcribed, translated, and structured in a way that makes it equally useful to the analysts and designers working downstream. The insight is not lost because of language. This matters not just as an equity commitment but as a data quality imperative: a learn-first system that can only learn from English-speaking residents is systematically missing the experiences of a large part of the population it is supposed to serve. Multilingual capability is not a feature. It is a requirement for the system to function as designed.
The same translation capability applies inside the organization. A city workforce is itself linguistically and culturally diverse. The ability to surface insights, route findings, and brief decision-makers in the language they work in, while not losing fidelity to what the resident actually said, closes a loop that currently stays open. Understanding doesn’t get diluted in translation between the resident and the people responsible for acting on what they shared.
The Digital Workforce is not a technology investment in the conventional sense. It is a workforce strategy for a diverse city that allows the city to scale conversations and discovery to include the full population precisely when it is under pressure to cut the human capacity that previously made that impossible. The system is always working for residents: at midnight when a night market surfaces, at 6am when a small business owner is trying to understand a permit process, or on a Sunday when someone finally has time to share what has been wrong on their block for months. The city’s ability to learn does not stop when its offices close. The innovation office is always open. That continuity is what makes the learn-first model real rather than aspirational.
How the Innovation Office Works Within This System
The Mayor’s Office of Innovation — the i-Team — is the catalyst for this transformation. But to be effective, it needs an operating model designed for innovating and producing the experience it wants to deliver. That model looks a little different from how the office has operated before, starting with changes to the innovation process described in this article.
The i-Pod Model
At its core, the i-Team should function as a set of focused “i-Pods” — small, cross-functional teams organized around specific, prioritized problems. Each i-Pod brings together the roles the work requires: a product manager to own the problem and drive the process, a service designer to understand and shape the resident experience, and a data scientist to identify patterns and surface insights from what the city is learning. These are the stable core roles. Everything else flexes.
When a priority requires engineering to build or transform a product, the i-Pod expands to include solution architects and engineers drawn from the city’s IT teams or partner organizations. When the work requires changes to department processes, policies, or people, the i-Pod brings in people from those departments who understand the existing systems and can drive change from the inside. When communications, legal, or procurement are needed, those resources are informed throughout, joining for the relevant phase, and stepping back when their work is done. The i-Pod stays focused and flexes to fit what the work requires.
This reflects how the best product organizations work — not a fixed team trying to cover every discipline permanently, but a core that orchestrates and a flex layer that brings in what the work needs, when it needs it.
Building the Right Team
The current i-Team with product managers, service designers, and a data scientist sets a solid foundation. As the model shifts toward learn-first, those roles don’t disappear; they evolve. Service designers move from mapping existing experiences to designing the learning exchange itself: what the city asks, how it listens, and how the initiation of a service becomes an opportunity to understand the resident before routing them anywhere. That is a more demanding scope than optimizing a form or improving a portal flow, and it changes what service design needs to produce. Three capability gaps grow as the model scales.
Data Science
The first gap is data science. As learn-first products come online with conversational interfaces, story-based feedback systems, and resident experience layers, they generate a new category of data at scale: transcripts, stories, sentiment signals, behavioral patterns across thousands of interactions. That data needs infrastructure to capture and structure it, and data science capability to analyze it and translate findings into something the innovation process can act on. The data grows as the products are built, which means the data science need grows with it.
This makes expanded data science capacity an immediate planning need, where it is resourced proactively, so the capability exists when the pipeline starts flowing, rather than scrambling to staff it after the data is already accumulating. AI can help surface patterns and accelerate synthesis, but it requires data scientists who know what to capture, how to structure it, and what the findings mean. Research-driven innovation at city scale needs a data science capability, not a single data science role.
UX Research and Design
The second gap is UX research and design. A genuinely learn-first interface that is conversational, story-based, context-aware, and designed to understand what someone needs before routing them anywhere does not exist in any SaaS catalog. It must be designed and built as a new experience layer, with a design system that defines what learn-first products look like and how they behave consistently across every service the city offers. That work requires dedicated UX capability: researchers who can test whether the new interaction model builds understanding, and designers who can translate service concepts into a coherent experience. Service designers define the system; UX research and design make it work in practice.
AI Engineering
The third gap is AI engineering: the role responsible for building, training, and stewarding the Digital Workforce. This is distinct from data science. Data science makes sense of what the city learns at scale by finding patterns, surfacing insights, and feeding the innovation process. AI engineering makes learning possible at scale in the first place. The two roles work at opposite ends of the same pipeline, and they need each other: the AI engineer structures what flows in; the data scientist works with what comes out.
The AI engineer’s work begins in partnership with service designers to generate a shared understanding of the conversational behavior of an agent — what it asks, how it probes for context, when it slows down to listen more carefully, and how it makes a resident feel understood rather than processed. This is a service design artifact before it is a technical one. Service designers define the learning exchange; the AI engineer translates that into agent behavior and ensures it performs reliably at scale. That collaboration is where the Digital Workforce develops its character. Agents built without service design input produce efficient transactions, but agents built with it produce genuine conversations that are effective.
As the Digital Workforce is deployed, the AI engineer’s work extends to the data science interface, creating the pipeline that structures conversation outputs into analyzable data and co-designing the data model with the data scientist so that what flows in is what can be effectively used within their workflow. This is where Discover and Diagnose start operating at city scale: not just qualitative depth from individual conversations, but patterns across thousands of them, surfacing simultaneously, compressing the time between learning and action in ways that were impossible before.
This is the role that changes the team’s and the city’s capacity to learn and improve. Without it, the i-Team is a small group working at human speed and human volume. With it, the innovation process is running continuously across the city, learning at scale, surfacing signals in near real-time, and compressing the cycle from discovery to action. The AI engineer is not a supporting role. It is the role that makes city-scale innovation operationally real.
Flexing Capacity
Not all these roles need to be permanent fixtures on a small, budget-constrained team. San Francisco has depth in UX, engineering, product management, and data science across city departments, within the broader civic technology ecosystem, and in our community of residents. The i-Pod model is designed for exactly this: a stable core that flexes to bring in what the work requires. What matters is that the capability exists when it is needed — whether through embedded team members, innovation partners in departments, or partner organizations — and that the roles are clearly defined so the right people are engaged at the right moment.
Innovation Partners and Change Management
To extend the i-Pod’s reach into departments without growing the core team indefinitely, the model requires innovation partners that are embedded inside departments, trained in the innovation process, aligned to the learn-first principle, and responsible for driving change within their department. They are not members of the i-Pod, but they interface with it. When the i-Pod identifies a change that needs to happen inside a department, the innovation partner is the person who makes it happen by navigating the internal environment, managing stakeholders, and sustaining the change after the i-Pod has moved on.
Innovation partners also serve as change advocates within departments to bring others along, manage resistance, and build the internal will to operate differently. That role is manageable at the early stages of the transformation when the scope is limited. As the model scales across departments, a dedicated change management function becomes critical to oversee readiness across the city, identify where adoption is stalling, and ensure that new ways of working take hold rather than fading once the i-Pod moves on. Change management is not a day-one priority, but it needs to be a day-one plan. Treating it as a reactive hire after resistance emerges is how transformations stall.
The City-Level Learning Capability
Threading through all of this is the city-level learning and innovation capability that receives inputs from resident interactions across departments, routes what belongs to existing services back to those services, and routes what is new, systemic, or unassigned to the i-Team for the innovation process. This capability makes learning operational rather than episodic. It is also what ensures that when a new capability is needed — one that doesn’t yet belong to any department because it doesn’t yet exist — there is somewhere for that insight to go and someone responsible for acting on it.
Measuring What Matters
The 5 Ds describe how the city innovates and solves problems. But the system also needs to know whether it is working. The question already embedded in the Deliver phase of “did your experience improve?” is the right starting point. It puts the resident in the position of evaluator, not just recipient. The answer is the grade. But the grade alone is not enough to drive the next cycle of learning. It needs context by asking “what changed?”
What specifically improved? By how much? What did not? Did any new problems surface? Those distinctions matter. They tell the city whether the work delivered is producing the right kind of change. That information feeds the next Discover phase with better-defined starting conditions.
A second category of measurement is trust. This paper identifies both a budget deficit and a trust deficit as symptoms of a city that executes without learning. The learn-first model addresses both, but trust cannot be assumed or declared. It must be earned and measured. One of the most direct signals available is opt-in behavior: whether residents choose to share more than the minimum required to initiate a service. When given the option to have a conversation recorded and transcribed, to have their story anonymized and used to improve the system, or to participate in follow-up research, do they say yes? Low opt-in rates are not a marketing problem. They are a trust signal. They tell the city that the new relationship model has not yet been demonstrated convincingly enough for residents to act on it.
This creates a virtuous obligation. To increase opt-in rates, the city must demonstrate that sharing is worth it. It must demonstrate that information is protected, used only as agreed, and visibly produces change. That forces the city to close the loop and report back to residents in ways it currently doesn’t. Residents who can see how their input shaped a decision, or who are included in validating proposed improvements before they are built, become stakeholders in the innovation process rather than subjects of it. Over time, participation becomes the mechanism through which trust is rebuilt. This is declared through communication campaigns, but through demonstrated results, genuine inclusion, and increased participation.
Together, these measures of experiential outcomes, quality of change, and resident participation give the city a genuine picture of whether the learn-first model is producing what it promises. They make performance visible not as a compliance exercise, but as part of the learning loop itself.
The Goal
The goal is not to keep all of this inside one office. It is to build an innovation capability across the city so that innovation is not something the i-Team does on behalf of everyone else.
Innovation is something the city does together, as one city.
Becoming a City of Innovation
San Francisco is known around the world as a center of innovation. The opportunity now is to apply that identity to the city itself, transforming how it learns, how it decides what work to do, and how it evolves over time.
The operating model — operating system — described here is how that happens. Not through a single initiative or a single team, but through a system designed to learn continuously from residents, frontline interactions, and the experiences happening on every block every day, then turning that learning into a city that gets better at meeting the needs of the people who live in it.
A city of innovation is not something that simply exists. It is something that is continuously built through the innovation and learning capability. It is built through every interaction designed to learn first, with residents participating as teachers and stakeholders.
We are not just here to govern the city. We are here to build the system that enables more effective governance.
Let’s build San Francisco.