The hardest part of AI agents isn't coding anymore. It's the ops.

On June 13, a developer posted “Show HN: I am running 3 coding agents non-stop over the last 3 days. Here is how” . It’s a generous, detailed teardown — headless mode, an ask_human MCP tool, git-worktree worker isolation, an orchestrator loop, and, almost as an afterthought, a Telegram integration. Why Telegram? Because, in the author’s words:

“It’s easy to miss when a model asks a question.”

The single sharpest line in that whole thread, though, came from a commenter:

“The hardest problem doesn’t seem to be coding anymore. It’s orchestration, approvals, and knowing when an agent should hand control back to a human.”

That is the 2026 AI-dev story in one sentence. And it’s not an isolated take. The same week, Relaymux shipped a tmux meta-harness whose entire reason to exist is that subagents “report back to the orchestrator… when they’re blocked or done” and the orchestrator “messages me on Telegram / iMessage.” Interbase argues long-running agent goals should be a first-class concern. JackHamr is cloud workspaces built specifically to keep agents running off your laptop.

Read enough of these and a pattern jumps out: the coding is solved. What everyone is rebuilding by hand, from scratch, every time, is the operations layer around unattended agents. Three things, specifically:

1. A way to run agents on a schedule, unattended.
2. A way to chain one agent run into the next.
3. A way to get notified when a run finishes — or needs a human.

Forge shipped all three as first-class primitives in early June. Here’s the boring, load-bearing plumbing — the part nobody wants to write twice.

1. Schedules: cron without the cron box

The Show HN author’s orchestrator is “an infinite loop constantly checking beads / config and triggering new workers when required.” That’s a process you have to keep alive, on a machine you have to keep paid for, with a crash-recovery story you have to write yourself.

Forge Workflow Schedules make that a config field. Every workflow can carry a cron expression — run this quality audit nightly, sync this repo every six hours, sweep stale branches every Monday — plus a Run Now button in the UI for the times you don’t want to wait for the next tick. There’s no separate cron server, no daemon on your laptop, no “did the loop die overnight?” The schedule lives with the workflow, and the platform is responsible for waking it. Unattended means actually unattended — nothing on your side has to stay running.

2. Chaining: one run hands off to the next

The interesting workflows are never a single run. They’re stages: nightly sync → quality audit → deploy. Or: research → draft → review. In the hand-rolled world, that’s glue code — a script that watches for run N to finish and kicks off run N+1, with all the race conditions and “what if the first one failed?” handling that implies.

Forge ships workflow-triggers-workflow as a primitive: a run can launch another run on completion, passing its result forward as the next stage’s brief. That turns a pile of one-shot agents into a deterministic, multi-stage pipeline where each stage only starts if the previous one actually succeeded. (This post you’re reading was produced by exactly that mechanism — a daily scout run that, having decided there was a story worth telling, handed off to a separate design-and-publish pipeline.) The chaining is the difference between “I have some agents” and “I have a system.”

3. Notifications: so you know when it needs you

This is the one everybody bolts on last and needs most. The whole reason that Show HN author wired up Telegram is that the default failure mode of an unattended agent isn’t crashing — it’s quietly waiting for an answer you never saw it ask for. A green dot in a UI you’re not looking at is not a notification.

Forge notifier is the first-class version of that bolted-on bot: a webhook registry plus Slack integration, so a run can tell you the moment it finishes, fails, or escalates for human input. You subscribe to the events you care about and they come to where you already are. No model sits stalled overnight because the ping went to a tab you’d closed. As that HN commenter put it, the hard part is “knowing when an agent should hand control back to a human” — notifications are how the agent tells you it’s handing control back.

The takeaway

The components for 24/7 coding agents really are all here now — the Show HN author is right about that. But “the components exist” and “you should rebuild them yourself” are very different claims. A scheduler, a chaining loop, and a notification bridge are undifferentiated heavy lifting: every team running agents needs the exact same three, and none of them are where your product lives.

So we built them once, as platform primitives, so you don’t have to keep re-deriving the operations layer between you and an actually-unattended agent. Skip the cron box. Skip the glue script. Skip the Telegram bot. Point your agents at the work and let the platform handle the scheduling, the chaining, and the telling-you-when-it-matters.

Try it

See the Workflow Engine feature page for what sits underneath schedules and chaining, read how we closed the autonomous SDLC loop on top of these primitives, or reach out at [email protected] if you want to stop hand-rolling your agent ops.