Harshit PaulResume

The agentic marketing stack

2025 2026 · AI adoption across a 20+ team

I started as a Salesforce developer, so when the team needed better instruments I built some of them and specified the rest. What held up was giving people an agent that remembers, and reporting only what changed.

Architecture only on this page. The code and its data belong to my employer; this page covers how the systems are designed.

1. The SEO monitor: git as memory

A small engine I built with Claude Code runs on a schedule. Each run pulls Search Console, scores two things (pages within striking distance of page one that earn no clicks, and query groups where the site competes with itself), then diffs against the last snapshot committed to the repository. The report is a delta: NEW / RESOLVED / PERSISTENT, posted to the team's chat and committed back as the next baseline. The team reads a diff instead of a dashboard.

Two design rules came from being wrong. The engine never exits non-zero: health is judged by the report's title, so a failed run is loud and a green check is not proof. And after the monitor once cried wolf, we added statistical guards (a longer control window, a trend window, impression floors) and wrote the post-mortem into the operating manual.

SEO monitor · sample run on example.dev

Run 27 Oct · 2 new, 1 resolved, 3 persistent

New 2

  • /docs/installpage two, earns no clicks
  • /guides/retries + /blog/retries-explainedtwo pages, one query group

Resolved 1

  • /pricingback on page one

Persistent 3

  • /docs/api-keyspage two, third run
  • /changelogtitle truncated in results
  • /guides/cipage two, second run

Full report and CSVs committed · snapshots/snap-2026-10-27.json

The monitorbi-weekly
$ git log --oneline snapshots/
a1c3e9f  snapshot 2026-10-27
77b0d24  snapshot 2026-10-13
3f9e112  snapshot 2026-09-29
9b2e610  snapshot 2026-09-15
5d07c41  snapshot 2026-09-01
Git as memoryone snapshot a run

Before a change is headlined

  • Longer control window
  • Trend window
  • Impression floors
  • Exit non-zero on failure

Health is judged by the report title.

Guardsadded after one false alarm
Sample data on a demo site.
Run loop: checkout the repo pull the last 14 days score striking-distance and cannibalisation resolve queryURL fetch live titles diff vs the last committed snapshot write the full report and CSVs post the short version commit the snapshot.

2. Competitive intelligence that runs itself

I built this one in n8n. A weekly workflow fetches our main competitors' sitemaps, diffs them against last week's state kept in a spreadsheet, asks a language model for a short read-out on what shipped, and posts the digest. That is fifteen minutes of a marketer's Monday, done every week without one.

Competitor sitemaps · sample week

competitor-a.example 4 new pages under /docs/

competitor-b.example pricing page changed

Read-out: one is adding documentation; the pricing change is a new layout, not new prices.

Competitor loopevery Monday

3. AI adoption as an operating change

The aim was a 20-person team that could ask an agent to draft, audit or measure and get something reviewable back. We standardised on a small set of workflows (content briefs from search intent, on-page audits, answer capsules for AI-search visibility, outreach research) and wrote the rules of use down, including what an agent is not allowed to decide.

What I'd do differently

Write the statistical guards first. A monitoring system that can raise a false alarm spends its credibility faster than it earns it.

Proof

  • statedArchitecture as described; a redacted sample report is available on request. The essay on AI-search visibility draws on the same programme.

Every figure carries how it is known: public links open for anyone; third-party corroborates direction from an independent source; stated is internal analytics, quoted with its date, with a walkthrough available in conversation.