What actually changed
Nine months ago we stopped treating AI as a set of tools bolted onto existing workflows and started treating it as the reason to redesign those workflows from scratch. The difference matters.
When you bolt AI onto an existing process, you get incremental speed. When you redesign around what AI makes possible, you get a different kind of work entirely. Roles shift. Interfaces change. The things that used to be expensive become cheap, and the things that used to be cheap — taste, judgment, system thinking — become the bottleneck.
The work does not just get faster; it gets redesigned.
AI-native is not just using AI tools
Every company claims to use AI now. Most are running copilots alongside the same processes they had in 2023. That is not AI-native. AI-native means the process itself assumes AI capability — the way a cloud-native architecture assumes elastic infrastructure rather than treating it as an optimization on top of fixed servers.
For us, that meant rethinking who does what. A product manager who can prototype in code — with AI doing the heavy lifting on implementation — is more valuable than a product manager who writes specs for someone else to build. An engineer who can ship a full feature, including copy, design decisions, and deployment, is more valuable than one who waits for handoffs.
The org chart did not change. The surface area of each role did.
Internal AI needs product discipline
The first thing we learned: internal AI tools need the same rigor as customer-facing products. We built agents, automations, and internal tools with the same product discipline we apply to momoGood itself — clear interfaces, defined inputs and outputs, monitoring, and iteration based on real usage data.
The temptation is to treat internal AI as a hack day project. Ship it fast, move on. But the moment a team depends on an AI workflow for daily work, it is a product. It needs an owner, error handling, and a feedback loop.
The agents
We run four primary AI agents internally, each with a clear domain and interface:
Build Agent — Takes a product brief and produces working prototypes. Not mockups. Functional code that the team can interact with, critique, and iterate on before engineering picks it up.
Content Agent — Drafts, edits, and formats long-form content. Handles the mechanical work of content production so the human writer focuses on insight, voice, and editorial judgment.
Research Agent — Synthesizes competitive intelligence, market data, and user feedback into structured briefs. Replaces the hours of tab-switching and note-taking that used to precede every strategic decision.
Operations Agent — Manages internal workflows: standup summaries, cross-team updates, onboarding documentation. The kind of coordination work that everyone agrees is important and nobody wants to own.
The PRD still matters, but it becomes supporting context. The prototype becomes the shared object.
Workflows: from idea to release communication
The old workflow: idea → PRD → design → engineering → QA → release → marketing writes about it. Each handoff introduced delay, context loss, and reinterpretation.
The new workflow: idea → prototype (with AI) → team review → engineering refines → ship → release communication generated from the prototype and commit history. The prototype IS the spec. The release note IS the changelog, rewritten for humans.
This compression is not about speed for its own sake. It is about keeping context intact. The further a feature travels from the person who conceived it, the more it mutates. AI lets us keep the originator closer to the output, longer.
Microsites made the work usable
One unexpected unlock: we started building internal microsites — small, purpose-built web apps for specific workflows. A hiring tracker. A content calendar with AI-generated drafts. A competitive analysis dashboard that updates weekly.
These are not ambitious products. They are simple interfaces that make AI output usable by people who are not prompt engineers. The interface layer turned out to be as important as the AI layer.
We still have tickets
To be clear: we still use project management tools. We still have sprints, backlogs, and code review. AI did not eliminate process — it eliminated the parts of process that existed to compensate for communication failures.
The standup is shorter because everyone has context. The backlog is cleaner because prototypes surface scope problems before engineering starts. Code review is faster because AI catches the mechanical issues, leaving reviewers to focus on architecture and intent.
The team shape changes
The biggest organizational change: we need fewer specialists and more generalists who can direct AI. A senior engineer who can also write product copy, make design decisions, and reason about go-to-market is worth more than three separate people in those roles.
This does not mean everyone does everything. It means the boundaries between roles are more permeable, and the cost of crossing them is lower. A product manager can ship a prototype. An engineer can write a blog post. A marketer can build a landing page.
The people who thrive are the ones who treat AI as a capability multiplier, not a replacement for learning. They still build deep expertise — they just apply it across a wider surface area.
Closing reflection
Nine months in, the lesson is simple: AI does not make a mediocre process faster. It makes a good process feel inevitable and a bad process feel intolerable.
If your team is using AI but the work does not feel fundamentally different, you are probably optimizing the old model instead of building the new one. The bottlenecks do not disappear — they move. And the new bottlenecks are taste, judgment, and the willingness to redesign how you work.
We are hiring people who think this way. If this resonates, check our open roles.
Continue the conversation on LinkedIn.
This piece is also on LinkedIn — join the discussion, or follow Matthew for the next write-up.
View the LinkedIn post