Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Ductwork – A Go platform for running AI agents on autopilot (github.com/dneil5648)
5 points by dneil8675 13 hours ago | hide | past | favorite | 5 comments
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

 help



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?


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.

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!


Glad those are on the radar. One thing that might help with prioritization: checkpoint granularity matters a lot in practice. Saving state at major tool call boundaries rather than just at conversation turns tends to give much better recovery points without bloating storage. Learned that the hard way watching agents redo 20 minutes of work after a single API timeout. The unified dashboard will be huge once you get there.

Great to hear! Good luck with the project. Wish you well!



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: