Fix trailing slash redirects on internal links

app/market/page.tsx

@@ -110,7 +110,7 @@ export default async function MarketIndex() {
           Tracking who's building proactive agents, how their architectures
           compare, and what ships next. Analysis scored against the{" "}
           <Link
-            href="/posts/three-primitives"
+            href="/posts/three-primitives/"
             className="text-terracotta underline decoration-terracotta/40 underline-offset-4 hover:decoration-terracotta"
           >
             three-primitives framework

content/drafts/four-repos-one-filesystem.mdx

@@ -6,7 +6,7 @@ accent: "sky"
 dropcap: true
 ---
 
-In [the three primitives](/posts/three-primitives) we argued that a proactive agent needs a clock, a listener, and an inbox. The clock is cron. The inbox is messaging. The listener is the hard one: the thing that wakes an agent up when something changes in the outside world, without the agent having to ask.
+In [the three primitives](/posts/three-primitives/) we argued that a proactive agent needs a clock, a listener, and an inbox. The clock is cron. The inbox is messaging. The listener is the hard one: the thing that wakes an agent up when something changes in the outside world, without the agent having to ask.
 
 We've been building the listener for the past 86 days. This is a look at what it actually took, sourced from `git log` across four open-source repositories, plus a hosted cloud layer. The decisions are interesting not because they're clever, but because they reveal what a proactive agent demands from its integration infrastructure.
 

content/market/proactive-agent-landscape.mdx

@@ -8,7 +8,7 @@ dropcap: true
 
 Six months ago, nobody was really shipping proactive agents. Now every major AI lab either has one in market or has one in internal testing. The convergence is something else: OpenAI, Google, Anthropic, Meta, Perplexity, and several startups all building agents that act without being asked.
 
-This page maps the landscape through the [three-primitives framework](/posts/three-primitives): does each product have a **clock** (scheduled execution), a **listener** (real-time change detection), and an **inbox** (multi-channel delivery)? That framework turns out to be a useful lens for separating marketing from architecture.
+This page maps the landscape through the [three-primitives framework](/posts/three-primitives/): does each product have a **clock** (scheduled execution), a **listener** (real-time change detection), and an **inbox** (multi-channel delivery)? That framework turns out to be a useful lens for separating marketing from architecture.
 
 *Last updated: May 15, 2026.*
 
@@ -50,7 +50,7 @@ Every product on this list runs on a schedule. That's the easy primitive to buil
 
 ## The big labs
 
-**[ChatGPT Pulse](https://openai.com/index/introducing-chatgpt-pulse/) (OpenAI)** launched in September 2025 as part of ChatGPT Pro. It processes chat history, Gmail, and Google Calendar overnight, then delivers 5 to 10 personalized morning cards. The personalization is genuinely impressive. The architecture is [clock-only](/posts/chatgpt-pulse): no real-time change detection, no delivery outside the ChatGPT app.
+**[ChatGPT Pulse](https://openai.com/index/introducing-chatgpt-pulse/) (OpenAI)** launched in September 2025 as part of ChatGPT Pro. It processes chat history, Gmail, and Google Calendar overnight, then delivers 5 to 10 personalized morning cards. The personalization is genuinely impressive. The architecture is [clock-only](/posts/chatgpt-pulse/): no real-time change detection, no delivery outside the ChatGPT app.
 
 **[Orbit](https://www.testingcatalog.com/anthropic-is-working-on-orbit-its-upcoming-proactive-assistant/) (Anthropic)** was unveiled at the Code with Claude conference in May 2026. It generates proactive briefings from connected tools (Gmail, Slack, GitHub, Calendar, Drive, Figma) on a timezone-aware schedule. "Orbit apps" let users pin specific insight views. It has the listener, which puts it ahead of Pulse architecturally, though the inbox is still limited to the Claude interface.
 
@@ -66,7 +66,7 @@ Every product on this list runs on a schedule. That's the easy primitive to buil
 
 **[Writer's Playbooks](https://writer.com/blog/writer-agent-skills-playbooks-press-release/)** are event-driven enterprise workflows: listen for triggers (emails arriving, sales calls completing, files landing), then execute multi-step automations. All three primitives, focused on enterprise teams. The least consumer-visible product on this list, and potentially the most revenue-generating.
 
-**[Notion](https://www.notion.com/product/dev)** is attacking proactive agents from both sides of the stack simultaneously. [Workers](https://developers.notion.com/workers/get-started/overview) are a TypeScript SDK that gives developers three composable capabilities: `sync()` for scheduled data pulls, `webhook()` for real-time event ingestion, and `tool()` for agent-callable functions. [Custom Agents](https://www.notion.com/help/custom-agents) wrap the same architecture in a no-code layer with time-based and event-based triggers, natural language instructions, and Slack delivery. An [External Agents API](https://www.notion.com/product/dev) (alpha) opens the workspace to agents from other providers like Claude, Cursor, and Codex. Early testers built over 21,000 Custom Agents during beta. The positioning is unique on this list: Notion isn't shipping a proactive agent product, it's shipping the primitives as a platform. Deep dive in [Notion ships the primitives](/posts/notion-ships-the-primitives).
+**[Notion](https://www.notion.com/product/dev)** is attacking proactive agents from both sides of the stack simultaneously. [Workers](https://developers.notion.com/workers/get-started/overview) are a TypeScript SDK that gives developers three composable capabilities: `sync()` for scheduled data pulls, `webhook()` for real-time event ingestion, and `tool()` for agent-callable functions. [Custom Agents](https://www.notion.com/help/custom-agents) wrap the same architecture in a no-code layer with time-based and event-based triggers, natural language instructions, and Slack delivery. An [External Agents API](https://www.notion.com/product/dev) (alpha) opens the workspace to agents from other providers like Claude, Cursor, and Codex. Early testers built over 21,000 Custom Agents during beta. The positioning is unique on this list: Notion isn't shipping a proactive agent product, it's shipping the primitives as a platform. Deep dive in [Notion ships the primitives](/posts/notion-ships-the-primitives/).
 
 **[Tonkean's Proactive AI Agents](https://www.tonkean.com/platform/proactive-ai-agents)** operate across 250+ enterprise systems as autonomous digital workers. Their agents run in three modes: time-based (scheduled), signal-based (event-driven change detection), and delegation-based (human-initiated). Delivery goes through Slack, Teams, email, and directly into enterprise platforms. The positioning is explicitly proactive, with agents that monitor continuously and anticipate renewals, risks, or anomalies before teams have to ask. Tonkean focuses on enterprise process orchestration, particularly procurement and operations, which gives it the same bounded-problem advantage as Managerbot and Writer.
 
@@ -94,15 +94,15 @@ We build [Agent Relay](https://agentrelay.com), a developer SDK that provides th
 
 ## What the convergence tells us
 
-Every product on this list arrived at roughly the same architecture independently. Scheduled execution, change detection, multi-channel delivery. The [three-primitives framework](/posts/three-primitives) wasn't so much a prediction as a description of what proactive agents just need to work.
+Every product on this list arrived at roughly the same architecture independently. Scheduled execution, change detection, multi-channel delivery. The [three-primitives framework](/posts/three-primitives/) wasn't so much a prediction as a description of what proactive agents just need to work.
 
 The differences are in coverage and depth:
 
 - **Coverage**: How many data sources can the agent watch? Google has a natural advantage with Remy because it already owns the data. Everyone else is integrating third-party APIs one at a time.
 - **Depth**: Is the listener doing real-time event streaming or periodic polling? The user experience is completely different. A four-hour-old alert is not the same as a real-time notification.
 - **Delivery**: Can results go where the action is (Slack, email, tickets), or are they trapped in the product's own UI? Most horizontal assistants are still trapped.
 
-I think the products that nail all three at depth are the ones people will actually reorganize their workflows around. Everyone else just ships a clock and calls it done, and those end up feeling like [another tab to check](/posts/chatgpt-pulse).
+I think the products that nail all three at depth are the ones people will actually reorganize their workflows around. Everyone else just ships a clock and calls it done, and those end up feeling like [another tab to check](/posts/chatgpt-pulse/).
 
 ## What to watch next
 

content/posts/agent-moves-first.mdx

@@ -17,7 +17,7 @@ Their [Agent for Slack](https://www.coderabbit.ai/agent) is one of the more ambi
 
 ### How does the Slack-native approach compare?
 
-The Slack-native approach is the right call. Engineers don't want another dashboard. They already live in Slack, and putting the agent there means feedback appears in the same thread where the team is discussing the deploy or the incident. We reached the same conclusion building [My Senior Dev](https://myseniordev.com): the review agent's move into Slack ([Act 2](/posts/review-agent-three-acts)) generated more engagement than any UI polish on the web dashboard.
+The Slack-native approach is the right call. Engineers don't want another dashboard. They already live in Slack, and putting the agent there means feedback appears in the same thread where the team is discussing the deploy or the incident. We reached the same conclusion building [My Senior Dev](https://myseniordev.com): the review agent's move into Slack ([Act 2](/posts/review-agent-three-acts/)) generated more engagement than any UI polish on the web dashboard.
 
 [Devin](https://devin.ai) is probably the strongest existing example of this pattern. Its Slack bot can review PRs, write fixes, and execute multi-step engineering tasks directly from a thread. It's been around long enough to prove that Slack-native is a durable product shape, not just a demo. Devin ships 7 native integrations (GitHub, GitLab, Bitbucket for git; Slack and Microsoft Teams for communication; Linear and Jira for task management) plus a marketplace of 76 MCP tools for extending its reach. Where CodeRabbit differentiates is observability context: native connections to Datadog, Sentry, PagerDuty, PostHog, and cloud infrastructure give it cross-system reasoning about incidents and deploys that a code-focused agent doesn't attempt. Where Devin differentiates is execution depth, going from conversation to committed code in the same thread.
 
@@ -59,7 +59,7 @@ CodeRabbit's Triggers feature partially closes this gap, but only for events tha
 
 This is a common pattern across the industry. [Devin](https://devin.ai) goes furthest with Slack-native execution, writing and committing code from threads, but it still responds when mentioned rather than when something changes in the repo. [Cursor's BugBot](https://cursor.com/blog/bugbot-autofix) triggers on PR creation but doesn't monitor for state changes after that. [Claude Code's auto-fix](https://code.claude.com/docs/en/claude-code-on-the-web#auto-fix-pull-requests) catches CI failures but not review comments that arrive hours later. The shape is consistent: respond to the initial event, poll for everything after.
 
-The [three-primitives framework](/posts/three-primitives) maps this clearly. CodeRabbit's automations give it a solid clock, with scheduled runs that execute reliably on cadence. The Triggers feature adds a listener for Slack-native events. The inbox works well, delivering results to channels and threads with clear attribution. The gap is in listener coverage: it hears what happens in Slack, but GitHub and Jira remain on the other side of a polling interval. For those systems, the agent depends on either Slack forwarding (a Datadog alert posting to a channel) or scheduled polling (the thirty-minute merge conflict check).
+The [three-primitives framework](/posts/three-primitives/) maps this clearly. CodeRabbit's automations give it a solid clock, with scheduled runs that execute reliably on cadence. The Triggers feature adds a listener for Slack-native events. The inbox works well, delivering results to channels and threads with clear attribution. The gap is in listener coverage: it hears what happens in Slack, but GitHub and Jira remain on the other side of a polling interval. For those systems, the agent depends on either Slack forwarding (a Datadog alert posting to a channel) or scheduled polling (the thirty-minute merge conflict check).
 
 <Callout tone="thought" label="Proactivity tracks coverage">
 A listener that covers one surface creates an asymmetry. The agent responds instantly to a Datadog alert because Datadog posts to Slack. It can't respond instantly to a GitHub push event unless something else relays that event into Slack first. The proactivity extends as far as the Slack integration does.
@@ -73,7 +73,7 @@ CodeRabbit is further along than most tools in this space. The multi-system cont
 
 The blog title "Now the Agent Moves First" describes where they're heading more than where they are today. For Slack-native events, the agent does move first. For everything outside of Slack, it still checks on a schedule.
 
-We hit the same boundary building My Senior Dev. The shift from scheduled checks to [continuous event detection](/posts/why-proactive-is-hard) required rearchitecting around normalized change events rather than periodic queries. It was the hardest part of the transition from [Act 2 to Act 3](/posts/review-agent-three-acts). Given how quickly CodeRabbit ships, they'll probably get there faster than we did.
+We hit the same boundary building My Senior Dev. The shift from scheduled checks to [continuous event detection](/posts/why-proactive-is-hard/) required rearchitecting around normalized change events rather than periodic queries. It was the hardest part of the transition from [Act 2 to Act 3](/posts/review-agent-three-acts/). Given how quickly CodeRabbit ships, they'll probably get there faster than we did.
 
 <Callout tone="cool" label="Worth using today">
 The thirty-minute version still delivers real value. Those 11 merge conflicts it surfaced? I wouldn't have found them on my own. And the automation took about ninety seconds to set up, faster than writing the cron job myself.

content/posts/building-weekly-digest.mdx

@@ -9,7 +9,7 @@ dropcap: true
 
 The weekly-digest agent is a Cloudflare Pages Function wired to cron (`0 9 * * 6`, Saturday mornings). It fans out across four sources looking for mentions of "proactive agents," deduplicates what it finds against previous results, clusters the survivors by topic using an LLM, and upserts a single GitHub issue labeled `weekly-digest`. A run takes about twelve seconds.
 
-I wanted to write about it because every other post on this site is kind of theoretical. We talk about [the three primitives](/posts/three-primitives), about [the webhook tax](/posts/the-webhook-tax), about what a [magical agent would do](/posts/magical-agents) if it existed. The weekly-digest agent is the one we actually built and tested. It has a git history with embarrassing commits and a log line that reads: "Found 30 new mention(s) across 4 sources, deduped, clustered into 4 topic(s)."
+I wanted to write about it because every other post on this site is kind of theoretical. We talk about [the three primitives](/posts/three-primitives/), about [the webhook tax](/posts/the-webhook-tax/), about what a [magical agent would do](/posts/magical-agents/) if it existed. The weekly-digest agent is the one we actually built and tested. It has a git history with embarrassing commits and a log line that reads: "Found 30 new mention(s) across 4 sources, deduped, clustered into 4 topic(s)."
 
 So here are the receipts.
 
@@ -104,7 +104,7 @@ The delivery channel shapes behavior more than the content does. A digest in Sla
 The restraint is deliberate. The agent files a curated summary somewhere durable and searchable, and goes quiet. I've found that the best production agents are honestly pretty boring to watch. That's the whole point.
 
 <Callout tone="cool" label="The delivery primitive matters">
-This maps directly back to the [three primitives](/posts/three-primitives). The clock is cron. The listener is Brave + Reddit. The inbox is GitHub Issues. Choosing GitHub over Slack changed the agent's behavior more than any prompt tuning did, because it changed how humans interacted with the output.
+This maps directly back to the [three primitives](/posts/three-primitives/). The clock is cron. The listener is Brave + Reddit. The inbox is GitHub Issues. Choosing GitHub over Slack changed the agent's behavior more than any prompt tuning did, because it changed how humans interacted with the output.
 </Callout>
 
 ## Costs
@@ -136,7 +136,7 @@ Three things, in order of likelihood we'll actually do them.
 
 **Source expansion.** Hacker News is an obvious addition. So is Twitter/X, though the API pricing makes it impractical on a free-tier budget. We could add a Brave `site:news.ycombinator.com` query for close to zero cost. The gather step's fan-out design makes adding sources trivial to implement, which was the whole point of that architecture.
 
-**Data-triggered runs.** Right now the agent is purely cron-driven. If a mention spikes on a Wednesday, we don't know until Saturday. For some sources, a data trigger would make more sense: watch an RSS feed or a webhook and fire the pipeline when something appears, not when the clock ticks. This is the M2 roadmap for us, replacing some cron triggers with real-time [listener](/posts/three-primitives) events. The weekly cadence would remain as the default for sources that don't support push.
+**Data-triggered runs.** Right now the agent is purely cron-driven. If a mention spikes on a Wednesday, we don't know until Saturday. For some sources, a data trigger would make more sense: watch an RSS feed or a webhook and fire the pipeline when something appears, not when the clock ticks. This is the M2 roadmap for us, replacing some cron triggers with real-time [listener](/posts/three-primitives/) events. The weekly cadence would remain as the default for sources that don't support push.
 
 <Callout tone="thought" label="The production test">
 If you want to know whether your agent architecture holds up, build something that runs unattended for a month. Not a demo. Not a benchmark. Something with a cron expression and a git history. The bugs you find will be different from the ones you expected, and the design decisions that matter will surprise you.