Most teams add AI one tool at a time. The CRM holds the pipeline, call transcripts sit somewhere else, campaign data lives in ad platforms, and each assistant gets a different slice of the company.
David Arnoux’s GTM OS model starts by connecting that context. Company data and know-how feed a shared layer. Scoring, outreach, ads, SEO, reporting, and other workflows run on top. People approve important actions, and results feed back into the system.
The full setup can be large. Start by choosing one workflow, defining its terms, assigning an approver, and demoing an improvement each week.
The workflows below come from David Arnoux’s independent GTM OS implementations and demo. They are not Extrovert product features.
A GTM OS starts with shared context
David uses “GTM OS” for the software and automation a company uses to find and win customers, connected through shared company context.
That context can include:
- CRM records and pipeline history;
- analytics, ads, product usage, and website data;
- sales calls, support conversations, and market feedback;
- ICP rules, positioning, messaging, and playbooks;
- account research and external signals.
The point is to give each workflow the same basic picture of the business. A scoring engine and an outreach workflow should agree on what an account is, who owns it, which stage it is in, and which messages are off-limits.
Source: David Arnoux’s webinar deck and operating model.
In David’s model, the shared context powers separate GTM apps. One may score accounts. Another may research them, draft outreach, check content, or prepare the Monday pipeline report. A conductor sends work through the right steps, while a person reviews anything consequential before it ships.
The last part matters. A collection of automations becomes more useful when outcomes return to the system. Feed campaign and deal outcomes back into the shared context. Monitor the loop and let people correct it.
Keep core definitions deterministic
An LLM can draft a message or summarize a call. It should not quietly redefine a lead, account, stage, opportunity, or customer every time it runs.
David recommends keeping core business rules deterministic. Write them down once, make them available to every workflow, and change them deliberately.
A useful shared layer may include:
| Rule | What to define |
|---|---|
| ICP | Company fit, buyer roles, exclusions, and priority segments |
| Lifecycle | Lead, account, opportunity, deal, customer, and stage definitions |
| Messaging | Positioning, approved proof, words to use, and claims to avoid |
| Ownership | Who can approve, send, edit, or override each action |
| Quality | Required checks before a draft, score, report, or campaign can move forward |
This is less glamorous than launching an agent. It is also what stops different workflows from acting on different versions of the company.
Start with the definitions your team already argues about. If marketing and sales use “qualified lead” differently, an AI workflow will repeat the disagreement at speed.
The first motion
Build the system one use case and proof of concept at a time.
Pick one motion with a measurable result, such as qualified accounts, reply rate, or reporting time. David often sees B2B teams begin with account scoring, ABM, or outreach. His common B2C starting points are ads, SEO/GEO, and lifecycle work. Those are patterns from his projects.
A simple selection checklist:
- List the motions that matter. Include the work that consumes time, loses revenue, or relies on scattered context.
- Rank impact and ease. A smaller workflow with clean data is a better first proof than a strategic monster nobody can ship.
- Choose one owner. Give one person responsibility for the business outcome and the final decisions.
- Use low-risk inputs first. Read-only access and lower-sensitivity data make the first version easier to inspect and contain.
- Ship a narrow loop. Produce a recommendation or draft, let a person review it, and record what happened.
Do not begin by rebuilding the whole GTM stack. The first proof should answer a specific question: can shared context improve this motion enough to justify the next one?
An explainable signal-to-action workflow
A narrow account-scoring engine combines four types of context:
- Fit: Does the account match the ICP?
- Behavior: What has the person or account done?
- Intent: Have they interacted with the company, product, or content?
- Recency: Did the relevant activity happen recently enough to matter?
A useful score should show its work. The salesperson needs to see why the account moved up, which evidence drove the change, and what action the system recommends.
The output might be:
- review the account now;
- research a recent change;
- draft a message for approval;
- wait because the evidence is weak;
- route the account to another owner.
Use the score to prioritize accounts. David noted that scoring systems produce false positives and that weighting signals is difficult, so the team needs a way to correct each result and feed that correction into the next run.
Human gates and guardrails
Important outbound messages and consequential decisions need human approval. The system may find a signal, prepare research, suggest a next step, or draft an action. A named person reviews what carries real business risk.
That gate can be simple:
- The workflow gathers the approved context.
- It drafts or recommends an action.
- It runs the required quality checks.
- A named owner approves, edits, rejects, or postpones it.
- The decision and result return to the system.
Approval belongs alongside access controls, quality checks, observability, spending caps, and kill switches. Controls vary by workflow and risk.
A sandbox with read-only mirrors can help a team test quickly. A regulated or larger company may need the workflow built inside its existing Azure, GCP, or AWS environment and reviewed at the security team’s pace. Neither route makes a system automatically safe or compliant.
Build versus buy
David’s rule is to buy access to data and infrastructure, then own the middle layer that contains the company’s logic.
Owning the middle layer gives the company more control, but the team must maintain, test, and secure it.
Use three questions for each component:
- Does the vendor own data or infrastructure we cannot sensibly recreate? Buying may be the obvious choice.
- Does this layer contain our definitions, judgment, or competitive workflow? Owning it may matter more.
- Can our team operate it after the first build? A custom system without ongoing ownership becomes another abandoned tool.
Proof-of-concept tools can still earn their place. The goal is to avoid locking the company’s core context and decision logic inside disconnected products that cannot learn from one another.
The operating pod
David’s standard operating unit has three seats:
- Operator or owner: owns the business result, priorities, and internal decisions;
- Ops lead: owns systems, data, definitions, and how the pieces connect;
- GTM engineer: builds, hardens, monitors, and maintains the workflows.
He described his own role as an architect or coach on the side. The goal is a pod that can run without him.
Source: David Arnoux’s webinar deck. The three-seat pod and coaching role reflect his implementation model.
Small teams can combine the operator and ops responsibilities. The important part is preserving both jobs: someone owns the commercial outcome, and someone owns the quality of the data and process.
The engineer needs to be embedded enough to understand the business rules and see the results. Throwing requirements over the wall to a disconnected technical team recreates the same context problem at the people level.
Ship every week
David treats weekly shipping as part of adoption, not project management ceremony.
A weekly rhythm creates a short loop:
- choose the next narrow improvement;
- build it against explicit definitions;
- demo it with real or safely mirrored data;
- let operators correct it;
- record what worked and what failed;
- harden the useful parts before widening access.
This exposes false assumptions early. It also gives skeptical users something concrete to judge. A slide about transformation rarely changes behavior. A working draft that saves time and remains editable might.
Keep one backlog for the pod. Rank work by impact and ease. Finish one pilot before opening five more.
Three moves to start this week
David recommended three practical moves: audit the data, rank the motions, and find the engineering capacity to build and maintain the first workflow.
Source: David Arnoux’s webinar deck.
Turn that into a one-week plan:
1. Audit the data and definitions
Choose one motion. List every system and data source it touches. Check whether the records are usable, whether the team agrees on the terms, and whether access can begin read-only.
2. Rank the first motion
Rank workflows by impact and ease. Check data access and risk before choosing the smallest one that can prove something important.
3. Assign the pod
Name the outcome owner, the ops owner, and the engineer. If two people cover three seats, make the responsibilities explicit. Put the first demo on the calendar.
The first version should produce one trustworthy recommendation or draft that a person can inspect.
Practical questions
Do we need a particular CRM or cloud?
David did not recommend one CRM for every company. His minimum requirement for the system of record is usable API access. The deployment path depends on the company’s stack, security requirements, and stage.
How should we calculate the business case?
David groups it into time or cost savings and top-line impact such as pipeline or closed revenue. He also noted that forecast calculations often miss. Use a proof of concept to test the assumptions before treating projected ROI as real.
How long does implementation take?
David estimated about one month for a scoring workflow and six to nine months for the complete demo-like setup. These are experience-based estimates, not delivery guarantees; scope, data access, definitions, and dedicated engineering capacity change the timeline.
Do operators need an engineering degree or certification?
David’s advice is to learn by building. He made an exception for specific cloud or software certifications that help someone qualify for a role or promotion.