Many tech leaders have seen the Notion feedback automation intake funnel. A piece of feedback, in this case, a bug report, comes in from somewhere, AI triages and categorizes it in a Notion database, routes it to the right team, pulls up related discussions and potentially relevant context, notifies that team on Slack, and drafts a spec of expected versus actual behavior. Depending on the complexity of the fix, it may have also drafted the PR with screenshots. By the time an engineer opens the ticket, most of the assembly is done. They review it, fix anything the AI might have gotten wrong, and ship it. This should sound familiar since it’s a big part of the “automate all the things” wave.
On the autonomy scales, most of which borrow the leveling structure from self-driving cars, this workflow is considered to be an L3: conditional. You can also think of it as propose-approve; the system does the work and a human validates, then ships the artifact. Pretty much every maturity model reads L3 the same way, as a waypoint. A place you pass through on the way to L4, where humans supervise on exception, and L5, where humans stop showing up entirely.
This particular workflow isn’t passing through. It’s parked at L3 by design. I expect many of our judgment-heavy workflows to stay at L3 permanently rather than advancing to L4/L5. The reason comes down to the two questions we should all be asking before automating anything: beyond doing the work, what was this step teaching us? And where does that signal go when the human leaves the workflow?
Where Understanding Gets Created
I think those questions are the missing half of what “AI-native” is supposed to mean. They expose a problem most organizations have been compensating for without realizing it.
Most organizations are not self-aware. Not because the knowledge to be self-aware doesn’t exist; it usually does, fragmented across systems and people. A PM can tell you what shipped last quarter. An operations manager knows who owns which subsystem or process. A CSM knows which customer complaints are trending and could lead to churn. The people closest to the work each hold a fragment. Almost nobody holds the whole picture. And decisions don’t need the whole picture in one head; they need the right parts of it, in front of the right person, at the right time. Historically, the only way to get that context was to participate in more work than anyone has time for.
The old operating model compensated for that limitation almost by accident. Every time someone triaged a bug, reviewed a proposal, routed a request, or answered a question, they weren’t just moving work forward. They were also helping the organization build an understanding of itself.
Once you start removing people from those workflows, you have to rebuild that capability deliberately.
The visible outcome is obvious: bugs get triaged, requests get routed, roadmap questions get answered. The less obvious outcome is that the organization learns. The people doing the work update their mental models, recognize patterns, and connect ideas that wouldn’t otherwise meet.
Work moves through workflows. Understanding does too. That understanding is more than just facts. It’s also patterns, connections, tradeoffs, and context that only emerge because someone had to do the real work. We usually notice when we automate the workflows. We rarely notice when we remove the place where that understanding was being created.
The mistake is treating automation as removing work instead of redesigning information flow.
Go back to the Notion feedback triage pipeline example. The engineer reviewing that AI-drafted spec is the one who notices it’s the third report of the same crash this month when two fixes had already gone out. The person who used to route tickets by hand was the one who discovered that nobody actually owns the subsystem that’s crashing and the tickets just keep getting routed to a different team for a quick fix. Or maybe, during a standup, they overheard that another team had already solved a similar problem while troubleshooting something else. It’s a human participating in the workflow who catches those patterns and surfaces them. The understanding isn’t created by the conversation itself, but by participating in the work.
AI can certainly be built to flag these patterns too. That’s exactly the point: it has to be intentionally built to do that. Which means the humans need to be aware that this is a critical step in the process and that it is missing. Automation, when done right, doesn’t just preserve the understanding. If it’s really executed well, it upgrades it, surfacing patterns no single human in the flow would likely catch. But the human version came “free”. Nobody designed it, nobody is accountable for it, and it doesn’t appear in any process doc. Which is why it dies silently when you automate the step. The work still moves, so everything appears fine. You don’t miss the pattern you never noticed forming. You don’t miss the problem you never knew you would have overheard. The loss is invisible by construction. Then it compounds — not as one dramatic failure, but as a widening knowledge deficit. Every quarter there are more patterns nobody recognized, more ideas that never got connected, more problems that never met the solution sitting two teams away. None of it registers as an incident. It’s the organization getting faster at everything except understanding itself. The churn shows up later, when a competitor ships the thing your customers had been asking you for all along, in requests nobody connected. That’s the organization learning about itself from the outside.
I know this sounds suspiciously like a return-to-office argument to put humans in the same place to communicate. I promise it isn’t that. Organizational understanding doesn’t come from shared air or water cooler talk; it comes from position in the workflow. A fully remote organization builds the same understanding through tickets, threads, and reviews. An in-office organization that automates those workflows loses that understanding just as quickly. You could even make an argument that an in-office culture relies more heavily on this dynamic because intentional async communication is prioritized less than in remote work culture.
It’s not nostalgia for more meetings either. Most of those conversations were a waste (besides the obvious rapport building), which is why automating them feels so good. The conversation was never the valuable part. It was repeated participation in the work. That’s how organizations learn. You can watch teams react to this without being able to name it. A process gets automated, output goes up, and within a quarter someone is bolting on a dashboard, adding a weekly sync, or asking for a status report the old process never needed. They can feel something went missing, and automation was supposed to make things better, so the reflex is to add more tooling. Nobody decided to stop understanding. The places where the understanding was built are getting automated away, one step at a time, while output keeps accelerating.
The Missing Design Question
The L1-to-L5 discussion typically treats autonomy level as a two-variable equation:
- Risk: automate when the mistake is reversible
- Value: automate when the human bottleneck is expensive
Both are real. But they answer a different question: should this work be automated?
They don’t answer what comes next.
That’s the missing step in becoming an AI-native organization. Once you remove people from the workflow, where does the understanding they used to build come from?
The organizational design question then becomes: what does this step produce besides the work itself? If the step is purely mechanical, like a lookup, transcription, or routing decision that requires no interpretation and creates no useful pattern exposure, then it may produce nothing beyond the work itself. Automate those steps aggressively and don’t look back. But the workflows that require judgment, translation, or pattern-matching across cases are also the ones where understanding gets created. Where a step carries that weight, L3 propose-approve (conditional) is the destination, not a waypoint. Different operations should sit at different autonomy levels, forever and on purpose.
None of this is a case against pursuing L4/L5 workflows. Quite the opposite. The exercise of questioning every workflow is incredibly valuable because it forces you to redesign work instead of accepting “that’s the way it’s always been.” I just think the design question changes once you’ve removed the people.
I think the main reason many teams are settling on L3 workflows today is simply reliability. Agents still make enough mistakes that a human should validate important work before it ships. I agree with that argument. I just don’t think it’s the durable one.
The agents will improve. The reliability argument will weaken. The organizational need for understanding won’t. What a workflow teaches your organization about itself has nothing to do with how good the AI is.
(I freely admit a personal bias against the fully autonomous company as a goal, even though I believe some parts of organizations require far more automation than they have today)
Retrofitting for AI-Native
When people talk about AI-native organizations (not products), they usually mean companies built around many agents and minimal headcount. That’s a perfectly reasonable definition if you’re evaluating startups. I’m trying to retrofit a few-hundred-person company that’s been around for a few decades. I can’t run that playbook and mostly wouldn’t want to. From that seat, a different distinction has become useful.
Here’s the spectrum-view from my perspective, and it runs along a single axis: what actually changed?
- Manual: nothing yet. The processes are still the processes at whatever level of automation they are at.
- AI-enabled: the speed changed and the structure didn’t. Your people use AI to do the same jobs faster. This is a legitimate operating state, not an immature one. Because the structure didn’t change, the understanding still gets built. But with more work getting done by the same amount of people, cognitive load starts to greatly increase for the humans (which can lead to burnout). The workflows that create understanding still exist, so the organization continues learning as the work gets done; just in a more taxing way for people.
- AI-native: the structure changed. Steps got removed, not accelerated. And the organizational understanding that used to emerge from those steps has to be rebuilt deliberately.
This is why I think discussions about AI-native organizations are incomplete. They spend a lot of time focused on agents, autonomy, and headcount. Much less time on how you redesign the organization once those people exit the workflow.
So the definition I actually use: an AI-native organization is one whose view of its own operations stays current as output and production accelerates. This isn’t about who has the most agents or the best adoption stats. Those are inputs and can be useful. It’s about whether the right information, at the right depth, is actually in front of people when they need it — not just technically accessible somewhere.
Redesigning a Workflow
Automation changes where understanding gets created. If you don’t redesign for that, you haven’t finished automating the process.
Here’s a concrete example of rebuilding that understanding deliberately.
We have a purpose-built roadmap application that tracks what we’ve delivered and what’s coming up. Then we put an MCP server in front of it so anyone in the company can ask roadmap questions from whatever tool they already work in. Commercial teams pull what they need for QBR decks and prospect meetings. Different teams serve different customer bases, and the framing that lands for one book of business isn’t the framing that lands for another.
The important part isn’t that the MCP answers roadmap questions. It’s that it doesn’t answer them from the roadmap alone. It queries the roadmap, then pulls customer context from our knowledge infrastructure (Notion, Jira, Slack) so the answer arrives already framed for whoever’s asking. The roadmap is the artifact. The surrounding context is the reasoning. The system deliberately reconstructs both before handing back an answer.
Answering these questions with the right knowledge and framing used to fall almost entirely on Product Managers. Given that this group is already always busy and oversubscribed, this MCP server allows them to be out of repetitive conversations they never needed to be in the middle of in the first place. The working assumption is that the roadmap itself stays well documented.
Run this through an automation maturity model and it scores as a clean win: a repetitive human step, removed. Run it through our pre-automation questions — what was this step teaching us, and where does that signal go — and things get more interesting. A PM sitting in the middle of every roadmap conversation was synthesizing information from dozens of individual conversations into a coherent understanding of the feature, product, or market. Hearing the same feature asked about three times in one week in multiple ways is a pattern. Noticing which customers leaned on which framing and then being able to think about why is a translation exercise. Catching the objection that pointed at a positioning problem rather than a feature gap is a translation skill. These are the kinds of “between the lines” operations that great PMs do naturally. But take the PM out of the middle of this process and this information stops flowing.
While this might sound like I’m all of a sudden making a counter-argument against automation, I’m not. I’m pointing out that you need to automate the “entire” process and not just the part that moves the work. If removing a human also removes the way your organization builds understanding, the automation isn’t finished until you’ve decided what replaces it.
I’ve written about the culture that makes this specific fix work: low-friction outlets where dumping what you saw or heard is normal, with agents doing the filing. Instead of commercial teams going direct to PMs with all feedback, now they dump information into a #product-feedback channel in Slack, including who made the requests (”I just had a meeting with Tina at Company X and they are insisting that the product needs to be able to handle Y because their organization always does Z”). An agent collects this information, categorizes it and digs deeper if necessary. This frees up the PMs to follow up on requests that require more information and doesn’t force busy people into busywork conversations.
What used to reach Product Management by accident — a PM grabbed in a hallway, a feature mentioned in passing — now reaches them by design, and we haven’t lost the understanding that used to emerge from those conversations. There’s an additional side effect worth naming: this version is auditable in a way the water cooler version never was. When feedback flows through a channel and an agent files it, there’s a record of who asked for what and when. The roadmap server logs its queries too. Signal that used to evaporate when the conversation ended now has a paper trail.
That’s the whole distinction in one workflow. The same setup, minus the channel and the logs, is an organization getting faster and blinder at the same time. No autonomy scale would flag the difference. The automation is identical. The understanding isn’t.
This isn’t really a roadmap story. It’s a pattern that shows up anywhere a person used to sit between a request and an answer: support escalations, sales-to-CS onboarding handoffs, even the Notion feedback pipeline at the beginning of the article. The workflows change. The design problem doesn’t.
Before You Automate
You can probably name the workflows in your organization that require judgment, translation, or pattern-matching. Those are the ones building understanding while they move work. Before you automate one of those workflows, ask yourself two questions:
- What is this step teaching us?
- Where will that understanding come from after it’s gone?
If you don’t have an answer to the second question, you haven’t finished redesigning the workflow.
The old operating model solved that problem almost by accident. The new one has to solve it deliberately.
