AI Pods: how GTM teams go AI-native
Most teams don't have an AI problem. They have an AI sprawl problem. A pod pairs a forward deployed engineer with your domain expert to observe the real work, build with the team, and ship AI workflows that are measured, adopted, and tied to revenue.
The model Uber used to embed AI engineers across 16 business functions, adapted for GTM teams.
One pod. Seven steps. On a loop.
How to stop AI sprawl and instrument AI workflows across GTM. Hover any step for the short version. Click it for the full breakdown.
working together
Weeks to minutes
End-to-end workflows compressed.
Adoption that sticks
Built with your team, not for them.
Value proven fast
Small-group MVPs before wide rollout.
Tied to outcomes
Every workflow maps to a metric.
AI adoption and proliferation
Teams don't lack AI tools. They lack adoption. Licenses everywhere, workflows nowhere: disconnected experiments with no owner and no measurable outcome. A pod replaces sprawl with one instrumented loop.
AI-native workflows
A pod doesn't bolt AI onto old process. It rebuilds the workflow around what agents do well, with the people who run it, inside the stack you already own, so it actually gets used.
Best-in-class AI for GTM
Every workflow ships tied to a metric: pipeline, cycle time, hours returned. Wins compound loop after loop until your GTM team operates at the AI-native frontier.
What is an AI Pod?
An AI Pod is a small working unit, a forward deployed engineer paired with a domain expert from your team, shipping AI workflows inside your existing GTM stack. The pod runs a seven-step loop: observe, identify, build, MVP, expand, enable, measure.
Where pods come from
Pods are not a consulting invention. Uber built this model internally: it paired roughly 30 of its most AI-fluent engineers with domain experts in finance, legal, HR, and operations, and gave each pair a tight loop to run. Shadow the real work, build an agent together, validate it with other practitioners, launch it.
The results in the first two months, across 16 pods: capital allocation analysis across roughly 150 cities went from 15 hours to about 30 minutes. Financial pacing reports went from 2 days to about 10 minutes. Marketing web QA went from 2 weeks to under an hour. Uber's CTO called the discoveries “hiding in plain sight”: engineers dropped into unfamiliar domains kept spotting problems insiders had stopped seeing.
Kieran Flanagan reframed the same loop for GTM teams as seven steps. I run that loop as a forward deployed engineer inside client GTM teams. Every system on this site was built this way.
It exists to transform GTM functions around AI rather than let AI sprawl, where lots of tasks get automated but nobody can say whether the team got better. Here's each step as I run it:
Qual and quant. I shadow the practitioner doing the real work, then instrument the workflow with observability tooling to see what actually correlates with outcomes.
Find the highest-impact automation opportunities, not the easiest ones. If a candidate workflow can't be correlated to an outcome, it doesn't make the list.
Engineer and domain expert build the workflow together. Not for them, with them. That's the difference between a demo and a system your team runs.
Deploy to a small group first and see if the results hold before rolling it wide.
Push it to more people. Does it generalize, or did it only work for the pilot group?
The most undervalued step. Someone has to train, hold hands, and make sure the workflow actually gets used. Building is 40% of the job. Adoption is the other 60%.
Close the loop back to observability. What worked, what didn't, and what does the pod build next?
Pod methodology adapted from Kieran Flanagan's agentic-pods framework, which builds on how Uber runs internal AI pods.
Inside the pod: every step, broken apart
The loop looks simple from orbit. Up close, every bubble is its own set of actions with its own exit bar. Here is each step the way I actually run it with clients, with receipts from real engagements. Industries named, clients kept anonymous, numbers real.
Observe
Get inside the real work before touching anything. Qual and quant.
Start with a lay of the land. One session mapping the data environment, the tools actually in use, and what the team is on the hook for this quarter.
Shadow the practitioner. Sit in the standups. Watch a rep work a list. Watch the ops lead assemble the Friday report. Process diagrams lie; screens do not.
Break the workflow down to first principles. What is actually happening, where the data lives, and what context the work depends on.
Instrument at scale. Call transcripts, CRM field audits, cycle time and turnaround measurements. Shadowing shows the shape of the work. Instrumentation shows what correlates with outcomes.
Document the friction. Where notes die, where handoffs slip, where the hours pool.
At a life sciences QMS company, shadowing the GTM org surfaced the real picture fast: reps transcribing call notes by hand, customer success monitoring 34 accounts news story by news story, leadership waiting on manually assembled weekly reports. That map became the build queue for everything that followed.
Hands off to Identify: an instrumented baseline. You cannot rank opportunities you have not measured.
Identify
Pick the highest-impact workflow. Not the easiest one.
Score every candidate on value and effort. High value, low effort goes first. Easy but pointless never makes the list.
Require an outcome correlation. If a workflow cannot be tied to a metric like pipeline, cycle time, or hours returned, it does not qualify. This is the test that kills AI sprawl.
Check the raw materials. Scale, repetition, business impact, and data availability. No data, no automation.
Scope with a beginning state and an end state. Define where the workflow starts and where it must land. The middle becomes the build plan.
Commit to one painful workflow. Resist the platform rebuild. The first win buys permission for the next ten.
At a mobile app security company, re-engagement timing was calendar guesswork. Identify pointed somewhere better: signals. Job changes, funding, job postings, review activity, and intent data stacking on one account inside a time window. That single reframe produced four signal-driven plays.
Hands off to Build: a scoped target with its success metric attached, so the build starts with the finish line defined.
Build
Engineer and domain expert build the workflow together. Not for them. With them.
Run co-building sessions like open office hours. The domain expert is in the room, steering. The team watches the structure go up and asks questions. That is how capability transfers.
Teach the system the client's context. Most of the build is context engineering: what the CRM fields actually mean, the schema, the business rules, the voice. The agent is only as good as the context it holds.
Build inside the stack the team already owns. HubSpot, Salesforce, Make, n8n, Slack, Claude. No parallel platform to migrate to later.
Gate it with a human from day one. Approve or reject in Slack or a review workbook before anything touches a customer or a system of record. Autonomy is earned later.
Ship the first working version in days. A live workflow the expert can react to beats a perfect plan.
At an energy data and analytics company, the build was a research and reconciliation pipeline: corporate family mapping with a citation on every claim, schema validation, and field-by-field Salesforce comparison. At a quote-to-cash SaaS startup, the build wired five-touch personalized sequences into a workbook where a human approved every lead before enrollment.
Hands off to MVP: a gated, working system ready to face a small slice of reality.
MVP
Deploy to a small group first. See if the results hold before you roll it wide.
Start with a tiny real batch. Three to five records, one rep, one persona, one play. Never the whole dataset on day one.
Use real data that matters. Pilot on the accounts the team already cares about this quarter, not synthetic samples. Real stakes make real feedback.
Measure against the baseline. Compare cycle time, completeness, and response against the numbers Observe captured. Watch completeness and trust, not vibes.
Hunt edge cases on purpose. Expect roughly 5 to 10 percent of runs to surface something weird. Log the failure patterns, fix the workflow, run it again.
Hold a high bar before scaling. Aim for roughly 95 percent success before full automation. At scale, the missing 5 percent is what everyone notices.
At the quote-to-cash SaaS startup, the outbound motion ran one segment and one persona first, with 100 percent of sends human-approved. At an edtech company, one product release went through the new tiered asset factory before any calendar-wide rollout.
Hands off to Expand: a validated workflow with known failure modes, safe to put in more hands.
Expand
Push it to more people. Does it generalize, or did it only work for the pilot group?
Scale when the numbers hold across segments. Different deal types, different territories, different reps. Generalization is the test, not enthusiasm.
Keep the engine constant, swap the context. New personas, verticals, and account lists slot into the same flow. One managed workflow with filters, never a clone per rep. Clones are where systems go to rot.
Loosen the gates where trust is earned. Human review stays on high-stakes touches; proven low-risk paths graduate to self-serve.
Expand deliberately. Once the team sees what is possible, requests flood in. Sequence them; keep the queue lean.
Checkpoint the batches. Guardrails on volume and spend so scale can never run away quietly.
At the life sciences QMS company, one painful workflow grew into 25 workstreams across six GTM functions, expanded in waves: marketing first, then demand generation, then the revenue layer. At the energy data company, the pipeline processed thousands of records in checkpointed batches instead of one runaway job.
Hands off to Enable: a scaled system that now needs owners, not just users.
Enable
The most undervalued step. Building is 40 percent of the job. Adoption is the other 60.
Name an owner for every workflow. A system nobody owns is sprawl with better branding.
Train operators, not spectators. Templates, intake forms, runbooks, and documented failure modes so the team runs the system without the engineer in the room.
Hold office hours until it is muscle memory. Live co-working in Slack, questions answered in the open where everyone learns.
Record everything. Screen-recorded working sessions become the self-serve library for the next teammate.
Make setup self-service. One-command onboarding and one-click updates from a shared library, so nothing depends on hand-distributed files.
At the life sciences QMS company, 14 production agents each shipped with a named owner. At the edtech company, coordinators now run the asset factory themselves: PMMs review strong drafts instead of writing from a blank page.
Hands off to Measure: trained owners producing consistent usage data worth measuring.
Measure
Close the loop back to observability. What worked, what did not, and what do you build next?
Compare against the instrumented baseline. Man-hours, cycle time, replies, meetings, CRM completeness. Before and after, with numbers on both sides.
Judge by shipped and moved. Deliverables shipped, metrics moved. Activity is not a result.
Feed corrections back into the system. Domain experts review the near misses; their judgment gets versioned into the workflow so the improvement is permanent, not tribal.
Report without meetings. Rollups assemble themselves from the workflows' own telemetry.
Queue the next build. The measurement conversation is the next Observe session. The loop does not end; it turns.
At the mobile app security company, the Friday executive report now assembles itself from live GTM activity: zero manual collation, leadership reads one document. At a cyber deception company, account selection logic that once lived in one person's head now survives personnel changes because the system carries it.
Hands off to Observe: everything the pod learned this cycle. Loop two starts smarter than loop one.
One loop is a win. The loop on repeat is a transformation.
The steps are not a checklist, they are a conveyor. Observe hands Identify a measured baseline. Identify hands Build a target with the finish line attached. Build hands MVP a gated system, MVP hands Expand a validated one, Expand hands Enable a scaled one, and Enable hands Measure the owners who keep it honest. Measure hands Observe the next target. Nothing is wasted between steps.
Then it compounds. The context files, schemas, and plugins from loop one make loop two faster. The trust earned in the first pilot makes the second pilot easier to staff. At a life sciences QMS company this is how one workflow became 25 workstreams across six functions with 14 owned production agents: not one big transformation project, but the same small loop run again and again, each pass expanding to an adjacent team.
That is the difference between AI sprawl and an AI-native GTM team. Sprawl automates tasks and hopes. The pod instruments workflows and knows.
Pods for GTM and revenue systems
Every system featured on this site, from RevOps automation to campaign operations to the AI SDR, gets built the pod way. Pick a function and walk the loop.
The RevOps pod
The target workflow: every client meeting becomes CRM updates, action items, and weekly reporting. Automatically. This is how the RevOps Automation System featured on this site gets built inside a client stack.
The marketing ops pod
The target workflow: campaign intake to launch without the coordination tax: the Campaign Operations Hub and Content OS featured on this site, built with the team that runs the calendar.
The pipeline pod
The target workflow: outbound that fires on signals instead of calendars: the AI SDR system plus plays like closed-lost re-engagement and micro-campaigns, run as one loop.
AI Pods, answered.
The questions teams ask before spinning up a pod.
What is an AI Pod?
An AI Pod is a small working unit that pairs a forward deployed AI engineer with a domain expert from your team to ship AI workflows inside your existing stack. The pod runs a seven-step loop of observe, identify, build, MVP, expand, enable, measure, so every workflow is built with the team that runs it and tied to a measurable outcome.
What problem do AI Pods solve?
AI adoption and proliferation. Most GTM teams have AI sprawl: many licenses and experiments, no owner, no measurable impact. A pod concentrates that energy into one instrumented workflow at a time, proven on a small pilot group before it rolls wide.
Who is in an AI Pod?
Two people at the core: an AI engineer who builds, and the domain expert who does the real work today: a RevOps lead, a campaign manager, an SDR manager. An executive sponsor owns the outcome metric. Pods stay small on purpose.
How is an AI Pod different from hiring an AI consultant?
A consultant advises from the outside; a pod builds from the inside. The engineer is embedded in your stack and your meetings, ships production workflows from week one, and spends as much time on enablement and adoption as on building, then transfers ownership to your team.
How fast does an AI Pod show results?
The first working workflow typically ships in days, not months. It runs as an MVP with a small pilot group for a couple of weeks; if the results hold, it expands. You see measured outcomes inside the first month rather than waiting on a transformation roadmap.
Which GTM functions can run as a pod?
Any function with a repeatable workflow and a measurable outcome: RevOps (meetings to CRM updates and reporting), marketing ops (campaign operations and content), pipeline (signal-triggered outbound and closed-lost re-engagement), customer success, and enablement.
How do you measure whether an AI Pod worked?
Instrument the workflow before and after. Every pod workflow maps to a metric: CRM completeness, campaign cycle time, replies and meetings booked, hours returned per week. The final step closes the loop: what worked, what didn't, what to build next.
What does the domain expert actually do in a pod?
They are half the pod, not a stakeholder on the sidelines. The domain expert steers the build in co-building sessions, defines what good output looks like, reviews the near misses during the pilot, and becomes the named owner or trains the person who will be. The engineer transfers the system; the expert keeps it alive.
What happens when the engagement ends?
The team keeps the system, the context, and the skills. Workflows ship with named owners, runbooks, documented failure modes, and recorded working sessions, and the whole engagement runs inside the client's own stack and accounts. Typical pattern: two to three months embedded shipping the first use cases, then the team builds on its own with office-hours support as needed.
Why not just roll out AI tools to everyone at once?
Because that is how AI sprawl starts: licenses everywhere, workflows nowhere. Uber's pods worked because each pairing proved one workflow at a time with validation before launch. The pod applies the same discipline to GTM: a small pilot, a roughly 95 percent success bar before scale, and a metric that says whether the team actually got better.
Spin up your first pod.
One function, one domain expert, one measured workflow, live inside your stack in weeks. I bring the engineering; you bring the person who knows the work.