RetailIntel: a council of AI agents reading Indian retail

The problem

Indian retail news is spread across the trade press, the business desks that file retail stories, the startup press and stock-exchange filings. Someone deciding where to open a store or which brand to back needs what moved today and what it means, with a way to check it.

Reading all of it is a full-time job. Summarising it with one model call is easy and impossible to trust. The interesting problem is the middle: automated reading that shows its work.

Sources: How RetailIntel analyzes signals, About RetailIntel: how a signal is made

What I built

A council run is a fixed sequence of model calls on one item at a time. A scout decides whether the article is about retail that matters in India and extracts the brands, cities, event type, stated figures and a summary of at most 45 words. An editor agent accepts or rejects the story. Forecaster, competitor, counter-case and reader-lens passes run only on what was accepted.

Every agent returns structured JSON that is stored against the signal, so a bad signal can be traced to the agent whose read was off. No person edits a signal before it publishes; the byline says so and links to how a signal is made.

Readers get Signals, Ask, Research and Competitor Watch on the site, and the same signals through a documented API (an OpenAPI 3.1 document) and a remote MCP server for their own assistants. Reading is free.

It shares a production platform with Clarity Today, not code: one Kubernetes cluster on AWS EKS, Aurora Postgres, Redis, container images in ECR and Argo Rollouts for delivery. Each product has its own code, pipelines and workers.

Sources: How RetailIntel analyzes signals, About RetailIntel: how a signal is made, RetailIntel for developers (API and MCP), RetailIntel pricing

Design tradeoffs

Stop early, spend late.

Items the scout marks out of scope stop there and never cost a downstream call. The expensive passes run only on stories the editor accepted.

Bound the retry, guard the render.

A summary whose first sentence misses the actor and a number, or states a number the article doesn’t contain, goes back for one rewrite; if that misses too, the first version stands. The safety net is at render time: the summary, key facts and watch items are checked against the extracted source facts on every page render, and anything that doesn’t match is dropped for the plain source summary.

Record dissent, don’t let it veto.

Every accepted story gets a counter-argument pass. The counter-case shows on the page only when every figure in it also appears in the source, and it never blocks publication. It is a second reading, not a fact-check by a person.

Publish an event once.

The same canonical URL, a close rewrite of a story from the last six hours in the same theme, or another publisher’s report of the same event within 48 hours becomes a further source on the existing signal. An earlier duplicate page redirects (301) to the one kept, so old links still resolve.

No paywall workarounds.

The council reads what a publisher makes public, often only the feed excerpt, and an item with no readable article behind it isn’t published. Each source has its own cadence and a per-cycle budget, so one slow publisher can’t starve the rest.

Sources: How RetailIntel analyzes signals, About RetailIntel: how a signal is made

What went wrong

RetailIntel started inside the Clarity codebase and moved to its own repository in August 2026. Two products in one repository share more than infrastructure: every change to one is a reason to re-test the other. The platform stayed shared; the code didn’t.

The one-rewrite rule is a real cost. When a rewrite also misses, the first summary stands, and only the render-time check keeps an unsupported number off the page. That check drops the summary rather than fixing it, so a reader sometimes gets the plain source summary instead of the sharper one.

What I’d do at 10x

Ten times the sources is mostly scheduling. Per-source budgets already stop one slow publisher from starving the rest; the next limit is the dedup window, which has to compare each new item with more recent stories as volume grows.

The council stays sequential per item, because that is what makes a bad signal traceable to one agent. Throughput comes from running more items at once, and cost from the scout stopping more of them before the expensive passes.

Ten times the readers moves the load to the API and MCP side. I’d separate the read path that serves signals from the pipeline that writes them, so a busy morning for readers can’t slow down filing.