I've heard a good bit of feedback from user interv...
# proj-agent-canvas
h
I've heard a good bit of feedback from user interviews that the Automate/Automations part of Agent Canvas isn't quite resonating with the SDLC use case folks are looking for. With that in mind I wanted to get some feedback on some potential updates to how that view differentiates between types of automations: Workflows, Routines, Responders. • Workflows: When something happens, run these steps. Ex -> New bug issue in Github/Linear/Jira/Gitlab then research the issue, add results to the ticket, label for human in the loop or ready for agent PR. • Routines: On this cadence, produce this recurring artifacts. Ex ->Scheduled scans, digests, readiness checks, recurring reports. • Responders: Stay available in this channel or mention surface. Ex -> Always on chat-like connections for slack/discord/chat bots, channel monitors, This is all possible as-is with Automations but the UI isn't quite communicating or helping users figure it out. A Create Automation UI could further support the workflow/routine/responder types where needed. I'll also make a shaping issue but dropping here for any quick feedback if anyone has any.
^ Automate shaping when you get a bit to take a look @elegant-branch-54423 @breezy-kilobyte-39430
I just realized the mockup put slack channel monitor inside a routine instead of responder. Hope that isn't too confusing for anyone looking closely 😬
e
This is really cool! A few questions: • Is it possible for a user to miscategorize an automation? Similar to your point above. Could we make it so they can re-categorize it later? • Can we organize Templates around SDLC stage - something like: Analyze, Plan, Build, Test, Deploy, Operate • For 'Polling' automations where the Automation checks for state every X minutes and then decides to start a convo or not -- would that show up as a workflow, routine, or responder? I guess it could depend on the scenario
w
This makes sense to me!
h
I think they would need a way to be manually recategorized for cases where they get put in the wrong bucket. If we have a UI then the type would be clear from the type selection. I imagine a UI where the Type is a tab and it helps navigate the options available based on the needs. Not sure about specifics for SDLC stage. Maybe an SDLC Dashboard view could help so you can monitor your SDLC and group automations as part of them. Something like a bug triage workflow could an entire analyze->plan->build->test flow. It might be better if each step was a different automation with labels for triage through code execution but not required. Hopefully we'll get some feedback here 😄 Agree on polling being scenario specific. I was hoping that putting Responders in a specific section would help expose them and differentiate.
w
"Routines" sounds more like "Reporters"
Reporters -> agents push information to humans Responders -> humans push work to agents Workers -> systems push work to agents
👍 1
h
Oh interesting framing....
m
I believe also that making the UI as friendly as possible is a big win. If i remember correctly, in the interviews surfaced that a lot of people which are not super AI friendly/informed use agent-canvas
nod 1
h
Reporters -> agents push information to humans
Responders -> humans push work to agents
Workers -> systems push work to agents
This makes me think more of the agent behavior than the automation. But maybe that makes sense...if I'm going to create an automation I can trust the "reporter" because it has a perceived guard of not modifying anything. Same with "Responder", it just responds...which isn't actually true for our slack integration. It can report, respond, and do work. Those could be a behavior settings on an automation that put in actual guard rails to the agent activity?
w
> Those could be a behavior settings on an automation that put in actual guard rails 🤔 not sure how easy that'd be to enforce but it would be cool!
c
if I'm going to create an automation I can trust the "reporter" because it has a perceived guard of not modifying anything. Same with "Responder", it just responds...which isn't actually true for our slack integration. It can report, respond, and do work.
This sounds like an interesting view! I think of the Responder as definitely doing work; it’s an agent, it can do whatever necessary, without me needing to babysit it, and then comes back with a response…
Re: this definition is very interesting. Why wouldn’t we just say “the agent will respond to you from all the places” ?
In other words, this makes the agent accessible for you wherever you are. Is there a reason to not put it this way?
h
I like that wording!
b
I think it's looking great directionally. with our other updates I think we'll have a great ui revamp for the section.