Transcription: OpenAgents Episode 125 - The Master Plan

Source: https://x.com/OpenAgentsInc/status/1834087017132511419 Wiki source: https://raw.githubusercontent.com/wiki/OpenAgentsInc/openagents/Video-Series.md Media title: OpenAgents - Episode 125: The Master Plan We detail our master plan: 1. Build th... Upload date: 20240912 Transcription model: gpt-4o-mini-transcribe Generated at: 2026-06-01T16:44:29Z

Machine-generated transcript. Review speaker labels and wording before using this as quote-grade source material.

[00:00] Speaker: So here's the plan. Step one, we build the best agents. Easy, we're pretty much there. Two, we sell the agents, and we pay you a cut proportional to how you help. Maybe you'll be incentivized to help us build better agents, sell them more, you get larger of a cut. And then we're gonna repeat one and two until world conquest. Is this clear? Hopefully this is clear. Okay, let's dig in a little bit. So the idea is that we are building agents out of graphs. This is not a unique concept. However, I haven't seen any projects combine two types of graphs, both knowledge graphs and execution graphs. So you've got like LangChain has a LangGraph thing. There's a bunch of like people building agents out of graphs representing execution steps as nodes and edges. Okay, fine. Makes sense. Here's an example of an execution graph. We're using this flow in our current auto dev, long-lived coding agents flow. If a user sends a message, is the user mentioning or referencing a GitHub repo? If so, have we indexed the repo? If not, build the index. If yes, just go and query the index for context and then pass that to the LLM. That's one example of an execution graph where you're using this flow in our current auto dev, long-lived coding agents flow. If a user sends a message, is the user mentioning or referencing a GitHub repo? If so, have we indexed the repo? If not, build the index. If yes, just go and query the index for context and then pass that to the LLM. That's one example of an execution graph. It's like one particular set of routes that can govern the agent. If you've used our V2 open agents, you can see how powerful it is to just have like one agent with access to 12 different tools. We've gotten a lot of like really good feedback from people who've played with this enough to like get it. Like, holy shit, this actually works to help me code really freaking fast because this has direct access to your code base and can, you know, make intelligent changes. But there's no reason that any agent should have access to only 12 tools or that you, the user, need to be like manually selecting. There's a lot of like automation that can be added here because ideally the user doesn't need to choose any of this stuff. They're just like talking to the interface and they're getting results back. So that's an example execution graph. And then example knowledge graph would be, here's just us kind of playing around with graphing files in a code repo along with the connections between them, like the imports, definitions, blah, blah, blah. Here's that applied to a PDF with too much granularity. All those like are nodes around the circle. And the idea behind connecting all of the knowledge of a code base is to enable the sort of rag process where you're feeding context about your code base to the model. If you've used Cursor or any of these other tools, Aider, where you have to like manually specify the files, like that's even like, why are you needing to manually specify the files? All that knowledge is in the repo. It's just not organized or the connections that are there are not like being properly surfaced. And so just taking this idea from the Microsoft LOL research group, GraphRAG, GraphRAG, they kind of do this over PDFs and like text documents. It's basically combining graphs with retrieval augmented generation. I haven't seen anyone apply this to code bases. We are doing that. If you check back two or so videos in this series, we've got a kind of an introductory walkthrough to code base indexing via GraphRAG. We just did like a very basic kind of chatting with our V2 proof of concept. And we are almost ready to show off a demo of like using that, seeing that in our little new little dashboard that we're building here. We've got like 236 passing tests for this portal app. Where have we got that? Anyways, so let's talk briefly about our code bases. So we have a new monorepo that is open source. We've open sourced our current app at OpenAgents.com, by the way, that's on in V2 there. And then in this code base, we're gonna be open sourcing under Creative Commons, both the new mobile app forthcoming as well as the Relay, which is a custom NOST relay and NIP90 service provider. We'll go soon into more details in other videos about why that's important. So those are both open source. And then we've got a private client app that we are starting to sign businesses up to. And, you know, I didn't wanna go the business route right off the bat because I really wanna build the consumer platform. But the problem is that we need to identify paid usage because we have to pay the bills. So it's like, it's hard to reason about solving problems that people only value at $10 a month. And like, if we do this right and we can like literally create coding agents for people, that should be something that people are willing to pay thousands of dollars a month for because you're talking about replacing or dramatically augmenting existing development teams. So we'll be gradually opening up access to this hopefully over the next month. In the meantime, if you are a developer or looking to hire developers, if you run a company, yeah, you're gonna want that. So part of the idea here is we wanna be able to represent graphs in a decentralized and open way so that anyone can contribute to them. And we're gonna be using NOSTR for that. And then for the payments, we're going to be using the Bitcoin Lightning Network, which is the obvious payments network for machine to machine payments. And we'll be using either L402, which is the kind of HTTP402 protocol from Lightning Labs has fleshed a lot of this out. And we'll maybe doing some combination of that with this new NOSTR specification NIP69. That's kind of like a drop-in replacement for LNURL, more NOSTR native and doesn't rely on DNS something, something. So check out that video. So the idea there is that instead of all these different companies building like singular agents that do one thing, like where is the open agent substrate where you can take advantage of all of the agents that other people have built? And if someone has built the best RAG algorithm, the best code base indexer, the best whatever it is, and you can like kind of pull in that set of execution and or knowledge graphs, and then you just, you know, some of the payments from your agent just like stream to whoever contributed that, that enables a true marketplace of the sort of building blocks for agents. So to borrow a line from TinyGrad, who's commoditizing the petaflop, I kind of came up with commoditizing the pull request, but really it's more than that because we're not just doing coding agents. We're really commoditizing the building blocks of agents. So I think that that graph structure is gonna be crucial for that. And then what this enables is, you know, once we have a lot of these agents and we have like data flowing through this, you know, you've got people like Mark Zuckerberg and others saying how in order to get to the next wave of truly useful compound AI systems or agents, we're gonna need really good data flows or data sets. Like we're gonna have all sorts of amazing data sets generated through these agents that can train the next generations of agents. And because we're like building this streaming money into our platform, like we're already set up to compensate people, you find people, proportional to how you contribute. So if you contribute some algorithm that other people use, you'll get paid. If you generate data that people wanna use, you get paid. If you're just good at shitposting and like you drive some sales on Twitter, you get a stream of permanent fucking referral income on the backend. So to come back to the beginning here, how are we building the best agents? Because we're gonna be building on and with and for open source. And then we're gonna be paying people to contribute to our massive fucking open agents swarm. See you soon.