- 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.
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.
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!