Designing a Grounded, Read-Only Marketing Intelligence System for a B2B Data and AI Services Firm
SQL-Grounded
answers
Read-Only
by design
Wippy Agent
runtime
Solutions
Industries
Technologies
About THE Project
A B2B marketing team was running a serious paid marketing program across four ad platforms, a separate web analytics dashboard, Pardot and Salesforce, and none of those systems aligned with each other. Pulling a straight answer meant a person stitching numbers together by hand, which is why campaign problems surfaced days or weeks after the budget was already spent, and why the VP of Marketing described his core feeling as having no idea what was going on. Spiral Scout designed a five-agent intelligence system on Wippy, an open-source actor-model runtime, that reads from every one of those sources, normalizes them into a single warehouse, and answers questions in plain English. The architectural constraint that anchors the whole build is simple and strict: an agent cannot state a number it has not verified with a real query, and it discloses how confident it is every time. The result is an operational layer that gives marketing leadership trustworthy answers the same morning, not the following week.
Objectives
- Replace manual cross-platform reconciliation with one normalized warehouse that every agent reads from, so the numbers are identical no matter which agent you ask
- Guarantee that every numerical answer is backed by a logged SQL query against real data, never an estimate or a fabrication
- Detect spend and campaign anomalies within hours instead of weeks, using thresholds the team defines
- Make the lead funnel visible from MQL through opportunity, broken down by rep and by campaign
- Give marketing leadership plain-English query access to live data without dashboards, SQL, or waiting for a weekly call
- Enforce read-only access at the architecture level, so the system can surface a problem but can never pause a campaign or change a record
Challenges
Solutions
Four ad platforms, a web analytics dashboard, and a CRM that never agreed
The team was reconciling numbers across separate ad-platform dashboards, a third-party analytics tool, and Salesforce by hand. The discrepancies created friction with leadership and meant the VP of Marketing was personally digging through ad accounts to answer questions that should have been automatic. Standard dashboards do not fix this, because they sit on top of the same unreconciled sources.
One normalized warehouse, raw data preserved, attribution windows handled automatically
Spiral Scout designed a single PostgreSQL warehouse on AWS with a three-stage flow: collect the exact platform response and store it untouched, normalize every platform into one shared vocabulary (spend converted to USD, campaign hierarchies mapped to a common dimension, lead stages aligned), then serve agents exclusively from the normalized layer. Because ad platforms restate conversion data for days after a click, the system re-pulls the trailing window on every sync and converges on the platform’s final figures with no manual reconciliation. A cross-platform question becomes a single query instead of a union of incompatible tables.
An AI that fabricates a number is worse than no AI at all
The entire value of a conversational analytics layer collapses the first time it confidently reports a metric that turns out to be invented. For a leader who already does not trust the numbers, a plausible-sounding hallucination is a liability, not a feature.
A hard tool-grounding constraint, enforced and logged
The non-negotiable design rule is that the conversational agent cannot return a numerical claim that is not produced by a real SQL query against the warehouse, and every such query is logged and inspectable. If the data to answer a question is missing or incomplete, the agent says so rather than filling the gap. Users can open the query log and see exactly how any answer was retrieved.
Cross-channel attribution is easy to fake and hard to trust
Connecting a lead back to the campaign that produced it is the hardest problem in the system, and a single confident attribution number with no caveat invites bad budget decisions.
A three-tier attribution model with confidence disclosed on every answer
The system matches leads to campaigns using click IDs first (highest confidence, exact match via gclid and li_fat_id), UTM parameters second (high confidence when naming is consistent), and form-plus-timing inference last (flagged as inferred, not confirmed). Crucially, the confidence tier is disclosed on every attribution answer, so a user never receives a confident-sounding cross-channel figure without knowing how much weight it actually deserves.
The rules for “what counts as a problem” lived in one person’s head, and a write-capable system was an unacceptable risk
The team’s decision logic, the if-I-see-this-I-do-that knowledge, was tribal and undocumented. At the same time, a system with the access to fix a campaign automatically is a system that can break one automatically.
Rules as data, and read-only enforced at three independent layers
The anomaly rules are stored as configuration, seeded from the team’s own decision frameworks, so adding or adjusting a threshold is a single database edit with no code change and no developer. Read-only behavior is enforced three times over: connector credentials request read-only scopes from each platform, the SQL tools given to agents accept only SELECT statements, and the conversational agent is instructed to decline action-shaped requests and refer the user to the responsible human. The system is structurally incapable of writing back to any source.
our Project strategy
Our approach starts from production judgment: a system that has to be trusted daily and run for years is worth more than one that ships a week sooner and quietly loses credibility. We sequenced the work to de-risk the hardest dependencies first and to leave the client able to operate the parts that change most often.
De-Risk the Data Foundation First
We prioritized the Salesforce integration, the single highest-value and highest-difficulty source, because the lead model has to map stages, rep assignments, and pipeline progression accurately before any funnel answer can be trusted. Each platform sits behind its own isolated connector, so a failure or an API change in one source never stops the others, and the raw-then-normalize pattern means we can always reprocess from the original data.
Encode the Methodology Into Configuration
Rather than hard-coding the team’s judgment, we turned it into data. The decision rules and thresholds that defined good and bad performance were captured in a knowledge base and an editable rules table. This is what lets the people closest to the work tune the system themselves, and it keeps the tribal knowledge in the system instead of in one person’s memory.
Build for Extension Without Engineering Drag
The architecture is deliberately modular: a new ad platform is one self-contained connector, a new alert rule is one new row, and a new agent is one registry entry that reuses the existing tools, knowledge base, and delivery layer. None of these additions touches the connectors, the warehouse schema, or the other agents, so growth in one area does not create risk in another.
Project Results and Impact
This engagement established the architectural north star for the system: a defined, buildable design that did not exist before, centered on a constraint that makes the output trustworthy enough to run a marketing operation on. The long-term bet is that an intelligence layer grounded in verifiable queries, with confidence disclosed and every action audited, is worth far more over time than a faster dashboard that nobody believes.
Tangible outputs:
– A complete architecture and system-design specification for a five-agent AI agent automation system on Wippy
– A normalized PostgreSQL warehouse design with a preserved raw layer and idempotent backfill for ad-platform attribution windows
– Isolated, per-platform connectors for Google Ads, LinkedIn Ads, Microsoft Advertising, Reddit Ads, GA4, and Salesforce
– A three-tier attribution model that discloses confidence on every cross-channel answer
– A rules-as-data anomaly engine, seeded from the team’s decision frameworks and editable without a developer
– Read-only enforcement at three independent layers, making the system structurally unable to modify any source
– Audit and observability surfaces: sync history, anomaly event log, report log, and per-channel delivery audit
– Handoff documentation covering agent configuration, threshold settings, and a general playbook
This is the kind of custom software and platform engineering work that holds up because the durability was designed in from the first decision, not bolted on later.
Key Takeaways
- Takeaway 1 (The Spiral Difference). The value here is not that agents can read marketing data; plenty of tools can do that. The value is in the encoded architectural judgment: the refusal to let an agent state an unverified number, the three-tier attribution with disclosed confidence, and the read-only enforcement that makes the system safe to trust. Those are decisions made by people who have shipped systems that had to survive real scrutiny, and they are the difference between an intelligence layer and a liability.
- Takeaway 2 (Transferability). Any team drowning in numbers that do not reconcile, from several ad platforms, an analytics tool, and a CRM that each tell a different story, has a version of this problem. The pattern of a preserved raw layer, a normalized warehouse, query-grounded answers, and disclosed attribution confidence transfers directly to any operation where decisions depend on cross-source data that has to be trusted.
- Takeaway 3 (The Independence Metric). The client owns the parts that change most often and matter most day to day: their marketing data, their agent configurations and thresholds, their decision rules, and the reports and alerts the system produces. Because rules and thresholds are data rather than code, the team adjusts them directly, with no developer in the loop and no dependency on Spiral Scout’s calendar for routine changes.
Worth a conversation if you’re building a marketing or operations intelligence layer and want a second set of eyes before the architecture hardens? Get in touch.
Related projects
-
Agentic Category-Growth Narrative Engine for Intent AI
LinkA Wippy-based agent system that turns four disconnected retail datasets into one connected category growth story
-
Agent-Driven Conversion Infrastructure for a Telecom Intelligence Platform
LinkSpiral Scout built a post-decision switching assistant that keeps Navi present at the moment users most often abandon.
-
Agent-Driven AI Data Hub with Grounded Executive Reporting
LinkGrounded AI retrieval, generative reporting, and conversational search for an executive data hub. Trusted answers. Stack owned by their team.
-
Temporal Workflow Architecture Consulting for Enterprise Data Services
LinkArchitecture consulting for a visual workflow editor built on Temporal, enabling cross-department automation at enterprise scale.
-
Market Discovery & System Framing for an AI-Driven Investor Relations Platform
LinkEstablished the architectural and market foundation for an AI-native earnings call product.
-
Conversational CRM Agent Orchestration for Salesforce-Native SaaS
LinkShipped a resilient multi-agent architecture that turns complex Salesforce CRM data into a conversational interface for sales teams.
Talk Before You Build
Meet the founders
Tell us your goals
Receive a proposal
Project kickoff
John Griffin
Co-Founder, CEO
Anton “JD” Titov
Co-Founder, CTO
“Anton is an exceptional technologist. I would feel comfortable having him work on any technical challenge.” – Ryland Goldstein, Head of Product, Temporal
