Personal Agent

[0x4007]

Task

• This will be registered under issues_comment.created
• This will look for username tags at the beginning of any comment, and relay everything to their self hosted plugin.
• The rest of the magic happens within their own self hosted plugin so this should be a super simple plugin to build.

Config

The host repository name. For example:

plugins:
  - uses:
    - plugin: ubiquity-os-marketplace/ubiquity-os-agent
      with:
        target: ubiquity-os-agent

Then comments starting with @0x4007 will relay the full issues_comment.created payload to 0x4007/ubiquity-os-agent

Context

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 tags¹. 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.

Planned Capabilities

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.

Review and follow up:

Sometimes a pull request will be 99% of the way there. It will be something like "just make sure CI passes" or "fix merge conflicts"

Ideally the personal agent should monitor pulls that I approved and are still opened. If I said something like this, and if those conditions are met, it should merge the pull.

• Example: feat: schema validation plugin-template#23 (comment)

Similar ²

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. ↩

2. 2025 Plugins Wishlist 84% ↩

[0x4007]

@gentlementlegen how would this look from a plugin config standpoint? Perhaps we make a special adapter? For example, we attach an issues_comment.created plugin that will route the request to one's "personal agent"?

[gentlementlegen]

If you do like other plugins and hook it to the issue_comment.created you will already get the full payload for that event, how would this differ?

[0x4007]

I take that as a yes. Then we can make the only config option to be the host repository name. For example:

   - with:
       name: ubiquity-os-agent

Then it will relay the payload to 0x4007/ubiquity-os-agent

[gentlementlegen]

As long as you have the bot installed in your organization, you can hook any plugin from your organization you want to see running so

plugins:
  - uses: 0x4007/ubiquity-os-agent

would run your agent.

[0x4007]

This issue seems to be similar to the following issue(s):

• 2025 Plugins Wishlist Similarity: 82.52
• Collaborator Gating Based On Label Similarity: 78.27
• Near Instant GitHub Actions Cold Boot Times Similarity: 76.98
• Do not break the loop when a plugin fails to run Similarity: 75.84

@sshivaditya2019 this is becoming recursive so I don't think its working correctly. It just keeps stacking more every time I create a new issue.

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

sshivaditya2019

77% Match ubiquity-os-marketplace/generate-vector-embeddings#25