70% of LangChain's Agent Runs Are Scheduled. Count the Ones Somebody Read.

LangChain made the proactive agent a product line this week, and the number it reports is the share of runs nobody typed. This is a field note on the number that sits next to it, from a fleet where a third of the agents were never read.

The short version

Nathan Drezner's October 28 post on the Schedules SDK in Managed Deep Agents says most proactive agents run as scheduled cron tasks, a mechanism more than fifty years old, and that more than 70% of Managed Deep Agent runs on LangSmith come from a schedule rather than a person. Sydney Runkle's "The Art of Loop Engineering," in the feed the next day, makes the event-driven loop level three of four. Nate B Jones's October 27 overview says every individual update seems reasonable and together they become a job. In December 2024 I wrote not to oversell a cron job as an agent; the vendors now say it themselves, and the question moved. When I audited my 39 appointed agents, 13 were orphans running clean output that nothing outside the fleet read, and 13 had drifted to the same 7 to 9 a.m. window on their own; the fleet is 44 and 15 still sit there. Drezner's server jitters runs to spread load, and what clusters at 8 a.m. is the reader. Runkle's four human touchpoints put a person before the action and before the output ships, and never name who opens it. The number to publish next to 70% scheduled is the share of scheduled runs with a reader, and the check is what downstream consumed the output.

What LangChain shipped

Drezner's post is honest about the mechanism, which is why I like it. After you learn about proactive agents you see them everywhere, Muse, Instinct, Dots, Claude Duet, Hone, and most of them are scheduled cron tasks. An operating system principle more than fifty years old, pointed at a new job.

Then the number. More than 70% of Managed Deep Agent runs on LangSmith come from scheduled runs, not from a human typing a message.

Five things a cron unlocks, in his list. Memory consolidation, a background job about once a day. Proactiveness, the agent starting conversations about things it thinks you care about, which arrive as proactive messages. Smart triage, about every ten minutes, watching Slack or email and notifying you of anything of note. Follow-ups. Orchestration, an agent sleeping while subagents work and waking itself to check.

Two building blocks. A robust cron server, which jitters runs that cluster at the same time so the load spreads. And an agent-friendly interface, tools that let the agent set a schedule, list them, delete one.

Runkle's post stacks it. Loop one, the agent calling tools until done. Loop two, a grader. Loop three, event-driven: cron, webhooks, heartbeats, a Slack channel that fires the agent. Loop four, an agent that reads the traces and rewrites the harness. The post says the focus should move from loops one and two to three and four. And it names four human touchpoints, one per loop: approval before a sensitive tool call, human grading, output approval before it reaches end users, human review of harness changes.

Jones's post is paid past its overview, so I'll cite only what's public. Five points. Close the thread that keeps pinging you. Make decisions without reconstructing them. Stop hearing "nothing changed." Know your recurring work actually ended. Cut the work that keeps multiplying. And the line above them: every individual update seems reasonable, together they become a job.

Three posts in one week. The proactive agent is a cron with a prompt, and the vendors are saying so out loud.

The question moved

In December 2024 I wrote Your "AI Agent" Is Probably Just a Cron Job, and the point was not to oversell a schedule as an agent because the word sounds better in the deck. That argument is over. LangChain's own post opens with the schedule and sells it as the feature. Fine. It was always the useful tier.

So the question is no longer whether it's an agent. The question is what 70% counts.

It counts runs nobody typed. Which is an input metric. It tells you the agents are busy. It tells you nothing about whether a person was on the other end.

What the fleet counted

I have the other number, from the failure side. 39 PM AI Agents Deployed: What Stuck, What Died, and Why is the April audit of every appointed agent I'd built, each with a stage in the operating model, a schedule, a standing job. Rung three by construction. None of them waits for a question.

Thirteen of 39 were orphans. Zero references from anything outside the fleet: no page, no ritual, no other agent consumed their output. Several had run for over a month, reliably, producing clean output that nothing read. In Drezner's terms, those were scheduled runs, every one of them, the kind of run a 70% counts.

Thirteen of 39 fired between 7 and 9 a.m. Nobody designed that. Every agent I'd built with some version of "tell me the most important thing from yesterday" drifted to the hour a PM wants the answer. Each decision was right alone. The result was thirteen briefs arriving together. 44 Appointed Agents, One Attention Budget has the recount: the fleet is 44 today and 15 still name a 7, 8, or 9 a.m. time. Six months on, the slot still chooses itself.

Put those two counts next to the posts.

Drezner's cron server jitters runs that cluster at the same time. That spreads the server's load. The thing that clusters at 8 a.m. in a fleet of briefing agents is the reader, one person, and no cron server can jitter that. The jitter is on the wrong side of the run.

Runkle's four touchpoints put a person before the sensitive call and a person before the output reaches end users. Both good. Neither is the person who opens the output on day thirty, and that was the line that was blank on all thirteen of my orphans. They had an owner who'd have fixed them if they broke. They never broke. They had nobody who read them.

Jones's "reading their updates is a new job" is the same problem from the chair on the other side. He's the reader with fifteen things at 8 a.m. I was the builder who didn't know he'd made fifteen things for 8 a.m. until he counted.

The number to publish next to 70%

The share of scheduled runs with a reader.

Not a notification target. Drezner's agents already notify. Not output approval. Runkle's event loop already has that. A named person who opens the result, per agent, per schedule, and the count of schedules where that name is blank.

The check isn't the agent's log, and this is the part I'd push hardest. A log says it ran. For each scheduled agent, count what outside the fleet consumed its output: a page that embeds it, a ritual that reads it, another agent that takes it as input, a decision that cites it. In my audit the three agents with three or more references were the ones the broader system had decided were load-bearing. The thirteen with zero had been voted off by silence. The heartbeat says it ran. Only something downstream says it mattered.

The Reach Line put a signature on every new tool an agent gets. This is the same discipline on the other end of the run: a name on every schedule, and a count of the blanks.

Under Enterprise AI Agents the claim is that agent count is a vanity metric and what matters is how many still complete production work after ninety days. Scheduled-run share is the same vanity metric with a timer on it. The agents that made ninety days in my fleet were the ones somebody opened.

This week: list every scheduled run your team has, in LangChain, in Claude Duet, in whatever cron-driven assistant somebody set up in March. Next to each, write the name of the person who opens it. Count the blanks. That count, over the total, is the number to put next to the vendor's 70%.

Related answer: How many of your scheduled agent runs have a reader?

Sources: Nathan Drezner, "How to Build Proactive, Always-On Agents with the Schedules SDK in Managed Deep Agents," LangChain blog, October 28, 2026, read in full. Sydney Runkle, "The Art of Loop Engineering," LangChain blog, page dated June 16, 2026 and carried by the feed on October 29, 2026, read in full. Nate B Jones, "You delegated the work to agents and ended up with a new job: reading their updates," Nate's Substack, October 27, 2026, public overview only; the guide behind the paywall is not claimed. Falk Gottlob, "39 PM AI Agents Deployed: What Stuck, What Died, and Why," "44 Appointed Agents, One Attention Budget: Three Lines on the Charter" (October 14, 2026), "Your "AI Agent" Is Probably Just a Cron Job" (December 31, 2024), and "MIT, LangChain, and Google Put Agent Risk on Reach This Week. Add the Name." (October 26, 2026).