Backstory
We recently had a hackathon at work where we were told to build something using the product we’ve been working on behind the scenes. I loved it because it had been a while since I built a workflow using our system, and the parameters were simple: it had to use AI, and it had to be long-running to emphasize the resilience of AutoKitteh.
Use Case
When I build something, I want it to be useful. At first, I had a bunch of ideas but had a hard time thinking of a workflow that I actually needed. And then it hit me.
Recently, I was going through an open PR and noticed that I was tagged in a comment in our GitHub repo. My manager was requesting an update on a PR that had been open for quite some time. I probably received an email notification, but I didn’t see that either—likely because my email inbox is a mess, but that’s a topic for another blog post.
I found my idea! I wanted to be reminded of messages in PRs where I was tagged but hadn’t responded within 24 hours. This included both issue comments and inline comments. This would be useful and would save me from having to monitor my inbox—or feeling awkward about “ignoring” messages. I immediately thought of enhancements, but given the limited time for the hackathon, I decided to keep it simple.
What Does It Mean to Respond?
The first hurdle was realizing I had to define what it meant for a message to be “responded to.” If this was a workflow I wanted to work for most people, this would be a more difficult task. But since I was building a workflow for myself, I only had to define it based on the way I work.
Here’s the condition a message needs to meet to be considered “not responded to”:
- It has been more than 24 hours.
- For inline comments: I haven’t made a later comment in the same thread. For issue comments: I haven’t quoted the original review comment or mentioned its author in a response.
- I have not added an emoji to the original review comment. (Side note: My manager pointed out that this is a very millennial approach. ¯\\_(ツ)_/¯ What can I say?).
For those interested, here’s what that logic looked like in code:
def has_been_responded_to(
target_comment, potential_responses, is_inline, github_user_id):
# Skip if comment is less than 24 hours old.
now = datetime.datetime.now(datetime.UTC)
if now - target_comment.created_at < datetime.timedelta(hours=24):
return True
# Check for emoji reactions.
for reaction in target_comment.get_reactions():
if reaction.user.login == github_user_id:
return True
# Check for comment responses.
for response in potential_responses:
if (
response.created_at > target_comment.created_at
and response.user.login == github_user_id):
if is_inline:
return True
# For issue comments, check for @ mentions or quotes.
if has_mention_or_quote(response, target_comment):
return True
return FalseWhy AI?
Okay, I’ll be honest—this workflow doesn’t *really* need AI. But that was one of the hackathon parameters, so I had to follow the rules!
I integrated AI by making it into a chatbot. It became the messaging interface that converted plain English into commands. Could I have used Slack commands instead? Totally. But not only would that have broken the rules, I also can’t tell Slack commands: “Hey, check if there are any messages that need responding to!” There’s just something satisfying about that level of automation that’s worth the extra lines of code.
The full prompt used can be found here.
Why AutoKitteh?
I’ve used other automation platforms, and building something with such custom requirements would be painful. If it was even possible, I would have to do it in an unfamiliar environment, dragging and dropping components when I would much rather be writing code.
Because AutoKitteh is built on top of Temporal and automatically converts workflow code into activities, a long-running chatbot is, by default, resilient. In other words, if the server crashes, upon restart, the workflow continues from where it left off. (Assuming, of course, that the crash wasn’t caused by the workflow itself—but that’s what testing is for.)
Here’s the code snippet responsible for the AI chatbot:
def on_activate(_):
"""Entrypoint for the AI chatbot assistant."""
while True:
print("Waiting for a message...")
subs = autokitteh.subscribe("slack_conn", "event_type == 'message'")
data = autokitteh.next_event(subs)
if data:
on_slack_message(data)Once the workflow is activated, it loops until the session is killed. In the meantime, it waits for a Slack message to process.
Integrations Used in the Workflow
- GitHub integration: For the ability to scan a repo.
- Google Sheets: Used to keep track of messages that need to be responded to.
- OpenAI’s ChatGPT: The chatbot interface.
- Slack: Used for communicating with the chatbot and getting notifications.
All of these were already installed, so all I had to do was initialize a connection.
Future Improvements
I have a similar problem with Linear that I do with GitHub, so I’d like to extend the functionality to scan Linear messages. (Plus, we already have the integration!)
I’d also like to fine-tune the ChatGPT prompt to make it less strict and more conversational. This might sound a bit silly, but I thought it’d be fun to let users set the AI’s tone—like, “I’m in a sad mood today, make your messages extra uplifting.” Part of that would involve adding context for the AI, since right now, it only processes one message at a time and has no memory of previous interactions.
Another improvement would be integrating Google Calendar, so I could tell the chatbot: “Schedule a time for me to respond,” or “Find my next available slot and remind me.”
Finally, I’d love to track PRs, since sometimes I’m waiting for a PR to merge but I’m not great at checking emails. A Slack notification would be way more useful.
You can check out the entire project.
