SUPERSTORE FORTY-NINE

#What it is

Superstore Forty-Nine is an agentic analytics system built on Salesforce Data 360 and Agentforce. It takes a business whose customer picture is split across five silos in three systems, and closes the loop those silos structurally can't close: an external signal arrives, identity resolution attaches it to a real customer, an agent investigates it against a governed model, and a review case lands in the CRM with the evidence chain attached.

The scenario is a national office-supplies retailer with a big B2B side. Susan runs purchasing for one of its accounts. She bought a line of office chairs, the chairs started failing, and she said so publicly — "broke after a week. Seriously?" The post carries only her social handle. Nothing connects that handle to a customer record, an order, or the account owner. Returns of the same chair are climbing in the ops team's lakehouse, invisible to sales. Every fact needed to save that relationship already exists inside the company. No system holds them at the same time.

So the problem isn't the dashboard, and it isn't the data. It's signal-to-action latency — how long it takes something true out in the world to become a decision somebody can act on. Today that gap is a person swivel-chairing between three systems, per account, per incident. Forty-Nine closes it in one conversation.

#How it works

• Five sources, three ingestion patterns. Batch file loads for customers, products, orders, and the social listening feed. Zero-copy federation for returns data that belongs to another team's Databricks lakehouse — queried where it lives, never copied. And a derived SQL transform that materializes the author dimension out of the social event stream. Three patterns because the silos are the premise: staging everything into one lake would refute the problem the build is solving.
• Identity resolution over 804 unified profiles. Twenty-six percent of social posts arrive with no customer ID at all. The ruleset unifies CRM identities and social authors into one key — 1,041 links, zero orphans — so @handle → customer → order → SKU → account owner is a walk, not a research project. The unified profile is a key, not a golden record.
• A router agent, not one agent that does everything. Superstore Signal dispatches to two specialists: an Investigator that answers "what's actually driving returns on this account," and an Early-Warning subagent that ranks SKUs on negative-sentiment volume against return rate — leading indicator against lagging. Bounded tool sets per job means each one is testable.
• Bounded, least-privilege actions. Three named Apex actions, and nothing else. The agent cannot free-query the data model. The consequential one opens a standard Case carrying the full evidence chain, assigned for a human to work. Human-in-the-loop by construction, not by policy memo.
• LLM reasons; code decides. Thresholds, filters, and routing are deterministic. The model handles language and judgment calls, and it does that inside the Trust Layer — masking, audit trail, zero retention.
• It lives in Slack. The agent runs where the account team already works, and the same agent runs headless over the Agent API with no UI at all. Its reach was bounded before the first prompt arrived: named OAuth scopes, a pinned run-as user, and an admin-granted doorway.

The claim I'd defend in any room: the semantic layer isn't the finish line, it's the prerequisite. An agent's answer is exactly as trustworthy as the governed definitions underneath it. That's why the modeling and identity work is most of this build and the agent is the small part sitting on top.

#What it taught me

1. The zero-copy claim is real because I checked. The helper tool for creating that data stream hardcoded an ingest mode — it would have silently batch-copied the returns data while I said "federated" out loud. I read the tool's source and hand-built the federation request instead. An Apex class now reaches through Data 360 into the lakehouse at query time. Federation, not migration, from application code.
2. Agents narrate intent convincingly. The first time I asked for a case, the agent replied that it would open one — and created nothing. The CRM said so. The tell is beautiful: a real creation quotes the case number back at you, a narrated one never does. Verify actions against the system of record, never against the narration. That rule is now written into the agent's own instructions.
3. Constraints are the design. The org gated the object that should semantically carry a social handle for matching. Rather than fake it, the handle rides a contact point, the match rule is exact-normalized, and the trade-off is documented in the open — production would use custom party identifiers. Constraint hit, diagnosed, routed around, narrated. That sequence is the job.
4. Observability is designed in, not bolted on. The agent emits its full reasoning trace by design — router handoffs, tool calls with latencies, safety gates, the case number it got back. You can only claim an agent behaves if you can watch it behave.

Honest scope: this is portfolio-scale and built solo. The environment holds a deliberately demo-sized slice of the company — 10,000 orders, 804 customers, 840 federated returns, 510 social posts. Big enough that identity resolution has real work to do and the defect signal has to emerge from noise; small enough that every claim in it can be verified live in one SQL statement. The architecture is the part that holds at national scale. The build proves the decisions, not the user count.