BTY, I monitor this thread via moadim.io, I have a routine that ping this page every 10 minutes and ping me on discord for every message that I didn’t responded to yet
How do I know this won't just eat through my token budget? It's hard to understand from the website how "done" is derived in the loop. If it's not deterministic then it seems like it would be prone to over-engineering.
Great question but the goal is not to handle tokens economy management, this is cupeled to the agent, I want to stay agent agnostic, you tell the agent what you want it to run in the routine, for example i have a routine that split a codebase to max 50 lines a file, I told it in the routine, when finish the refactor, change the routine to run every week and check for regression and if there is take it back to run every 30 minutes and work file after file.
I don’t think this is where it’s should land, I believe that is not the “single responsibility” of this project but I would love to hear more, because it’s seems like a pain point for several people, what is your suggestion?
Looks like a userland cron/launchd, with jobs committed in a local repo. It’s designed to launch agent clis, for which it provisions a workspace and manages process state, and to be used by agents (and so provisions an api and mcp for each task).
Might seem silly (no disrespect meant), but I have this use case; I’ve tried to give agents access to launchd, but it has not gone well. Nothing has b0rked my system, but it has been annoying to version control plist files with my project repositories. And so i find this interesting, having written a shell script to convert repo config file + plist to safe launchd commands - and much shittier version of this thing.
You got it just right, but the idea is that the user don’t need to care about the configuration of the cron in the lower level and the agent spawning and the worktree setup etc… the daemon does it for us.
I think the actual loop engineering lives in skills and workflows. The trigger is the creation of a ticket, manual or programmatic; e.g., through an incident.
Your perspective here is of a software engineer only, and I gets it, for software engineering you got a great point and I somewhat agree with it.
When we talk about how to work with agent the holy grail is agent’s pro-activity, one of the columns of pro activity is webhooks as you said “the creation of a ticket”, I don’t want to attack this vector, I what to be laser focus on the scheduling vector as I said in another comment here.
Regarding skill and workflows, I don’t want to make you couple your way of work to the routine, if you want to load the the workflows and skills feel free, in the end of the day the routine is only a scheduled prompt.
Would love to hear more about your way of working with event driven actions
BTY, I monitor this thread via moadim.io, I have a routine that ping this page every 10 minutes and ping me on discord for every message that I didn’t responded to yet
How do I know this won't just eat through my token budget? It's hard to understand from the website how "done" is derived in the loop. If it's not deterministic then it seems like it would be prone to over-engineering.
Great question but the goal is not to handle tokens economy management, this is cupeled to the agent, I want to stay agent agnostic, you tell the agent what you want it to run in the routine, for example i have a routine that split a codebase to max 50 lines a file, I told it in the routine, when finish the refactor, change the routine to run every week and check for regression and if there is take it back to run every 30 minutes and work file after file.
Would this be where llm/agentic observability come into play?
I don’t think this is where it’s should land, I believe that is not the “single responsibility” of this project but I would love to hear more, because it’s seems like a pain point for several people, what is your suggestion?
Concretely and Simply, what are you actually building with this?
Looks like a userland cron/launchd, with jobs committed in a local repo. It’s designed to launch agent clis, for which it provisions a workspace and manages process state, and to be used by agents (and so provisions an api and mcp for each task).
Might seem silly (no disrespect meant), but I have this use case; I’ve tried to give agents access to launchd, but it has not gone well. Nothing has b0rked my system, but it has been annoying to version control plist files with my project repositories. And so i find this interesting, having written a shell script to convert repo config file + plist to safe launchd commands - and much shittier version of this thing.
You got it just right, but the idea is that the user don’t need to care about the configuration of the cron in the lower level and the agent spawning and the worktree setup etc… the daemon does it for us.
I would love to hear your feedback and features suggestions, feel free to contact me in LinkedIn https://www.linkedin.com/in/ofek-gabay/
TLDR: a way to manage my agents routines in a single source of trust in a repository.
Everything should be open source and agent agnostic
I think the actual loop engineering lives in skills and workflows. The trigger is the creation of a ticket, manual or programmatic; e.g., through an incident.
Your perspective here is of a software engineer only, and I gets it, for software engineering you got a great point and I somewhat agree with it. When we talk about how to work with agent the holy grail is agent’s pro-activity, one of the columns of pro activity is webhooks as you said “the creation of a ticket”, I don’t want to attack this vector, I what to be laser focus on the scheduling vector as I said in another comment here.
Regarding skill and workflows, I don’t want to make you couple your way of work to the routine, if you want to load the the workflows and skills feel free, in the end of the day the routine is only a scheduled prompt.
Would love to hear more about your way of working with event driven actions