My guess is the agent that sets up the Automation is getting confused -- and instead the system is kicking off a new conversation every 5 mins rather than executing the script and efficiently determining if a conversation is needed to run (thus being more efficient with LLM tokens) In the 🧵 , i propose a diagram that we could follow to be more efficient/reliable, without relying on the agent to create the script for us.

I think this is a good plan. I had a quick wireframe mocked up to help me visualize what a small slice could look like that lets a user run a script or run a prompt on a schedule. Seeing or sketching it out helps me so maybe this helps others visualize it as well:

Are all keywords necessary? If they’re all optional, the agent would trigger for “I want to review this later!” I understand it’s a draft, the reason why I’m mulling on details is that I feel we have a simple solution: “@agent”. That's it. When I call the agent, of course I expect that will go to the agent?

User configured. We could give a recommendation but up to users to keep it specific

It could work that way, it’s tricky for me to make my point here because I don’t disagree with it. I do think we’re trying maybe a little too much to fit everything in “configurable automations”. 🤔 What I am trying to argue for, is a “golden path” if I may put it this way. (1) “Access your agent from wherever you are” • “Your agent can be with you in Slack” ◦ small package or automation that is fully implemented, user just enters minimal values • “Your agent can be with you on GitHub” ◦ small package or automation that is fully implemented, user just enters minimal values (2) Automations (custom automations) • the wireframe Notes: • the first can be implemented as the second, it seems; but why does it have to? it’s not totally trivial, and as of now, the predefined versions get it clearly wrong • more importantly, the first feels differently to the user, I would argue. We just say: “tell your agent to activate _*the* Slack resolver_” ◦ or whatever we’d name it if we do it, “your Slack connector”, “the Slack entry point” • the user can configure Automations, and can create a custom Slack resolver -like of their own. I don’t know… Why would we want to offer only one feature (from user perspective or docs on it), automations feature, and not two features: • remote access to your agent = “Slack/GH resolver” = “Slack/GH connector” • automations = create custom scheduled or event-driven automations

I like that framing a lot actually

Sorry, by ‘pre-built’ here, do you mean… pre-built? 😅 As in, the agent does NOT create it during the wizard, instead we make it and place it in the repo, and the pr-review workflow always uses it?

Looked into the terminology across projects: - Hermes calls each messaging service a "platform" (Telegram, Discord, Slack, API Server), and the central routing process the "gateway." Implementations live in

gateway/platforms/

. - OpenClaw calls them "channels" instead of platforms, but same concept. Also calls the central layer "gateway." Channels are plugins registered via

api.registerChannel(...)

-- can be bundled or third-party extensions. - SmolPaws calls them "ingress apps" (

apps/whatsapp

,

apps/slack

,

apps/github

), each a thin adapter that dispatches to the local agent-server. No shared "gateway" layer yet -- each ingress talks to the agent-server directly. So "gateway" is consistent between Hermes and OpenClaw. The individual entry points are "platforms" (Hermes), "channels" (OpenClaw), or "ingress apps" (SmolPaws). Notably, Hermes has an OpenAI-compatible API server as one of its platform adapters -- so the agent itself is exposed as a

/v1/chat/completions

endpoint. Any OpenAI-compatible client (Open WebUI, ElevenLabs voice, etc.) can talk to the agent through it. OpenClaw doesn't have this yet. We just proposed it for the OpenHands agent-server: https://github.com/OpenHands/software-agent-sdk/issues/3540