Ponko

This project started out as a personal investigation into several agent orchestration architectures to see how they’re put together and how to stretch them. It evolved into an attempt to run some day-to-day tasks as cheap as possible.

https://github.com/bryanneva/ponko

How I use it

I have it set up in a private Slack instance and have it registered as @otto. I have a general channel for arbitrary requests, but several dedicated channels for different interaction patterns.

• #job-hunt: keeps track of stateful instances of job applications and recruiter interactions. I capture raw meeting notes with voice-to-text software like granola.ai, then I dump the generated notes into this channel. @otto takes over by parsing the notes, updating the data, noting the interaction, and keeping my application progress up-to-date. Otto researches the company for me and handles some background work
• #lab-bench: this is a side project i’m working on. @otto’s hooked into a database full of project docs, a project-management db, and github. I can dump raw info, and otto synthesizes the ideas, creates issues, and tells me what’s ready

Runtime

The agent runs on Fly.io as a Go app on postgres. It’s hooked into slack as a custom bot, that I have named @otto. It has a backing memory layer, which is a vector database on supabase. I’ve been adding a ton of extra tables and edge nodes for arbitrary data as I find useful. The MCP is hooked into claude and chatgpt.

What is it

It’s a go app. I have it hardcoded on claude as the llm layer. Agent interactions are orchestrated with river and it has a “conversation” model to keep track of more complicated requests. Its tool access into my memory layer allows it to send and get work, including doing arbitrary compute and dispatching messages proactively.

What’s next

I’m pulling out the core orchestration into an open source package (ponko). I’m next working on a runtime to have it execute longer running tasks on persistent machines.