I Built an AI Agent That Reads Everything So I Don't Have To
Staying current in your field means newsletters, blogs, news sites, and analyst notes, and nobody has time for all of it. Here's the agent I built to read them for me.
by Sean Campbell, Assistant Professor of Business
I work in AI, which means my inbox is a firehose. I read 30 to 40 different newsletters each week, and many of those publish daily. For a long time my system was manual: read what I could, save the relevant bits off to Notion or Raindrop.io, and mine those saves later for class material, client conversations, and things to write about.
That system worked right up until it didn't. The saves piled up faster than I could mine them, and the reading itself was eating hours I didn't have. The whole thing depended on me being the bottleneck. Clip-and-file is a fine habit at 10 newsletters. At 30 to 40, with dailies in the mix, it doesn't scale, and I knew it every time a client mentioned a product launch sitting unread in my Raindrop queue.
And that's just the newsletters. Go beyond the Substacks and it gets harder still. Podcasts are some of the best analysis in AI right now, and even when you're funneling them through a tool like Podwise to get transcripts and summaries, that's another system to maintain and another pile to mine. That doesn't count keeping up with the major publications, which cover the field on their own schedule and behind their own paywalls. Each source type you add multiplies the manual work.
So I stopped trying to read faster and delegated the scanning instead. I built an agent that works through my sources on a schedule and delivers a short brief: what moved, why it matters, and what deserves my attention this week. I've been running versions of it for a while now, and it's changed my relationship with staying current. I want to walk you through the build.
The Skimming Problem, and Why Summaries Don't Fix It
The obvious first move is to ask an AI to "summarize my newsletters." I tried that. The output was worthless, and the reason it was worthless is the design lesson at the center of this whole post.
Newsletters are already summaries. A digest of digests gets you headlines about headlines: "Company X announced a new model. Researchers published a study on AI in hiring." I could get that from the subject lines. What I actually need lives one level down, in the analysis the newsletter linked to, the details of the study, the pricing page behind the announcement.
So the first rule I wrote into the agent's instructions: don't summarize the newsletter, follow its links. When a source mentions a product release, the agent opens the release notes. When it cites a study, the agent reads the study, or at least the methodology and findings, not the press release about the study. The brief I get synthesizes the underlying material. That single instruction is most of the difference between a clipping service and an analyst.
A Prompt Won't Do This. An Agent Will.
You could get one decent brief by pasting a pile of newsletters into a chat window with good instructions. The problem, as always, is what happens on week two, and week twenty.
Staying current is a recurring job, and recurring jobs have two requirements a one-off prompt can't meet:
- It has to run without you.The week you're buried in grading and client deliverables is exactly the week you'd skip the manual version, and exactly the week something ships that you needed to know about. My agent runs on a schedule whether or not I'm at my desk. Monday morning, the brief is there.
- The format has to hold still.A brief you can process in five minutes is one where you know where everything is. If this week's version is organized by source and next week's is organized by theme, you're re-learning the document every time, and the five minutes becomes twenty.
The build, then, is less about clever prompting and more about writing a spec. Mine defines the sources (which newsletters, which blogs, which sites), the schedule, the depth rule (follow the links), and a fixed output structure. The structure is where the filtering happens, and it's worth showing mine in full, because the buckets are doing the job my Notion saves used to do:
- Product and tool releases, each with a note on what's different from what existed before
- Model watch, tracking what the major labs (Anthropic, OpenAI, Google, Microsoft) shipped or signaled, since those moves reset the board for everything else
- Voice, video, and image tools, split out on their own because media generation moves on its own timeline and my clients ask about it constantly
- Editorial and hot takes, the opinion pieces and analyst arguments worth engaging with rather than just knowing about
- Important news stories, the funding, policy, and industry developments that don't fit the other buckets
- Studies and research, with the finding and the methodology, not the press release framing
Sometimes these buckets change, so this is just a snapshot of how you might bucket what you’re reading.
Tune It Like an Employee, Not Like Software
The first brief the agent produced was mediocre. So was the fifth. That's worth saying plainly, because people try this once, get a middling result, and quit.
What made it good was treating the early weeks like onboarding a junior analyst. The first briefs over-weighted whatever the loudest sources hyped. So I added instructions: be skeptical of funding announcements, weight shipped products over roadmap promises, and flag when multiple independent sources converge on the same story, since that's usually the real signal. Each week I noticed what the brief got wrong, and each note went into the spec. The agent doesn't learn on its own between runs. The spec is its memory, and I'm the one writing it.
That framing, delegation and supervision rather than tool use, is the actual skill here, and it's the one I teach. This same pattern shows up in the AI courses I lead at George Fox, in the undergraduate business program and in the MBA program, because supervising autonomous work is becoming a core management skill. My students won't manage teams of people only. They'll manage rosters of agents, and the manager who can write a clear spec and then sharpen it based on what comes back will outperform the one who just prompts harder.
Where I Still Go Manual
The agent didn't end my reading. It changed what I read, and being clear about that line is most of what makes the system trustworthy, reliable and useful. A few places where I still do the work by hand, on purpose:
- Anything I'll teach or advise on.If an item is headed for a classroom or a client conversation, I read the source myself, start to finish. My credibility is on the line in those rooms, not the agent's, and "my briefing agent said" is not a citation. The agent's job was surfacing it days earlier than my skimming would have. The reading is still mine.
- Studies and benchmarks.A summary can tell me what a study found. It can't tell me whether to believe it. Sample size, who funded it, what the benchmark measures versus what the headline claims: that's judgment I haven't delegated, and given how much AI research is vendor-adjacent right now, I don't plan to.
- The arguments.When a sharp writer publishes a contrarian take, the summary flattens exactly the part that matters. The reasoning is the content. I have the agent flag these pieces rather than digest them, and I read the two or three best ones whole. I tell my students the same thing: you can't form a position by reading summaries of other people's positions.
- The pattern-spotting across weeks.The agent sees one week at a time. Noticing that three unrelated items over a month point at the same shift, the kind of observation my newsletter posts are built on, still happens in my head. The briefs are the raw material. The connection is the human part, and it's the fun part.
Notice what dropped off that list: the scanning, the triage, the clipping, the filing. The Notion-and-Raindrop labor. That was never the part that made me better at my job; it just stood between me and the reading that did.
The Same Idea Works on Other Platforms. The Mechanics Vary.
I built mine on Claude, using its skills and connectors, because that's where the rest of my systems live. But nothing about the pattern is platform-specific. ChatGPT also has agents and skills, and Gemini has similar tools. The feature names will keep changing, probably faster than this post ages.
The architecture underneath is stable:
- A defined source list, so the agent scans what you chose rather than what an algorithm surfaced
- A depth rule that forces it past headlines into the underlying material
- A fixed output format with a "so what" requirement on every item
- A schedule, so the brief arrives without you initiating it
- A feedback loop, where your corrections become permanent instructions
If your company has standardized on a platform, build it there. The discipline transfers.
What This Isn't
A few clarifications, because I've watched people take the wrong lesson from this kind of setup.
This isn't a replacement for deep reading. The section above should make that plain. The agent decides what reaches me, and it bought back the hours the reading that counts requires. What I believe still gets formed the old way, one source at a time.
The agent doesn't own the judgment. It surfaces and organizes. Deciding what to act on and what to bring into a classroom or a client conversation, that's mine. An agent can also miss things and occasionally over-weight something trivial, which is why I spot-check it against the sources directly every few weeks, the same way you'd audit any delegated work.
And it isn't entirely set-and-forget. The spec needs maintenance as sources change and your priorities shift. Mine might get edited daily, weekly, or monthly depending on what I'm seeing, reading, and deciding on. That's not a flaw in the system. That's what supervising delegated work looks like.
The Reading List Isn't the Job. The Awareness Is.
Nobody's actual job is "read 40 newsletters." The job is to know what's happening in your field well enough to teach it, advise on it, or act on it, and for years the only path to that awareness ran through hours of scanning, so we treated the scanning as the work.
It isn't anymore. The scanning, triage, clipping, and filing are now delegable, and the professionals who figure that out first get their hours back for the reading that still has to be theirs, while staying better informed than the ones still skimming subject lines. The one-off prompt gets you a one-off summary. The system gets you a standing analyst who scans everything, every week, and tells you what's worth your own eyes.
If you build one, I'd like to hear what your spec catches that mine misses. You can send me an email at scampbell@georgefox.edu or connect with me on LinkedIn.
Appendix
---
name: weekly-ai-brief
description: >-
Produce Sean's weekly AI brief by mining his Superhuman "News" split — the standing-analyst workflow from his briefing-agent blog post. Scans every newsletter in the split over any window — 24 hours, 3 days, 30 days, "since my last brief," or a date range (default 7 days) — follows the links to read the underlying articles, release notes, and studies (never the newsletter's own summary), and returns a fixed six-bucket brief: product & tool releases, model watch (Anthropic/OpenAI/Google/Microsoft), voice/video/image tools, editorial & hot takes, important news, and studies & research — every item with a "so what" and a routing tag (LinkedIn, newsletter, classroom, client advisory). Use whenever Sean asks for his weekly brief, "run the briefing agent," "what moved this week," "mine my News split," "what deserves my attention," or "catch me up on the week in AI from my inbox." (Full calendar+inbox rundown = chief-of-staff; features-only = ai-product-feature-tracker; social/web trends = ai-trend-research.)
---
# Weekly AI Brief
Turn Sean's Superhuman "News" split into a short, fixed-format brief: **what moved, why it matters, and what's worth his own eyes this week.** This skill is the production version of the agent described in his briefing-agent blog post. The two design rules that make it work: follow the links (never digest the digest), and keep the output format identical every run.
Before generating anything, read `references/tuning-log.md`. It is the agent's memory — every correction Sean has made lives there, and it overrides any conflicting default in this file.
## Step 1: Pull the sources
Use the Superhuman Mail tools (load them via tool_search first).
**Set the window first.** The pull timeframe is a parameter, not a constant:
- If Sean names a window, use it exactly. Accept any phrasing: "last 24 hours," "past 3 days," "last two weeks," "the last 30 days," "since July 1," "since my last brief," "month to date."
- "Since my last brief" → read the `last-run` line at the top of `references/tuning-log.md` and pull from that date forward. After every completed brief, update that line with today's date and the window covered.
- If Sean names no window, use the default on the `default-window` line of the tuning log (seeded at 7 days). If he changes his default ("make it 14 days going forward"), update that line rather than treating it as a one-off.
- If the request is ambiguous ("catch me up" after a long gap with no last-run marker), ask which window before pulling rather than guessing.
- State the window in the brief's header every time (e.g., "Window: Jul 7-14"), so a wrong window is visible immediately.
Then pull:
1. Confirm the "News" split exists with `list_splits`. If it's missing, stop and ask rather than guessing at labels.
2. Pull threads from the News split for the chosen window with `list_threads`, using the window's start/end as the date filters.
3. For each thread, get the full message content with `get_thread` / `get_message`. Subject lines and snippets are not enough — the links live in the bodies.
4. Volume check: Sean receives 30-40 newsletters weekly, many daily. A 30-day window means hundreds of threads; process all of them, but for windows over 14 days tell Sean the item count up front and confirm before the link-following pass, since fetch volume scales with the window. Do not sample unless he asks for a quick pass, and if he does, say which sources were skipped.
## Step 2: Follow the links (the depth rule)
Newsletters are already summaries. A digest of digests is worthless. For every item that survives triage:
- **Product/tool releases** → web_fetch the release notes, changelog, or product page. Capture what actually changed, pricing if relevant, and availability.
- **Studies & research** → fetch the study itself (or its abstract + methodology section), not the press release. Note sample size, who funded it, and what was actually measured versus what the headline claims.
- **Editorial/hot takes** → fetch the piece and capture the argument's actual reasoning, but see the flag-don't-digest rule in Step 3.
- **News stories** → fetch at least one primary or original source, favoring company blogs, filings, and official statements over aggregator rewrites.
Skip fetching only when the newsletter item is trivially self-contained (a one-line factual update). When a link is paywalled and unfetchable, say so on the item rather than substituting the newsletter's gloss silently.
Triage before fetching: an item earns a fetch if it plausibly lands in a bucket AND could matter to Sean's teaching, clients, or content. Pure promotional filler, webinar invites, and sponsor blocks get dropped without a fetch.
## Step 3: Build the brief (fixed format, every time)
Same six buckets, same order, every run. Consistency is the point — Sean reads this on his phone between meetings and knows where everything is.
1. **Product & tool releases** — each with a one-line note on what's different from what existed before
2. **Model watch** — what Anthropic, OpenAI, Google, and Microsoft shipped or signaled; these moves reset the board, so include credible signals (pricing changes, deprecations, exec statements), not just launches
3. **Voice, video & image tools** — media generation gets its own bucket; clients ask about it constantly
4. **Editorial & hot takes** — the arguments worth engaging with. For sharp contrarian pieces, FLAG rather than digest: give the thesis in one line, say why it's worth reading whole, and link it. Do not flatten the reasoning into a summary — the reasoning is the content and Sean reads the best 2-3 himself.
5. **Important news stories** — funding, policy, legal, and industry developments that don't fit above
6. **Studies & research** — finding + methodology note (sample, funder, what was measured), never the press-release framing
**Every item must carry two things:**
- **A "so what."** Not "Anthropic released a feature" but what it changes and whether Sean should care. An item that can't answer "so what" gets cut.
- **A routing tag.** Where the item earns its keep in Sean's week: `[LinkedIn]`, `[Newsletter]`, `[Classroom]` (George Fox), or `[Client]` (advisory conversations). Multiple tags allowed; an item with no plausible destination is a candidate for cutting.
**Top of the brief:** open with a 3-5 item "worth your own eyes" list — the things Sean should personally read this week, chosen for classroom/client relevance, contested claims needing his judgment, and flagged arguments. This is the manual-mode handoff from his blog post: the agent's job ends where his reading begins.
**Convergence flag:** when multiple independent sources hit the same story, mark it (e.g., "covered by 4 sources") — convergence is usually the real signal.
Length discipline: the whole brief should be readable in about five minutes. Typical shape is the top list plus 3-8 items per bucket. Empty buckets stay in the output with "Nothing significant this window" so the format never shifts.
## Step 4: Voice and delivery
- Run the output through **sean-writing-style** and **humanize-ai-writing**. No em-dashes, no hollow transitions, short direct sentences.
- Default delivery is in-chat. If Sean asks for a file or says he wants to archive it, save as markdown.
- Cite sources on each item so he can click through.
## Judgment defaults (seeded from Sean's spec)
These are the standing analyst instructions. The tuning log extends and can override them.
- Be skeptical of funding announcements; funding is not traction.
- Weight shipped products over roadmap promises and waitlists.
- Vendor-adjacent research gets a methodology note every time.
- Prefer primary sources over aggregator rewrites when both are available.
- Hype-loudness is not importance; one quiet changelog entry can outrank a week of thinkpieces.
## Maintenance (the feedback loop)
When Sean corrects the brief — "too much X," "you missed Y," "always flag Z," "add this source," "drop this bucket item type" — append the correction to `references/tuning-log.md` with the date, in his words plus a one-line operational restatement. Confirm what was logged. The spec is the agent's memory; Sean is the one writing it, and the log may get edited daily, weekly, or monthly depending on what he's seeing.
If Sean asks to change the buckets themselves, update this SKILL.md, not just the log.
—
# Tuning Log — weekly-ai-brief
This file is the agent's memory. Read it in full before every run. Entries below override conflicting defaults in SKILL.md. Newest entries win when two entries conflict.
## Run state (update after every brief)
- default-window: 7 days
- last-run: never (no brief generated yet)
Format for new entries:
```
## YYYY-MM-DD
- Sean's correction (verbatim or close): "..."
- Operational rule: ...
```
---
## 2026-07-14 (seed entries, from the original spec)
- Sean's correction: "The first briefs over-weighted whatever the loudest sources hyped."
- Operational rule: Source loudness carries zero weight in triage. Judge items on shipped substance and relevance to Sean's teaching, clients, and content.
- Sean's correction: "Skepticism about funding announcements."
- Operational rule: Funding rounds go in Important News only when the amount or investor signals a market shift; never lead the brief with a raise.
- Sean's correction: "More weight on shipped products than roadmap promises."
- Operational rule: "Available now" outranks "coming soon." Waitlist-only launches get a one-liner at most.
- Sean's correction: "Flag when multiple independent sources converge on the same story since that's usually the real signal."
- Operational rule: Track story overlap across newsletters during Step 1; annotate converged items with source count.
- Sean's correction: "I have the agent flag these pieces rather than digest them" (re: contrarian arguments).
- Operational rule: Editorial bucket flags, never summarizes, the strongest argued pieces. Thesis + why it's worth reading whole + link.





