APIP — Policy Intelligence Platform

The Problem

A multi-unit policy advisory firm — with separate practices across policy, health, gender, and climate — needed to publish more policy briefs to stand out in a competitive advisory market. Speed mattered as much as accuracy: a brief is worth less if a competitor has already told the client about that regulatory update first.

But producing one manually meant working through the same chain every time — gather data, check sources for updates, draft, review, get approval, send to the client — and that chain couldn't move fast enough on its own. In any week with a pressing client engagement pulling the team's attention elsewhere, planned brief output for that week was at real risk of being missed entirely.

The Approach

APIP automates that same chain — gather, check, draft, review, approve, send — so it no longer depends on a team member having the bandwidth to run it that day.

It runs as a scheduled pipeline that pulls from RSS feeds every 15 minutes and pushes each item through a staged sequence: deduplication, a relevance filter, a summary pass, and a client-specific impact analysis — each stage a separate, auditable LLM call rather than one prompt trying to do everything at once. Processed items land in a Notion-based Policy Bank, which doubles as both the searchable output and the pipeline's own tracking state, so the system runs without a separate database.

The hardest problem was avoiding duplicate or flooded output. A brand-new source has its entire historical archive marked as seen on the first run without processing any of it, preventing a flood of years-old articles on day one. From there, layered checks catch different failure modes: per-source tracking of every URL already seen, a 60-day age cutoff as a safety net for tracking gaps, and a cross-check against the existing Policy Bank to catch duplicates arriving from a different source. In production, the system correctly marked over 60,000 historical items across sources as seen without processing a single one — ready to pick up only genuinely new items from the next run.

The LLM layer is provider-agnostic by design: each pipeline stage is assigned a model via configuration rather than hardcoded to one provider, with automatic failover to a second provider if the first errors out. That came from direct experience — an initially-chosen model had API quotas too restrictive for a hosted pipeline despite being on a paid plan, and switching providers meant an automatic config change, not a rewrite.

Every AI-generated summary also goes through a human review step before it reaches a client. The draft is posted to Slack, where a team member can chat directly with the AI to refine it — add nuance, correct a detail, adjust tone — before approving it. Once approved, the AI sends the finished update straight to the client in a predesigned email template, so the team stays the accountable checkpoint without doing the actual writing or formatting.

• Staged pipeline as discrete, auditable LLM calls rather than one prompt doing everything
• 4-layer deduplication design, with zero false processing on first run
• Provider-agnostic LLM layer with automatic failover between providers
• Every summary is reviewed and refined by a human in Slack before an AI-assembled email goes out to clients
• A separate practice team uses historical archive for weekly digests updates

The Outcome