What PulseAd is

Read this first. It’s the map the rest of the docs assume — what PulseAd is, the names you’ll hear (and which are current vs. retired), what the product is made of, and the one behavioral rule (reads freely; changes never bypass the approval path) that lets you predict the rest.

This is an internal doc: it describes the real current state, including legacy surfaces and features that are live for only one pilot brand. Where something is messy, it says so rather than smoothing it over.

What PulseAd is

PulseAd is the company and the platform. Its product is Pulson — an agentic Amazon-advertising product. You talk to Pulson in natural language about your Amazon ad accounts — “why did Brand A’s ACOS jump last week?”, “draft a budget cut for my worst Sponsored Products campaign,” “build me a weekly performance report” — and it answers from live account data and can act on the account (adjust budgets and bids, pause campaigns, change keywords and targets) once a human approves the proposed change.

Under the hood it is a chat agent that reads freely and writes carefully, on top of a multi-tenant model of who-can-see-which-Amazon-account. Almost everything else is a consequence of those two facts.

The product is more than the chat. PulseAd also runs the data & semantic layer that the analyst reasons over, a creative suite (image and video generation), the data ingestion that brings non-Amazon channels in, and an internal operator cockpit (AOP) that staff use to drive accounts directly.

The name map

You’ll hear several names; here’s the canonical map. Rule of thumb: “PulseAd” is the company/platform; “Pulson” is the product.

Name	What it is
PulseAd	The company and the platform. Also `PULSEAD`, the main Snowflake schema (218 source tables). It’s the platform, not a UI.
Pulson	The product — the agentic Amazon-advertising app the customer uses. The current, canonical brand name.
Action agent (`action_chatbot.py`)	The live chat engine behind Pulson — a LangGraph multi-agent graph streamed over SSE. The web client uses this action-chat transport by default.
PSM (`psm_chatbot.py`)	The original chat engine, now legacy/frozen. Its `/pulsy/chats` transport remains for compatibility, but new work must use the Action agent.
Pulson agent (`pulson_agent.py`)	A session/memory wrapper around the chat engine. (It can still call the legacy PSM engine underneath — a code detail, not the brand.)
AOP / `aop-hermes`	PulseAd’s internal operator CLI — staff enter with `aop`, configure with `aop setup`, and launch a Pulse Library brand workspace with `aop launch`. It is a separate tool from the product, and its writes are not behind the product’s approval gates (see Capabilities).

Live: PulseAd, Pulson, the Action agent, the Pulson agent, and AOP (a separate surface). Deprecated: PSM (frozen — don’t build on it). The product was rebranded in 2026, with an earlier dashboard product before it — see the timeline and what’s deprecated.

What the product is made of

Surface	What it does	Where it’s documented
Analyst / chat	Ask, analyze, report, and propose-then-approve changes — the Pulson product. The web agent hub groups the available flows into Reporting Results, Campaign Execution, and Strategic Planning.	Guides, Capabilities
Data & semantic layer	What Pulson knows: six domain analysts over Snowflake, refreshed nightly.	Data model
Capabilities	The read-vs-write boundary and the approval gates.	Capabilities
Creative	Generate and vary ad images, and generate video.	Creative
Data & coverage	Which channels Pulson sees — Amazon plus off-Amazon (Meta, Google, TikTok, …).	Data & coverage
Operator tooling (AOP)	Internal staff CLI (`aop-hermes`) — a separate tool.	CLI

How it’s shaped (at a glance)

Key Exhibit — how Pulson and AOP reach Snowflake. Boxes link to their docs. Pulson's pulsead-agents and AOP also read/write Amazon Ads (mutations); this exhibit focuses on the Snowflake analytics paths.

Three pieces, one brain between them:

The app — the Pulson web app you sign into (Next.js, Auth0).
The API (ai-api) — the brain. It authenticates you, resolves which advertising data you’re allowed to see (team + country), runs the agent, and streams results. FastAPI + LangGraph; runs on OpenAI models (not Anthropic), with Postgres for state and Snowflake for analytics.
The agent layer (pulsead-agents) — the layer that actually touches Amazon. ai-api proxies all Amazon Ads / AMC reads and approved writes to it; it owns the Amazon integration and records every action.

pulsead-agents also runs the operational groups behind campaign health, scheduled Amazon Ads work, and proactive keyword management (Strands + Bedrock AgentCore). Those flows produce operational candidates, then keep a human approval step before mutating Amazon state.

So Amazon-data problems usually surface as a timeout from the pulsead-agents proxy, not as a raw Amazon error.

What it does (the one rule to internalize)

Reads flow freely; changes never skip approval. In a customer Pulson session, an operational change is not executed in the turn: the customer is a requester and the request is routed to the operator owner with an inbox/task entry. In an internal or operator session, execution tools are available only after the agent presents the target/value and receives in-chat confirmation. Where the action-chat mutation path creates a pending request, the approval/apply step dispatches it through pulsead-agents → Amazon.

One internal caveat worth knowing up front: autonomous (non-chat) budget optimization is live for exactly one pilot brand today (shown here as Brand A; the internal brand code is intentionally not reproduced). For every other brand the optimizer computes the decision but sends nothing to Amazon. The full gate model is in Capabilities.

Where to go next

Capabilities — the read-vs-write boundary and the approval gates, in full.
Data model — what Pulson knows and how current it is.
Guides — task-oriented how-tos.
Reference and the glossary — the Amazon-advertising and PulseAd terms the rest of the docs assume.