Uplify Ads Assistant — Nestor AI

Nestor AI connects five Google data sources for online stores, detects what changed, explains the business impact, and prepares evidence-backed actions that owners review and approve.

Comment

Inspiration

I run a performance marketing agency, and I keep seeing the same problem. An online store owner asks a simple question such as "Why did sales fall this week?" and gets four dashboards, a spreadsheet, and several possible explanations.

The data is available, but it is scattered across Google Ads, Merchant Center, Google Analytics, Search Console, and the store itself. Each system describes one part of the business. None of them tells the owner what changed, which evidence supports the conclusion, and what decision needs attention now.

I did not want to add a generic chat box on top of another dashboard. I wanted an assistant whose answer could be challenged: show the source, name the comparison period, admit when the data is incomplete, and never change a live advertising account without approval.

I called it Nestor AI.

What it does

Uplify Ads Assistant gives online store owners one workspace for five Google data sources: Google Ads, Merchant Center, Google Analytics 4, Search Console, and PageSpeed.

Nestor is the decision layer inside that workspace. It can read the connected store's metrics, campaigns, products, search visibility, site evidence, audit findings, recent actions, and measured outcomes. It connects related signals and explains the commercial consequence in plain language.

A typical result is not "performance declined." Nestor can say that search spend rose while qualified conversions fell, point to the affected campaigns and terms, show the periods used, and prepare a draft action for review.

The action stays separate from the conversation. The owner can inspect the evidence, edit the proposal, approve it, reject it, and, for supported operations, undo it later. After an approved change runs, the service compares the before and after windows. It labels that comparison as a directional signal rather than pretending it proves causation.

What was new during Build Week

Before Build Week, Uplify Ads Assistant already collected data and ran audits. During the hackathon, I added the Nestor decision and action layer and rebuilt the complete English experience.

Between July 17 and July 18, I used Codex with GPT-5.6 to build and ship:

  • tenant-scoped Nestor chat with typed tools, source citations, conversation history, plan limits, and cost quotas;
  • a shared, versioned knowledge pack that keeps methodology separate from live account evidence;
  • the verification bridge that turns supported audit findings into reviewable actions and blocks proposals that cannot be proved safe;
  • additional Google Ads and Merchant Center executors with pre-state capture, approval, apply, undo, and failure recovery;
  • before/after action outcomes with explicit insufficient-data and non-causality handling;
  • new site, GA4, Merchant Center, Search Console, and PageSpeed evidence used by Nestor and the audit pipeline;
  • regression tests for tenant isolation, quotas, tool boundaries, action expansion, guardrails, outcomes, and incomplete specialist evidence;
  • a complete English product experience and a rebuilt bilingual public site.

The core Nestor implementation is recorded in commit ea67d15 (feat(nestor): ship tenant chat, quotas, and verified actions). The English product work is in 03c99ed. The dated commit history and the primary Codex session provide the boundary between the earlier cabinet and the Build Week extension.

How I built it with Codex and GPT-5.6

I used Codex running GPT-5.6 as an engineering partner across the repository. My role was to set the product rules: which evidence an owner should trust, which actions are acceptable, when the system must stop, and what "human control" means in practice.

Codex traced data through five Google integrations and the existing audit code before changing the architecture. That mattered because a convenient local fix could easily break tenant isolation, double-spend an LLM quota, or apply an action against the wrong account.

We worked in a repeated loop:

  1. Trace the current behavior and identify the real source of truth.
  2. Write the safety invariant before implementing the feature.
  3. Build the smallest complete path through API, database, worker, and interface.
  4. Ask GPT-5.6 to challenge the assumptions and search for failure cases.
  5. Add regression tests for the failures we found.
  6. Run the feature against the live product flow and inspect the interface as carefully as the unit-test output.

This process caught issues that happy-path development would miss: concurrent quota reservations, stale preconditions during undo, unsupported proposals slipping into the action layer, empty specialist evidence, cross-account mutation risks, and model output that looked reasonable but did not match the required schema.

Codex also handled work outside the backend. It implemented the English application flow, redesigned both landing pages, added the new brand mark and screenshot lightbox, corrected responsive layouts, prepared OAuth verification assets, and assembled the final demo with an English voiceover and synchronized subtitles.

Technical architecture

The backend uses FastAPI, SQLAlchemy, PostgreSQL, Redis, and Celery. Scheduled workers sync connected sources and create durable evidence snapshots. The product talks to the Google Ads API, Merchant API, Google Analytics Data API, Search Console API, and PageSpeed Insights API.

Nestor's model gateway is isolated from the rest of the product. Every model call is budgeted and logged. Tool execution remains server-side and tenant-scoped. Model responses must pass Pydantic schema validation before the application accepts them. The model cannot write directly to an advertising account.

The production reasoning loop currently uses Claude Sonnet through that dedicated gateway. For Build Week, Codex with GPT-5.6 was the engineering environment used to design, implement, review, and test the new system. The Codex session and dated commits document that work.

Supported changes go through a separate action system. It verifies the proposal type, checks plan and pilot permissions, captures prior state, applies a bounded mutation, records the result, and exposes undo only when the executor can reverse the operation safely. Unsupported or ambiguous changes remain recommendations for manual review.

Challenges

Producing a convincing answer was easy compared with deciding whether the evidence was strong enough to become an action. Models can sound certain long before the product has earned that certainty.

Advertising data also disagrees with itself. Google Ads and GA4 use different attribution logic. Merchant Center issues may arrive later than product edits. A before/after improvement does not prove that one action caused it. Nestor had to preserve those distinctions instead of smoothing them into a confident story.

Multi-tenancy was just as hard. Nestor needs broad read access inside one store, but it must have no path into another store. The tool layer, action executors, quotas, histories, and outcomes each enforce that boundary without relying on the model to behave correctly.

What I learned

By the end of testing, Nestor could investigate more of the account than before, but it had fewer ways to act on its own. That tradeoff made the system easier to trust and test. Conversation, evidence, proposal, approval, execution, and outcome measurement remain separate parts of the product.

Codex was most useful when I let it trace the repository before asking for code. The strongest fixes came from explicit invariants and adversarial reviews with GPT-5.6. Large one-shot implementation prompts were much less useful.

What's next

The next step is a controlled pilot with online stores that already spend on Google Ads. I want to measure whether owners identify problems faster, challenge agency or contractor decisions with better evidence, and approve fewer low-confidence changes.

On the product side, I plan to expand the reversible action library, improve outcome windows for stores with longer purchase cycles, and add clearer evidence-difference views when Google Ads, GA4, and Merchant Center disagree.

Live product: ads.uplify.agency/en

Built With

Share this project:

Updates