Part one of UXR for AI-native teams, a six-post series.
Earlier this year I asked people on my LinkedIn about AI-first teams, agentic teams, AI pods- pick your label- to talk to me, and a lot of you did. This series is me working the resulting pile of notes into a framework, weekly, in public, over the next couple of months or so. (Or watching it fall apart in real time. Either would be informative.) Today: the economic model that explains why research keeps losing these teams, and the three operating models a research function can run, so you can work out which one yours is actually running.
A team that shouldn't exist #
Two senior engineers and an agent layer between them: one agent drafting code against a spec, another writing tests, a third watching every change for breakage. Monday they pick up a problem statement. By Thursday morning, three working prototypes sit on a staging URL, live enough to click, because the distance between a mockup and working prototype has collapsed significantly. Friday they pick a winner. Monday it ships behind a flag.
Ask how quality survives that speed and they won't describe heroics; they'll describe infrastructure. The agents run inside a harness: version control, tests they can't skip, review gates, rollback paths, eval suites that score output before a human looks. That harness is why two people supervise what used to take nine.
Now ask what the harness knows about the people the product is for, and enjoy the silence.
Seven terms, quickly #
If some of those words washed past you, here's the decoder. The whole series leans on these, so I'd rather spend a hundred words now than lose you in week three. AI-native team (or pod): a small team where AI agents do much of the building and the humans concentrate on framing, deciding, and checking. The label is unsettled. The shape isn't.
Agent: software that does multi-step work on its own, here writing code, tests, and drafts against instructions. Not a chatbot you paste things into.
Spec: the written description of what to build. On these teams it isn't a communication aid; agents build directly from it, so what the document says is what ships, including its gaps.
The harness: the infrastructure around the agents. Version control, automated tests, review gates, rollback paths. It's the reason speed doesn't mean chaos on the good teams.
Feature flag: a switch that releases a change to a small slice of users first, so shipping stays reversible. "Ships behind a flag" means ships carefully.
Evals: automated tests for AI behavior, scoring outputs against a standard before anyone relies on them.
Context: whatever an agent can see while it works: its instructions, the code, the documents it was handed. If knowledge isn't in the context, the agent doesn't know it, no matter what your organization knows. Hold onto that one.
Is this every team? No. It's the fast end of a real distribution, Microsoft's Frontier Firm at one end, and the diluted version most teams run at the other: two or three weeks instead of one, more humans in the loop, same shape. DORA's 2025 research found AI amplifying whatever engineering conditions already existed, which is why the gap between those ends is widening. Take whichever version you believe. The argument below doesn't move an inch, because the research model we all inherited was calibrated to quarters, and a function built for quarters is equally dead at one week or three.
The subsidy you didn't know you had #
Here's the economic model, and once you see it you can't unsee it.
For the entire history of software, building was the expensive part. A feature cost weeks of engineering time, so everything upstream of the build could afford to be slow, and research's entire delivery model, the intake queue, the two-week study, the readout, the deck, was priced against build time. Build time was generous. We were, in effect, subsidized by engineering's slowness, and like most subsidies, nobody who benefited ever called it one. The subsidy just got withdrawn. When a team can produce four working candidates in the time it used to take to write the ticket, producing options is no longer the expensive part of product development. Choosing between them is. Deciding became the scarce resource, and every deliberative function got repriced overnight, whether it noticed or not.
Watch what the pod actually decides with: the PM's memory of the users, last quarter's dashboard, a summary an agent wrote of a document another agent wrote, whatever a chat window says at 11pm with a confidence no evidence supports. I've sat close to versions of this meeting, and nobody in it is being lazy. Decisions arrive at generation speed, human confidence regenerates at human speed, and people reach for whatever is within reach.
This is why the standard prescriptions underdeliver. Faster studies still miss Thursday decisions. Better storytelling can't find a readout slot in a loop that ships before the readout could be scheduled. Research didn't get worse. Its delivery model was priced against a cost structure that no longer exists, and the repricing happened without a memo.
The three operating models #
Once you see the repricing, every research function turns out to be running one of three operating models, and I've come to believe the model predicts the outcome better than the talent does. Find yours.
Requestable. Research as a service you file a ticket with. The tell is an intake process with a latency measured in weeks, and a roadmap of studies. This model was completely rational under the subsidy; when builds took six weeks, a two-week study fit inside the slack. Its failure signature now is arithmetic, not attitude. A pod making thirty meaningful calls a quarter can route maybe two of them through a two-week channel before the channel's latency makes it a rounding error, so the loop routes around the queue, without malice, the way water routes around a rock. From inside, this looks exactly like declining demand. It's actually a clock mismatch, and the cruel part is that the intake queue going quiet reads as "less work," right up until the headcount conversation where it reads as "less need."
Consultable. Research as a fast, embedded, reachable human. Slack-first, in the room, methods compressed, turnarounds in days. This is genuinely better, it's roughly where the best current practice lands, including my own book on running research at speed, and I stand by it. But the conversations behind this series taught me its ceiling, and I'll state it plainly: inside an AI-native team, consultable means one human's availability standing between the team and its blind spots. Your coverage is your calendar. The failure signature is that everything works until you're saturated, and then the 11pm spec, the Saturday decision, and the week of your vacation all get made the old way, on memory and a chat window. Consultable doesn't get routed around. It gets exhausted, and its quality degrades exactly when the team is moving fastest, which is exactly when it matters.
Built in. Research as part of how the team operates: knowledge encoded where the team's standards live, present in the spec's template, wired into the ship gates, standing in the context the agents read when they generate. Concretely: a spec template that asks about evidence before it asks about requirements, a ship checklist with one user-facing line on it, and a file of what's known about your users sitting in the repository next to the agents' instructions. The tell is the strange one: things happen correctly without you. A spec cites evidence you didn't hand anyone. A team checks what's known before the kickoff because the checking is in the kickoff. This is the only model that operates at the unit's own tempo, because it's made of the same stuff the unit is made of: documents, gates, and context. And before you file it under aspirational, notice that one function already survived this exact wave by running this exact model. Design encoded its judgment into systems the machines are forced to respect, which is why generated screens come out on-brand, and why design didn't get sorted into overhead when screens became generatable.
The one-question test.
Does what your organization knows about users participate in any decision you do not personally attend?
If the honest answer is no, you are consultable at best, and your ceiling is your calendar. If the answer is "only when someone remembers a deck," you're requestable with good branding. That single question locates you more accurately than any maturity model I've seen, and it's the question the rest of this series is built to change your answer to.
The stakes #
One more thing before the map, because the three models would just be taxonomy if nothing were being decided. Something is. Organizations are quietly sorting every function into infrastructure, the things wired into how work happens, or overhead, the things that re-justify themselves each budget cycle, and the sorting doesn't happen at an offsite. It happens through a thousand small defaults, one skipped intake at a time, one 11pm spec written without asking anyone, and by the time it's visible in a headcount conversation, it's mostly finished. Nothing in the pod's loop is hostile to research. Nobody voted to exclude user evidence; they decided, without ever holding a meeting about it, that evidence arriving after Thursday doesn't exist. The org chart didn't reject research. The clock did.
Where you're standing changes the timeline. Near real pods, the sorting is already underway and your intake went quiet months ago. In the quiet middle, where tools are compressing execution inside an unchanged org chart, you have time, and you should know that the quiet middle is a transition, not a destination. And in a platform play, where leadership has declared the agent layer strategy, the window is already half closed.
What comes next #
The claim this series defends, then, in one sentence: at the speed of AI-native teams, the only research that matters is research built into how the team operates. The rest of the series is the working-out, and it starts with the obvious question: built into what, exactly? Not in general, in the loop. There are, it turns out, exactly five moments where knowledge about users can enter an AI-native team's decisions, and five ways it silently fails to. Once you can see them, most of what a modern research function should build becomes uncomfortably obvious.
That map is Next week's post, and the rest of the series hangs off it.
And if you think the claim is wrong, my email is here, and I mean that. A thesis that can't survive its own comment section doesn't deserve ten chapters of machinery.
See you Next Week.
🎯 This is part one of UXR for AI-native teams, a six-post series. Subscribe, and the rest arrives as it publishes, Fridays, no algorithm required.
📖 If the fast-research layer underneath this series is the part you need first, that's my book: AI-Powered UX Research, the operating manual for running research at the speed your team actually needs. This series is what I've been thinking since.