Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Personal Agent #3

Open
0x4007 opened this issue Mar 26, 2024 · 0 comments
Open

Personal Agent #3

0x4007 opened this issue Mar 26, 2024 · 0 comments

Comments

@0x4007
Copy link
Contributor

0x4007 commented Mar 26, 2024

This one I'm very excited about. The vision here is that we can make custom user "agents" (i.e. plugins with LLMs) that are hosted by the user's GitHub (so they can modify it) and will automate actions for the user (with their PAT to authorize as them) with the full context of a particular repository/organization.

  • We make a repository that power users are intended to fork, for example @ubiquibot/personal-agent -> @pavlovcik/personal-agent
  • A repository/organization configures personal agents command to be /@<user's name> /@pavlovcik maybe something like that. This should also support arguments, for example a sentence that can be parsed by an LLM /@pavlovcik review my pull #123
    • This technically would allow other users to invoke other user's agents. We can easily see if the invoker is an "authorized" user by checking the event context, and hard coding authorized users (self) in the boilerplate plugin code.
    • I wonder if it would be more useful if we just look for comments that start with a username tag instead, it might be more natural to set up automations for common questions/requests i.e. @pavlovcik can i work on this issue? then my agent, with my PAT, and my custom prompt saying what to do in this situation, would just automatically assign them and explain the /start command.
  • The kernel will invoke a request (and pass all parameters) to that user's plugin/agent (hosted at @username/personal-agent actions)
  • The user can grant access to their PAT from their agent, allowing the agent to act on behalf of the owner inheriting their permissions.

There are some ways we can make the template code which will be forked:

  1. simple starting point would be just template/boilerplate that doesn't do anything
  2. code makes a call to an LLM (we could even run a small model locally on the GitHub Action runner potentially in order to make dealing with credentials/API keys more hands off, at the tradeoff of it being dumber than ChatGPT etc but decentralization/free is cool)
    1. this LLM has a big prompt in the template that explains the context (you're running in a github action runner and a user invoked you from this repo...) and its capabilities (we can provide some local functions from our SDK that it can invoke to perform specific tasks by using an authenticated octokit instance using the person's PAT. It also receives all of the context of the event invocation (which user called the function, what repository and organization is it coming in from? possibly even scraping all the linked issues and pull requests for more context)
      2. If we can reliably get the LLM to write working code with Octokit (or just raw CURLs with the PAT) then we can have a context aware and english language input to any function a user can perform on GitHub (limited to the PAT permissions) which is quite interesting.
      3. The user can "fine-tune" their LLM by adding extra details and preferences to their prompt in their forked code. I imagine that I would continue to add new sections as I see repetitive questions/queries.

Assuming that the org config enables support for personal agents, technically we can extend personal agent capabilities beyond GitHub. Generic telegram example: @pavlovcik send me the credentials on Telegram @username with the right code in my personal agent, the GitHub Action can send information to their Telegram. All invoked from the GitHub Action runner!

This could make plugin development a lot more exciting and rapid. If the team all works on their own agents, and tests them in production, we could extract useful bits from eachothers' and release "official" plugins which may normally have slower r&d cycles.

In the further future, our kernel can support webhooks coming in from other services (like Telegram) and invoke user agents which can be a very powerful architecture for platform composability. For example, a bot call (can be "inline" in a dm to someone as well) that will pass along the conversation context to our kernel, then to a user's personal agent (github action) back to kernel and then back to Telegram

Notes for @pavlovcik/personal-agent

  • I want to make use of the XP system (as an admin) to soft incentivize/disincentivize behaviors.
    • Prompt follow ups: there are situations where I tag team members for input and they take days to reply. I think if they take longer than 24 hours to reply, I would want to dock XP, and include an automated follow up (perhaps even on Telegram dm!) High performing team members generally reply promptly. XP can be used as a heartbeat for how actively engaged the contributor is, and how well they are performing, which is important for performance evaluations regarding base pay.
    • On the other end of the spectrum: unnecessary tags1. If I make it clear to team members that I am around to help but more for emergencies, I would appreciate not being pinged on things unless its essential. Would be interesting to make a personal agent that will automatically reply (like an away message) explaining this, while also scrubbing out the tag from their message. Assuming it is during my awake/working hours, I would still receive a push notification on my device from the original tag.

Comment rewrites:

From my phone sometimes writing comments can be arduous with the custom vocabulary we use and the autocorrect. A simple agent that will save me from a lot of frustration is to edit my comments posted, and correct any typos when I post from my phone.

Footnotes

  1. Although it is not clear to me how we can capture the event from this. I suppose I would need to manually add in the org/repo config for issue_comment.created.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant