Applied AI — full context & operating model

Companion to Applied AI Roadmap. The roadmap is the what/when; this is the why — the complete mental model, decisions, and principles the roadmap sits inside. Written to be read by both a human and an agent (Cowork). Nothing here is summarized down; it’s the working context.

0. What this initiative is

An in-house Applied AI function inside a multi-brand ecommerce operation. The operation runs paid acquisition across Meta, Google Ads, and TikTok Ads; owns DTC channels (WooCommerce, landing pages via GTM/GA4); sells on marketplaces (Shopee, TikTok Shop); uses Fighter.my for multi-channel order management on one brand; and is expanding into the US while continuously launching new brands and ad accounts.

Role note (important): This is no longer an agency/consultant engagement. Nadeem has been hired full-time and becomes the in-house Applied AI Operator starting next year. The four systems, the roadmap, the deck, and the earlier “proposal” are now internal builds, not deliverables sold to a client. This changes the physics of the work (see §1 and §7).

1. The theme (the goal everything serves)

Lean scaling: improve productivity and directly increase revenue and net profit — scaling output without proportional headcount growth.

Two equations anchor everything:

Realized AI value  ≈  Applied AI  ×  min(Data maturity, Organization maturity)
Net profit impact  ≈  (labor displaced + revenue lift)  −  (Track A + Track B + Track C spend)

The structural claim behind “lean”: as output grows, A + B + C spend grows sub-linearly (tiered SaaS, shared infra, usage that doesn’t scale 1:1 with output), while the labor you would otherwise hire grows linearly with output. The gap between those two lines widens as you scale. That widening gap is the entire thesis — and it’s why cost mapping (§8) is not bookkeeping but the proof of the thesis.

Implications of going in-house:

Build-vs-Teach reshapes. As an agency, “Teach” meant hand off to the client and exit. In-house and permanent, “Teach” becomes anti-bottleneck insurance: if every workflow routes through Nadeem, that’s a bus-factor of one wearing a lean-scaling costume. Raising organization maturity is how he makes himself scalable instead of the chokepoint.
Horizon lengthens from bounded to open-ended → the compounding assets (warehouse as feature store, historical panel for MMM, the angle library) pay off far more.
His KPI = the top box. Lean scaling → profit is now literally his performance metric.
The vault + Git repo become his operating system for years, not an artifact left behind. Worth over-investing in.

2. The domain model — how the pieces relate

The core insight: this is two substrates and one multiplier, not three peer pipelines.

Data maturity — a substrate. Governs what the org can know and how fast.
Organization maturity — a substrate. Governs how the org operates and what AI can plug into and act through.
Applied AI — the multiplier, not a third substrate. It converts both substrates into output. It is bottlenecked by whichever substrate is weaker.

The gating law: value ≈ AI × min(data, org). You cannot out-AI a maturity gap. Pour sophisticated agents onto a weak substrate and you get very little — the connectors have nothing to read, the agents have no captured process to run, the people can’t prompt. This law recurs throughout.

The revised topology

The two maturities don’t feed AI directly. They first converge into a shared context/knowledge layer (“the something”). Both surfaces of Applied AI draw from that same layer. AI-as-product is not a detached island — it’s a sibling surface fed by the same fuel, and a multiplier in its own right.

        LEAN SCALING   (outcome: more output, flat headcount)
              ▲
        APPLIED AI   (the multiplier — one discipline, two surfaces)
              ▲
      ┌───────┴────────┐
  INTERNAL          AI AS
  LEVERAGE          PRODUCT        (two surfaces — same fuel, sibling roles)
  creative,         customer-facing,
  social,           + extra product axis
  reporting
      ▲                ▲
      └───────┬────────┘
      CONTEXT & KNOWLEDGE   ("the something" — warehouse tables + Git/Obsidian vault)
              ▲
      ┌───────┴────────┐
  DATA             ORGANIZATION
  MATURITY         MATURITY        (two substrates)
  Starter→         Tooling→
  Growth→          Process→
  ML→              Literacy→
  Real-time        AI-native
  (Track B)        (Track A)

Read bottom-up: the two substrates produce the shared context; both AI surfaces consume it; both roll up through Applied AI into lean scaling.

3. The two maturity ladders

Data maturity (RudderStack modern-data-stack framing)

Starter → Growth → Machine learning → Real-time

Starter: basic tracking.
Growth: warehouse, dbt, BI layer. This is the target rung for near-term work.
Machine learning: forecasting, predictive, auto-insight. Key nuance: the ML stack (own models, real MLOps) is likely overkill for lean ecommerce, but ML outcomes (forecasting, predictive signals, auto-insight) are now reachable via the AI multiplier sitting on a solid Growth stack — without the heavy stack. The warehouse-as-MMM-feature-store is exactly this: an ML outcome built pragmatically (historical panel accruing now for future MMM), not a data-science org.
Real-time: the activation layer — data flowing back into tools fast enough to act on (creative team sees performing creatives immediately, no manual reporting). It’s the genuine top rung, the hardest/most expensive, and where both ladders converge. Sequence it last.

Measurement philosophy is MER-based, not deterministic last-click attribution. In a privacy-era multi-channel operation, modeling the gap between campaign-level spend and backend revenue beats false precision from UTM/click-ID spines. (Over-engineering attribution was explicitly corrected.)

Organization maturity

Tooling adoption → Process capture → AI literacy → AI-native ops

Tooling adoption: work actually lives in software (not in heads, not in WhatsApp). This is the base rung — see §5.
Process capture: workflows defined, documented, repeatable. This rung does the quiet heavy lifting — an agent can only take over a process that’s been made explicit. Much of the “Teach” work is really process-capture work, not AI training.
AI literacy: people can actually drive the tools (prompt, delegate, review).
AI-native ops: work designed around agents from the start.

4. The two infrastructures (a distinction that was initially folded together)

There are two kinds of infrastructure, serving the two pillars:

Data/AI infrastructure (Track B): the warehouse, the Git/Obsidian vault, the MCP servers. Substrate for knowing and reasoning.
Organizational infrastructure (Track A’s base rung): the coordination tooling the org runs on — Slack, Notion/ClickUp, Google Workspace. Substrate for coordinating and being AI-pluggable. This is the “tooling adoption” rung made explicit — not a new track.

The WhatsApp situation (current state)

The organization currently coordinates on WhatsApp. That means the org-infra rung is on the floor, with two consequences:

It caps organization maturity outright. You can’t do process capture in WhatsApp — no structure, no persistence, nothing searchable. The org-maturity climb starts with getting onto structured tools.
It blocks the org-context slice of AI. WhatsApp is not a first-party connector, so Claude’s connector/enterprise-search value (see §9) can touch none of the org’s conversations.

But be precise about what it does and doesn’t gate:

Not blocked: the near-term product track (creative, ideation, marketing reporting) draws on data infrastructure and creative libraries, not on internal chatter. WhatsApp does not block any of it.
Blocked: only the org-context slice — CS/CRM, “what did we decide,” institutional-memory queries — is gated by migration off WhatsApp.

So the WhatsApp → proper-tooling migration is a Track A prerequisite for a specific slice: cheap in dollars, but human-paced. Do it early on Track A; do not let it block the compounding product track.

5. Applied AI — the two surfaces

Both surfaces are the same multiplier pointed different directions, fed by the same context/knowledge layer.

Internal leverage: ops-facing agents — creative, social, reporting, and CS/CRM automation. This is where ~all near-term weight sits.
AI as product: customer-facing agents (e.g., chatbots the brands deploy for their own customers). A sibling surface, fed by the same fuel — but it carries an extra axis internal leverage doesn’t: product concerns for external users (latency, guardrails, PMF). In the current roadmap this surface is thin — CS/CRM is the only near-term touch, and even that is more internal-leverage than sold product. It’s on the map so it has a home, not so it demands attention now.

6. The three execution tracks (three tempos)

The execution view of the domain model. Three tracks, each at its own tempo — concurrent, not sequential, coupled by the gating law.

Track A — Culture & adoption (people; = org-maturity pillar). Tempo: continuous, human-paced, never “done.” Includes org-infra migration (off WhatsApp) and enablement (training, onboarding, support). Paces how fast workflows can be handed off.
Track B — Infrastructure & system (the substrate; = data-maturity pillar + knowledge backbone). Tempo: slow, phased, built in step with adoption. Building a warehouse nobody queries is the classic failure.
Track C — Product & workflow (the applications; = the AI surfaces). Tempo: fast — ship → test → iterate. The compounding engine.

The sequencing rule

Track C never waits for Track B to be “finished.” Each product workflow ships the moment the specific substrate rung it needs exists. Order Track C by least-substrate-required → most, banking compounding early while A and B grind underneath. Matching each product item to its required rung is its place in the sequence.

Two bars on Track C

Shipped (it works, value proven) ≠ handed off (a colleague runs it without Nadeem). Ship at product-speed to compound; hand off at culture-speed. This is the discipline that keeps the fast track from turning every workflow into a Nadeem-shaped bottleneck — critical now that the role is in-house.

7. The cost dimension (ties everything to the theme)

Every track carries cost. Organizational infrastructure is a real bucket that was invisible until it was named.

Track	Cost bucket	Cost model	Examples
A · Culture & adoption	Org infrastructure (coordination)	Per-seat SaaS, recurring	Slack, Notion/ClickUp, Google Workspace — replacing WhatsApp
A	Enablement effort	Labor (Nadeem’s time)	Training, onboarding, support channel
B · Infrastructure	Data infrastructure	Usage + tiered SaaS	MotherDuck, Fivetran/Airbyte, dbt/Dagster+, Omni/Hex
B	Knowledge backbone	Mostly free + light SaaS	Git, Obsidian, Supermemory
B	Connectivity (MCP)	Per-service SaaS	Zernio, Foreplay, Canva
C · Product & workflow	AI runtime	Usage-based, scales with volume	Claude Team/API, image/video gen, scraping
— offset —	Labor displaced	The counterfactual	Headcount not hired as output grows

The theme lives in the last row. Net profit ≈ (labor displaced + revenue lift) − (A + B + C). Lean scaling is the structural claim that A + B + C grow sub-linearly while labor-avoided grows linearly with output — the gap widens as you scale.

The honest tension: org-infra maturity adds cost (moving off near-free WhatsApp onto Slack + Notion + Workspace is net-new spend), which cuts against a cost-cutting theme. Resolution: it’s an investment, not a cost — proper tooling → process capture → automatable → headcount avoided. Size it against the labor it enables, not on its own line. The labor-displaced row is the magnitude everything else is measured against.

8. Tooling & platform decisions (current state of the architecture)

Warehouse stack (architecture resolved):

Ingestion: Fivetran (recommended for dynamic multi-account handling) or Airbyte Cloud (familiar alternative) — TBD.
Warehouse: MotherDuck (Business tier).
Transformation/orchestration: dbt-core + Dagster+ serverless.
Agent access: MotherDuck native MCP server.
BI/dashboard: Omni (recommended, semantic-layer consistency) or Hex (AI-forward) — TBD. Metabase Cloud ruled out (self-hosting incompatible with MotherDuck).
Designed from day one as a future MMM feature store.

Knowledge backbone:

Git repo is the backbone (source of truth + history); markdown files you own. OpenKnowledge (by Inkeep) is the agent-native editor + knowledge base over that markdown — open-source, local-first, git-backed, with native MCP, built-in agent skills, and agentic hierarchical-RAG search, so humans and agents co-author the same files (real-time CRDT). It is the “agent brain” for the shared context/knowledge layer and the retrieval layer both AI surfaces draw on (supersedes the earlier Supermemory note). Obsidian remains a human vault view over the same files — overlaps with OpenKnowledge, so consolidate or run both.
Governance split into declarative (strategy, policy, design, playbook — the agent reads for context) vs procedural (skill packages the agent invokes). Keeps governance from becoming monolithic.
Naming conventions are join keys, not aesthetics — the link between produced assets, Ads Manager ad names, and performance exports.

Publishing / creative: Zernio (organic social scheduling + analytics + hosted MCP, human-approval-before-scheduling), Canva (template autofill + asset hosting via MCP), Foreplay (ad scraping via MCP/API for ideation).

Operator bench (local): Obsidian, GitHub Desktop, Codex, Cowork, Antigravity.

Ad/data platforms: Meta (Business Manager + System User token), Google Ads (MCC level), TikTok Ads (Business Center); WooCommerce (primary OMS), Fighter.my (one brand), Shopee + TikTok Shop (marketplace, dev IDs to be requested).

Claude plan reasoning (Team):

Team’s value for this setup is mainly a licensing + governance substrate for Build-vs-Teach, not a knowledge/collaboration layer — Git + curated MCP already own that.
Standard seat ≈ individual Pro price on annual billing (~$20/seat/mo, 5-seat min), so no cost penalty vs individual accounts, plus admin/billing/spend controls/seat elasticity. Premium seat = 6.25× Pro per session — put Nadeem (builder) on Premium, Operators on Standard.
Custom MCP connectors are available on all plans (incl. Pro), so Team doesn’t unlock the curated MCP servers — it governs connectors (Owner enables org-wide; read/write scoping, e.g. read-only Meta Ads so an agent can’t write to live systems) and adds enterprise search.
Enterprise search (“Ask Your Org”) is a live federated query over connectors (no external index, permission-aware; requires at minimum a Documents + Chat connector). Its value is strictly proportional to how much org knowledge lives in connected tools — which is exactly the org-maturity gating, and exactly why the WhatsApp situation matters. Custom MCP can be plugged into it to span both the SaaS exhaust and the curated layer.

9. Implementation scope (the systems) — see roadmap for phasing

Proposed:

Ideation agentic workflow — scrape a maintained list of followed brands + Foreplay (MCP/API), break down recurring patterns/formats, feed creative ideation across formats.
Agentic creative production workflow — a paid-ads creative factory producing finished Canva image assets + copy variants for marketers to run manually (explicitly not auto-publishing). Fed by a scraped ads library, an angle library (documented creative angles in Obsidian as agent strategic context), a raw-materials catalog, and a performance ledger (angle-level results). Ad run duration is the primary prioritization signal. A compliance gate requires all copy claims to draw from an approved substantiated list (relevant for the supplement brand Lipidri — holds MeSTI + Halal certs).
Social media management — automated organic publishing across FB, IG, TikTok, Threads. Two tracks: a growth loop (IG/TikTok: scrape → analyze → draft → approve → publish) and an operational track (FB/Threads: templated support/business content). Two-gate calendar: Gate 1 = strategic review of the proposed calendar; Gate 2 = tactical review of finished copy/carousels before Zernio scheduling.
Full-funnel reporting — Tier 1: Cowork + ads MCP for fast reporting (no warehouse). Tier 2: the warehouse unifying ads (FB/TikTok/Google) + WooCommerce + Fighter.my, MER-based.

Exploratory: video generation (UGC-style; pairs with ideation), Shopee + TikTok Shop API (request dev IDs for fuller brand performance), CRM/CS AI automation.

Enablement & support: hands-on training/onboarding on the bench (Obsidian + GitHub, Codex, Cowork, Antigravity) incl. full environment setup and the onboarding path for everything built; plus a standing support channel. (In-house, this is Nadeem’s ongoing job, not a billable line.)

10. Governing principles & decisions (“the laws”)

You can’t out-AI a maturity gap — value ≈ AI × min(data, org); the weaker substrate caps the return.
MER over attribution — model the spend↔revenue gap; don’t over-engineer a click-ID spine.
Managed over self-hosted, even at higher cost — operational leverage and reliability beat cost savings from self-hosting.
Build for scale from day one — the architecture must absorb constant new ad accounts, multi-brand scaling, and US expansion without re-architecting.
Dashboards are the actual product — the warehouse exists to enable precise, fast decisions; insight velocity is the real success metric.
Build infra in step with adoption — never build a substrate nobody will use.
Ship at product-speed, hand off at culture-speed — the two-bars discipline that prevents the operator becoming the bottleneck.
Declarative vs procedural governance — separate what the agent reads (context) from what it invokes (skills).
Git is the knowledge backbone — Obsidian is a view over it; sharing is through Git.
Naming conventions are join keys — the critical link between production, execution, and measurement.
Org-infra maturity is an investment, not a cost — sized against the labor it enables, not judged on its own line.

Next artifacts

Cost model (spreadsheet, in Cowork) — needs real numbers: current tool spend, roles not being hired + loaded cost, growth assumptions. This is where the thesis in §1/§7 gets proven or falsified.
Vault scaffold — actual Obsidian structure, naming spec, seeded angle library, draft policy/skill docs.
Roadmap v2 — fold in the org-infra sub-track and the cost lens.

Career Path

Explorer

Applied AI — Full Context & Operating Model