Hey @wooden-umbrella-84098 do we have someone currently working on "recommended automations" in agent canvas? I know you had a prototype. I have thoughts about concrete implementation and could possibly vibe something later today or over the weekend if nobody is on it already (cc also @hundreds-twilight-32833 and @elegant-branch-54423) My basic idea: 1. Find an appropriate OSS MCP/API marketplace and either use or modify their data into a format that we can use. 2. Create several "recommended automations" that have (a) a prompt to the agent about what the automation should do, (b) an example implementation of the automation, possibly with holes/unfinished design decisions, (c) a list of required MCPs for the automation, linked to "1". 3. Create a UI that displays "1" on the MCP page (in popularity order), similar to the MCP marketplace we previously had. Clicking on an automation will open a UI to add an MCP. 4. Create a UI that displays "2" on the automations page (in popularity order), similar to your prototype. Clicking on this will lead you through a process of (a) adding all required MCPs, re-using the interface from "3", (b) launching a conversation with the agent according to the prompt in "2". The reason why I'd prefer this design is that "1" and "3" allow people to use MCPs without automations, but "2" and "4" can re-use all components of MCPs so that the additional lift is low. (OFC if someone is working on this already I'm happy to let other people do it!)

cc @fierce-account-55183 is working on parts of this

I created this issue and Paul is working on a design. These are some of the possible automations we pulled from that could work with cron for one-click ish creation:

Code Quality
- QA
- Vulnerability Discovery
- Architecture Review
- Pen testing

Optimization
- CPU/Memory tuning
- Log cleanup

Maintenance
- Dependency updates
- Test cov expansion
- Test optimization

Reporting
- Repo change summary
- Summarize open issues
- Standup automator

Cool, thanks @hundreds-twilight-32833! One thing that's missing from that issue is how to interface between MCPs and automations, which is what I was discussing above

Yes definitely is. I don't have a clear line from Integrations/MCP -> Automations right now in the MVP scope. I do think it needs to be there.

Cool, happy to prototype something today or tomorrow, but I also don't want to duplicate work if @fierce-account-55183 is already on it

I am working on this now

OK, cool!

@fierce-account-55183 did you see this thread? https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1778790383598359

I believe Tim means to dump a reference polling script into an agent skill?

Yes

when you say polling, do you mean retrieval? The automation cron should be managing the time behavior

Again yes - it will use the cron

I guess retreival and state tracking

Exactly

ok perfect, thanks!

Sometimes we use the same words to mean completely different things, and sometimes we use different words to mean the same things - I'll err on the side of being too verbose to hopefully reduce confusion

Why do we encode

GitHubTrigger

? I imagined we would just have a CRON automation running python code for polling

Yeah, I'm a little confused why we need to write any new code for the automations repo? I thought we'd just be calling a registered MCP or directly to the github API to get the info from github

Here is my rationale... • We could call the MCP endpoints instead of REST endpoints saving on having to store keys - but we still need to configure which repositories / channels we are interested in, and how filtering should be done. The REST endpoints are mature and well known - but we may switch this over later • If we run this as Rohit describes (Invoking the tarball), then we need to run it inside a sandbox (Unless I'm mistaken?) This will mean either creating a new conversation as we poll (Likely every minute), or reusing an existing one. The current method reduces this friction - the automation produces a worthy event which results in a conversation only when it's needed.

> If we run this as Rohit describes (Invoking the tarball), then we need to run it inside a sandbox (Unless I'm mistaken?) Local automations don't run inside a sandbox, and a conversation is only created when the following sdk code is executed. For polling CRON there will be no such conversation created, just raw python execution

with RemoteWorkspace(...):
    conversation = Conversation(
        agent=agent,
        ...
    )

What about non local?

Same applies for non local (for conversation creation) but by default the automation runs inside a sandbox But we won't be polling in cloud, we'll be using webhooks so it shouldn't be an issue I think

It feels odd to me to dispatch events from the automation service in cases where no action is required.

It feels odd to me to dispatch events from the automation service in cases where no action is required.

This seems OK, although def a bit hacky. I'm imagining the polling service sending events to the automation BE, and automation BE will see if the trigger conditions for any automations are met

invoke MCP commands directly

I was thinking this. It can even be REST APIs assuming the mcp has the API key

In which case, the tarball would still need some kind of http call

Not following this part, the tarball can contain arbitrary code which can make http requests. Are we talking about http request to fetch mcp credentials or execute mcp calls?

I'm out right now and unfortunately can't join the huddle, but my main request is that it soon (not necessarily now) be possible to add a new automation and integration with no code changes to the agent canvas and automation repo. We're going to scale this to many integrations and automations eventually and code changes every time don't scale. My design above easily allows this. But I'm open to any design that has that property as well

@quick-window-91705 @fierce-account-55183 I'm just catching up here. Could you please note in thread any decisions/changes/etc that came out of your huddle for how we're handling the integrations?

No changes (So far) - We just walked through the various automation options. I think it was a case of this...

@limited-student-10747 Tim is working on (how an automation runs) • The skill for the agent to create a CRON that polls events using saved MCP credentials and kickoff automations based on incoming events • This covers step 4b (launching the agent conversation with the right prompt) It seems these parts can still be worked on in parallel if you'd like (what automations exist and how users discover/configure them) • Step 1: Source the MCP/API marketplace data • Step 2: Build the recommended automations catalog (prompt, example implementation, required MCPs list per automation) • Step 3: MCP page UI — show recommended automations in popularity order, click → add MCP flow • Step 4a: Automations page UI — show recommended automations in popularity order, click → walk through adding required MCPs (reusing the UI from step 3), then hand off to Person 1's execution layer to launch the conversation

Cloud • Scripts are run in sandbox (So one is required, and if it is deleted a new one must be created) • Events will be received in the automation service via an outgoing websocket connection Local • Scripts are run in same env as Automations server locally • Events are received by querying the service (via REST or MCP) My approach: • Agent creates an automation script with required action • Agent invokes endpoint which creates automation with script, cron, repos/channels, and filter expression • This results in: ◦ Automations server queries github using cron ◦ Automations server does event filtering ◦ Automations server invokes script when condition is satisfied (An appropriate event was encountered) Everybody else's approach: • Agent creates automation script - this script includes checking github, event filtering, and whatever action was required • Agent invokes endpoint which creates automation with script and cron. • This results in: ◦ Automation server invokes script ◦ Script queries github, does any filtering, and then whatever else it needs to Notes • I was worried about us having to keep sandboxes alive in cloud due to the filtering being done inside the script - but as Rohit pointed out we will be using integrations hub in cloud so the script generated will need to be different - we will have a completely different skill configuration in cloud than local. • I was worried about continuously running the scripts every minute if somebody has a lot of automations, but I guess if you have a lot of automations, use our cloud service!

Was there a decision on Tim approach vs other approach? 😄 . Or are you gonna POC a bit and then check back in?

I am gonna go with the other approach

Thanks for the recaps and huddling to hash it out!

Thanks both for the summary! I can take a look at some of the stuff that's not on Tim's plate now.

I've cleaned up a number of surrounding issues: • agent-canvas/pull/501 • agent-canvas/pull/502 • agent-canvas/pull/503 (Needs review) 503 should mean that we can actually create automations in the agent canvas locally

I'm working on these draft PRs but still testing and polishing: • Add recommended automations and MCP marketplace setup flow by neubig · Pull Request #504 · OpenHands/agent-canvas • Add MCP and automation catalogs by neubig · Pull Request #237 · OpenHands/extensions

I had one too! (I have no idea if it works) https://github.com/OpenHands/extensions/pull/238 I'll try yours in the morning

This PR on MCP+extension onboarding is getting there, although I'd say it's not ready yet. If people have feedback on the general design/architecture I'd be happy to have it though: Add recommended automations and MCP marketplace setup flow by neubig · Pull Request #504 · OpenHands/agent-canvas There's an animated GIF of what the interface looks like for quick review (although the text is currently blurred out in a few places, i'm having the agent re-create the gif now). also, the design can certainly be improved a bit.

What stuff?

It was frontend stuff, probably not related to the stuff you're working on. I think this is basically ready Add recommended automations and MCP marketplace setup flow by neubig · Pull Request #504 · OpenHands/agent-canvas

@limited-student-10747 I will review the agent-canvas pull request. Thank you very much! thankyou

Thanks for the review @millions-afternoon-47582 , addressed the two small comments: Add recommended automations and MCP marketplace setup flow by neubig · Pull Request #504 · OpenHands/agent-canvas

Hello @limited-student-10747, While testing the pull request locally, I came across a few issues and have shared the details within the pull request. Thank you very much! thankyou

Thanks a lot, I’ll check and verify that those issues are resolved!

@limited-student-10747, I have approved the pull requests and left a few suggestions and questions for your consideration. Thank you very much! thankyou