Show HN: Ductwork – A Go platform for running AI agents on autopilot

[dneil8675]

I've been running Claude agents for various automation tasks — monitoring crypto news, syncing Todoist, running health checks — and I kept hitting the same problem: there's no clean way to deploy an agent that just runs on a schedule without a human babysitting it.

Every agent framework I looked at was built around chat interfaces or one-shot workflows. I wanted something closer to cron for AI agents — define a task, give it a schedule, let it run forever. So I built Ductwork.

You define tasks as simple JSON files — a prompt, a schedule, optional memory and skills — and ductwork handles scheduling, execution, retries, and history. The agents have bash, file read/write, and that's it. No fancy abstractions.

The thing that makes it actually useful for unattended operation:

Persistent memory — agents write to a memory directory between runs. My Bitcoin news monitor remembers which articles it's already reported on. Next run, it only flags new ones.

Security boundaries — if you're letting agents run unsupervised, you need guardrails. Per-task tool whitelists, path restrictions, bash command filters. A monitoring task can't accidentally rm -rf something.

Run history and observability — every run is tracked with status, duration, token usage, and errors. REST API for everything so you can integrate with whatever alerting you already use.

It scales from a single process (ductwork start) to distributed — same binary with --mode=control runs a task queue, --mode=worker on other machines polls for work. No new dependencies, just HTTP.

Single Go binary, go install and you're running. ~3,500 lines, only deps are the Anthropic SDK and Cobra.

This is definitely not a finished product — it's early and there's a lot I want to add. But it's functional and I'd love for people to download it, play around with it, and let me know what they think. Feedback, ideas, issues — all welcome.

https://github.com/dneil5648/ductwork

[jlongo78]

Interesting approach. One thing worth considering with autopilot agents: session persistence and context recovery become critical when agents run long tasks and hit failures mid-stream. The ability to resume exactly where a conversation left off, rather than restarting from scratch, saves significant time and cost. Also worth thinking about multi-agent observability in a single view - context switching between isolated agent outputs is a real friction point teams underestimate until they're running several concurrent tasks.

[dneil8675]

Those are great points, both session persistence and multi-agent observability are on the roadmap.

Checkpointing conversation state + sandbox filesystem mid-run so agents can resume on failure will be key for operating at scale. And a unified dashboard across all running agents is the goal once the core scheduling and execution layer is solid.

I appreciate the feedback!

[john_minsk]

So let's say I run this with a lot of tasks.

- How many tasks/schedules have you tested? - What if some schedule has to run another schedule on demand. Can I clearly see it in a management view? - If you and me are running this. Can my task contact your task and be stay alive while another user finishes his task?

[dneil8675]

Only have tested around 4-5 tasks at the same time (since I don't want to end up with a large anthropic bill on this MVP just yet).

Management view isn't there yet — still focused on getting the core execution and scheduling solid before layering in observability.

For the agent communication - at the moment there is no connectivity between two spawned agents, unless one agent spawns the other. The system is task based with the task being the separation boundary, where agents can spawn agents if required by the task. For this what kind of use cases are you imagining ?

Also please feel free to pull it down and tinker with it! This is an MVP and more people playing and updating it will make it that much better!