WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=jVjt-2g8NMY NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/jVjt-2g8NMY.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:04.680 --> 00:00:07.800 Imagine you find a magic lamp in an antique store. s2 00:00:07.800 --> 00:00:12.640 You rub it, a genie appears, and asks how it can help. s3 00:00:12.640 --> 00:00:18.520 You burn it in the outline, so you say, "I need the best engineer to help with an impossible project at work." s4 00:00:18.520 --> 00:00:20.560 And the genie grants your wish. s5 00:00:20.560 --> 00:00:25.360 For me, the best engineer is probably John Carmack from his eight days, so you get Carmack. s6 00:00:25.360 --> 00:00:31.200 But the genie had a sense of humor and imposes restrictions, maybe for safety. s7 00:00:31.200 --> 00:00:36.160 Carmack can only see one small part of your code base, maybe 1/1000 of it. s8 00:00:36.160 --> 00:00:38.520 And he remembers nothing he did before. s9 00:00:38.520 --> 00:00:41.360 Every conversation starts fresh. s10 00:00:41.360 --> 00:00:42.480 So, that would be maddening, right? s11 00:00:42.480 --> 00:00:46.520 You would know there is a standard way to do stuff, and Carmack wouldn't. s12 00:00:46.520 --> 00:00:50.880 You would have to explain the same thing over and over and over again. s13 00:00:50.880 --> 00:00:55.520 You would have a genius on one side and something deeply deficient on the other. s14 00:00:55.520 --> 00:00:57.440 And that's what agents are. s15 00:00:57.440 --> 00:01:03.880 Let me walk you through an example of how many times we re-explain things in a simple interaction. s16 00:01:03.880 --> 00:01:09.120 We have four repos, UI, module one, module two, and platform. s17 00:01:09.120 --> 00:01:12.760 I want to change the UI and propagate the change through the system. s18 00:01:12.760 --> 00:01:13.440 Okay? s19 00:01:13.440 --> 00:01:14.800 First, we change the UI library. s20 00:01:14.800 --> 00:01:17.640 Say we, I don't know, change a button or whatever. s21 00:01:17.640 --> 00:01:19.680 That's the first explanation, unavoidable. s22 00:01:19.680 --> 00:01:22.160 We have to express the intent, okay? s23 00:01:22.160 --> 00:01:22.960 Then we publish it. s24 00:01:22.960 --> 00:01:30.360 We go to module one, and we have to re-explain what just has happened in the UI library, so it can consume the package here. s25 00:01:30.360 --> 00:01:32.560 Note that that's often a different person, right? s26 00:01:32.560 --> 00:01:37.800 Every box in this diagram can be done by a different person. s27 00:01:37.800 --> 00:01:43.080 And then we discover that the published UI library doesn't work with module one. s28 00:01:43.080 --> 00:01:51.040 So, we go back to UI, and we have to re-explain the original change and the issue. s29 00:01:51.040 --> 00:01:51.200 Right? s30 00:01:51.200 --> 00:01:54.760 Because it's a new agent, it doesn't know the original change. s31 00:01:54.760 --> 00:01:57.160 It obviously doesn't know about the issue. s32 00:01:57.160 --> 00:01:59.320 Let's say we fix it, right? s33 00:01:59.320 --> 00:02:01.680 And uh publish it again. s34 00:02:01.680 --> 00:02:07.200 We go and again we explain the new change in the context of module one, same module. s35 00:02:07.200 --> 00:02:10.240 I mean, do the same for module two again. s36 00:02:10.240 --> 00:02:17.560 And then we go to the platform repo and we explain everything fits together and we implement the change there. s37 00:02:17.560 --> 00:02:23.480 Let's imagine a week after release, a bug appears in the UI component and we have to fix it. s38 00:02:23.480 --> 00:02:26.120 So we start an agent in the UI repo. s39 00:02:26.120 --> 00:02:32.480 And we have to explain again the original change from a week ago and this production issue we're seeing. s40 00:02:32.480 --> 00:02:37.520 So we have seven explanations for what essentially is one change. s41 00:02:37.520 --> 00:02:43.520 And also it may not be one person making all these seven explanations, but they still occurred, right? s42 00:02:43.520 --> 00:02:46.920 So that's very very typical with agents. s43 00:02:46.920 --> 00:02:49.640 So how do we solve it? s44 00:02:50.640 --> 00:02:58.040 Well, there are many problems in here that contribute to this experience, but they roughly fall into two categories. s45 00:02:58.040 --> 00:03:03.680 The first one is that an agent essentially is repo bound. s46 00:03:03.680 --> 00:03:08.680 Agent sees and changes generally one repo at a time. s47 00:03:08.680 --> 00:03:14.120 It never sees the whole system, which can be hundreds or thousands of repos. s48 00:03:14.120 --> 00:03:18.000 So that's kind of the space component of the problem. s49 00:03:18.000 --> 00:03:19.959 Second is amnesia. s50 00:03:19.959 --> 00:03:21.800 Agent forget the work. s51 00:03:21.800 --> 00:03:24.160 Every session start with a blank slate. s52 00:03:24.160 --> 00:03:26.120 The human becomes the memory in this case. s53 00:03:26.120 --> 00:03:28.239 That's the time component of the problem. s54 00:03:28.239 --> 00:03:29.880 Look at the two closer. s55 00:03:29.880 --> 00:03:32.320 Take the repo boundary first. s56 00:03:32.320 --> 00:03:38.160 Without a model how repos fit together, the agent leans on the human to do the research. s57 00:03:38.160 --> 00:03:40.840 It can't align the code with the rest of the system. s58 00:03:40.840 --> 00:03:43.560 It couldn't align the UI change with module one. s59 00:03:43.560 --> 00:03:48.040 The human didn't explain it, so a bad version shipped. s60 00:03:48.040 --> 00:03:55.120 It can't reliably reference best practices and standards either because those often live in other repos. s61 00:03:55.120 --> 00:04:01.520 Worse than even worse, the agent writes to one repo at a time, it means it can't validate changes downstream. s62 00:04:01.520 --> 00:04:05.880 Modules one CI should have failed on the UI change, but it didn't. s63 00:04:05.880 --> 00:04:12.920 The agent can't update consumers at the same time even though, you know, while making the UI change, it has perfect information to do so. s64 00:04:12.920 --> 00:04:14.959 It knows exactly what it's doing. s65 00:04:14.959 --> 00:04:20.160 So, the user has to re-explain stuff imperfectly to each consumer. s66 00:04:20.480 --> 00:04:24.200 Changing something across 20 repos means re-explaining things 20 times. s67 00:04:24.200 --> 00:04:28.480 A lot of developer time spent, but also a lot of tokens burned. s68 00:04:28.600 --> 00:04:32.640 The second category is that the agent forgets. s69 00:04:32.640 --> 00:04:35.440 The agent has no episodic memory. s70 00:04:35.440 --> 00:04:38.040 Every session is a blank slate. s71 00:04:38.040 --> 00:04:41.840 And the human, in this case, becomes the memory. s72 00:04:42.360 --> 00:04:46.840 Here's what the graph of your work actually looks like. s73 00:04:46.840 --> 00:04:49.520 At the bottom, there is a repository graph. s74 00:04:49.520 --> 00:04:55.600 The artifacts your organization produces plus every open source repo you depend on. s75 00:04:55.600 --> 00:05:00.520 Maybe a thousand repos you own and tens of thousands of open source repos. s76 00:05:00.520 --> 00:05:05.840 At the top, there are all agentic sessions that create and modify that code. s77 00:05:05.840 --> 00:05:09.520 Sessions relate to each other, repos relate to each other. s78 00:05:09.520 --> 00:05:14.720 So, this graph is a faithful picture of the work in your organization. s79 00:05:14.720 --> 00:05:20.480 It describes what's there at the bottom and how it came to be at the top. s80 00:05:20.480 --> 00:05:24.360 That's what you want your agent to see. s81 00:05:24.400 --> 00:05:26.640 Here's what it actually sees. s82 00:05:26.640 --> 00:05:33.800 There is one session, one small fraction of the code base, no memory, okay? s83 00:05:33.800 --> 00:05:41.080 Because it sees so little, it leans on the one who understands the system, the developer. s84 00:05:41.080 --> 00:05:44.240 Every developer has a part of that graph, right? s85 00:05:44.240 --> 00:05:47.360 In their hand, at least in the domain they know. s86 00:05:47.360 --> 00:05:50.480 Agent generically speaking doesn't. s87 00:05:50.480 --> 00:05:52.240 If this doesn't sound crazy, right? s88 00:05:52.240 --> 00:05:59.120 Imagine an agent that could see one file at a time maximum and can only look five messages back. s89 00:05:59.120 --> 00:06:05.080 Sort of constraint again both in space, what can see, and time, how far in the past it could see. s90 00:06:05.080 --> 00:06:08.280 You would say that's impossible to work in. s91 00:06:08.280 --> 00:06:12.600 What we have now is similar to that crazy picture. s92 00:06:12.600 --> 00:06:18.320 And the more complex the organization is, the more apparent it becomes. s93 00:06:18.320 --> 00:06:21.280 I'll show you how we solved it. s94 00:06:21.280 --> 00:06:31.200 Other organizations I talked to have similar solutions, so uh look at the problem and the solution conceptually, not the specific tool, although the tool is pretty cool. s95 00:06:32.440 --> 00:06:39.120 We built an agent agnostic meta harness called Polygraph. s96 00:06:39.120 --> 00:06:44.360 Okay, let me show you what it does and how it fixes the issues we just discussed. s97 00:06:44.360 --> 00:06:58.280 The first idea that we uh arrived at is that if a GitHub user, any user, has access to thousands of repos, some of them they own, many of them are open source, s98 00:06:58.280 --> 00:07:07.320 we can analyze them and extract a lot of metadata out of them to build unified dependency graph. s99 00:07:07.320 --> 00:07:12.320 Uh no line of code changes in those repos, that all happens kind of on a side, right? s100 00:07:12.320 --> 00:07:24.320 And then we can get this metadata and feed it to the meta harness and create an illusion of one big code base the agent can read and write anywhere. s101 00:07:24.320 --> 00:07:26.960 This is my personal graph. s102 00:07:26.960 --> 00:07:30.000 I want to have about 300 repos I own, right? s103 00:07:30.000 --> 00:07:33.600 And thousands of open source repos my projects depend on. s104 00:07:33.600 --> 00:07:44.320 Polygraph computes what each one produces, each repo, each project in each repo, what each project in each repo consumes package-wise, what API they produce and consume, and lots of other stuff, right? s105 00:07:44.320 --> 00:07:53.520 And this stitches this together uh into this like one big body of code that your agent can work with. s106 00:07:53.720 --> 00:07:56.680 So, let's see what it does, right? s107 00:07:56.680 --> 00:08:05.040 The first thing it it does is uh it lets you start a session to bring the relevant repositories in, right? s108 00:08:05.040 --> 00:08:18.640 So, what it needs to do, it needs to uh set up the source code, install dependencies, set up an agent for each repo, wire them up so they can work together, s109 00:08:18.640 --> 00:08:25.800 and provide a clean, beautiful GUI to make non-trivial changes without getting lost. s110 00:08:25.800 --> 00:08:28.280 I will show you how it all works in a second, right? s111 00:08:28.280 --> 00:08:31.480 So, that's kind of pull information in. s112 00:08:31.480 --> 00:08:34.800 Pulling information in is only one part of the story, all right? s113 00:08:34.800 --> 00:08:36.280 Honestly, it's an easy part. s114 00:08:36.280 --> 00:08:38.760 Making changes is harder. s115 00:08:38.760 --> 00:08:45.120 If you have 10 repos in one session, it means you can have 10 pull requests, all right? s116 00:08:45.120 --> 00:08:47.120 You need to run CI. s117 00:08:47.120 --> 00:08:50.839 You need to coordinate all of it, right? s118 00:08:51.200 --> 00:08:53.640 You need to do all this stuff, all right? s119 00:08:53.640 --> 00:08:55.720 What if one of them fails, right? s120 00:08:55.720 --> 00:09:00.280 Polygraph treats all the CI as one vector. s121 00:09:00.280 --> 00:09:13.400 Like if you look at the earlier example, uh when we run CI for UI module one and module two, if module one fails within a polygraph session, it will figure out who fixes it, whether module one needed a patch s122 00:09:13.400 --> 00:09:20.520 or the UI component itself is broken and incompatible with module one, at which point everyone will need a patch, right? s123 00:09:20.520 --> 00:09:27.720 Polygraph lets you treat complex multi-repo change as if it was a single repo change. s124 00:09:27.839 --> 00:09:32.320 The same machinery, by the way, fixes episodic memory. s125 00:09:32.320 --> 00:09:38.840 Because we capture your work, no matter how many repos are involved, we We your intent, the repository is involved, PRs. s126 00:09:38.840 --> 00:09:41.160 We also capture all agent traces. s127 00:09:41.160 --> 00:09:43.600 Because we capture all of this stuff, we can relate it. s128 00:09:43.600 --> 00:09:49.800 So, now we can say your work in one repo connects to another work in another repo. s129 00:09:49.800 --> 00:09:50.440 Right? s130 00:09:50.440 --> 00:09:58.120 And all of that lets us restore any session, any piece of work on any machine, or reference it from anywhere. s131 00:09:58.120 --> 00:10:01.720 And I will show you again how it works in a second. s132 00:10:01.720 --> 00:10:09.760 What you get is an agent with eidetic or photographic memory of your entire organization. s133 00:10:09.760 --> 00:10:19.920 It understands how repos are written, how they relate, how they put together, and remembers every session from every repo by basically every developer. s134 00:10:19.920 --> 00:10:20.680 Right? s135 00:10:20.680 --> 00:10:24.840 And that creates a completely different development experience. s136 00:10:24.840 --> 00:10:26.680 Let me show you. s137 00:10:26.680 --> 00:10:30.600 First, let's look at how we create a session, something simple. s138 00:10:30.600 --> 00:10:36.520 You run a command, and you pick some repositories from a list. s139 00:10:36.520 --> 00:10:40.200 Here's a tiny GitHub work with only three repos because it's a demo. s140 00:10:40.200 --> 00:10:43.280 I pick back end and a front end. s141 00:10:43.280 --> 00:10:51.400 Let's say I need to make a change that, you know, changes the API and has to update both the API and how stuff is being displayed. s142 00:10:51.640 --> 00:10:54.560 I need to give my session a name. s143 00:10:54.560 --> 00:10:57.800 I need to pick an agent from the ones I have installed. s144 00:10:57.800 --> 00:10:59.280 I picked Claude. s145 00:10:59.280 --> 00:11:01.360 But any installed agent works same way. s146 00:11:01.360 --> 00:11:04.280 Remember, Polygraph isn't an agent. s147 00:11:04.280 --> 00:11:10.120 It's a meta harness around an agent that makes them uh more capable. s148 00:11:10.720 --> 00:11:17.720 And in a second, uh the agent boots. s149 00:11:17.720 --> 00:11:24.280 And here I could interact with it as if I was in a single repo, even though multiple repos are involved, right? s150 00:11:24.280 --> 00:11:26.760 I could give it instructions. s151 00:11:28.560 --> 00:11:32.480 It's going to uh plan out the change. s152 00:11:33.880 --> 00:11:37.520 There is some cool animations in the UI as well. s153 00:11:38.840 --> 00:11:40.203 Eventually, s154 00:11:40.203 --> 00:11:41.200 [snorts] s155 00:11:41.200 --> 00:11:45.160 it figures out how the two repos relate and what the change is. s156 00:11:45.160 --> 00:11:47.440 I can ask it to implement the change. s157 00:11:47.440 --> 00:11:53.720 My interaction with this uh exactly same as if it I was working in a single repo. s158 00:11:53.720 --> 00:11:57.200 The fact that there are multiple repos involved is not really important, right? s159 00:11:57.200 --> 00:12:02.840 Uh the only uh part where it becomes important that I have multiple pull requests, right? s160 00:12:02.840 --> 00:12:06.400 Uh but I also get a polygraph session where those pull requests are. s161 00:12:06.400 --> 00:12:07.040 All right? s162 00:12:07.040 --> 00:12:19.240 If I look at the session, I will see I have a description uh that uh description of the session describes the work conceptually uh kind of bypassing the repo boundary, saying we have to change stuff in this repo, change stuff in that repo. s163 00:12:19.240 --> 00:12:25.480 It gives me a good view of which repos are involved, pull requests involved, CI in those repos, everything I need to know. s164 00:12:25.480 --> 00:12:30.240 A lot of this stuff is basically what I would have in a single repo but many, right? s165 00:12:30.240 --> 00:12:36.800 And I also have all the agent logs captured as well, which is important for resuming, which I'm going to show you in a second. s166 00:12:36.800 --> 00:12:38.760 Now it gets interesting. s167 00:12:38.760 --> 00:12:41.440 I already saved one re-explanation. s168 00:12:41.440 --> 00:12:46.040 I didn't re-explain the back end change uh in the in the front end repo, right? s169 00:12:46.040 --> 00:12:50.680 I explained the change once and I got it implemented in both repos and it's all in agreement. s170 00:12:50.680 --> 00:12:52.480 Now let's resume a session. s171 00:12:52.480 --> 00:12:54.680 Say I want a coworker to finish the back end change. s172 00:12:54.680 --> 00:12:57.240 Perhaps they own the back end repo. s173 00:12:57.240 --> 00:12:58.680 I send them the session. s174 00:12:58.680 --> 00:13:00.440 They resume it on their machine, all right? s175 00:13:00.440 --> 00:13:02.720 So this I'm sending them the session. s176 00:13:02.720 --> 00:13:04.520 They could run the command. s177 00:13:04.520 --> 00:13:06.040 Uh different machine, different everything. s178 00:13:06.040 --> 00:13:08.320 They use different terminal, all right? s179 00:13:08.320 --> 00:13:11.560 Uh they would reconstruct it on their machine. s180 00:13:11.560 --> 00:13:13.480 They don't have the session, right? s181 00:13:13.480 --> 00:13:15.000 They have never worked on it. s182 00:13:15.000 --> 00:13:16.839 They they can pick an agent. s183 00:13:16.839 --> 00:13:19.680 Uh the agent they pick could be a different agent, right? s184 00:13:19.680 --> 00:13:23.480 I used Cloud in the original session, but let's say they're using a different one, Cortex. s185 00:13:23.480 --> 00:13:29.800 The same setup happens to their machine, same repos, same SHAs, everything set up correctly. s186 00:13:29.800 --> 00:13:32.160 Agent starts in a triple like in mine, all right? s187 00:13:32.160 --> 00:13:34.440 They're all connected again, so they work together. s188 00:13:34.440 --> 00:13:42.440 They're all primed with a trace captured from my machine, so the back end of the repo agent on their machine has the same shine and the same history. s189 00:13:42.440 --> 00:13:44.600 The front end repo situation is the same. s190 00:13:44.600 --> 00:13:50.120 It's It's checked out at the same at the correct shard, has the agent running with the correct history. s191 00:13:50.120 --> 00:13:51.480 So, my agent was Claude. s192 00:13:51.480 --> 00:13:54.440 They coded, but they share memory. s193 00:13:54.440 --> 00:13:59.120 And they could actually actually make changes in here as shown in a small video. s194 00:13:59.120 --> 00:14:03.160 Um but I think what the memory sharing part is key, all right? s195 00:14:03.160 --> 00:14:08.880 Uh I can work, they can work, and we can share our memories as though we used to different agents in different machine. s196 00:14:08.880 --> 00:14:13.360 The full state of my session can I get materialized on their machine. s197 00:14:13.360 --> 00:14:15.560 It kind of less memory and more about the state, right? s198 00:14:15.560 --> 00:14:25.000 The state of the world that's attached to the session, uh you know, is what enables them to continue my session even though they had didn't do anything with it originally. s199 00:14:25.000 --> 00:14:27.160 It's close to the transporter in Star Trek. s200 00:14:27.160 --> 00:14:32.600 Like a whole copy of my session is all of its state materialized on their machine so they can continue. s201 00:14:32.600 --> 00:14:39.120 And that's how I often work when there is a pull request for me to review and I have questions, I usually don't ask the person. s202 00:14:39.120 --> 00:14:48.845 I resume their session on my machine, I get the exact state, fully functional, zero setup, and then I just talk to my agent about the decisions we made, right? s203 00:14:48.845 --> 00:14:48.920 [snorts] s204 00:14:48.920 --> 00:14:52.520 Because all these decisions are in the traces captured. s205 00:14:52.520 --> 00:14:56.839 So, my agent knows exactly what the other person talked to their agent. s206 00:14:56.839 --> 00:14:57.600 Right? s207 00:14:57.600 --> 00:15:05.080 So, a side note, this is also useful when I want to switch from say Claude to Codex mid-session when something goes down, okay? s208 00:15:05.120 --> 00:15:06.200 Okay. s209 00:15:06.200 --> 00:15:10.520 Take the earlier case I talked about where a bug landed in production. s210 00:15:10.520 --> 00:15:16.760 Here, I'm going to reference the session and say it's basically broken. s211 00:15:16.760 --> 00:15:21.880 Uh and you know, can you figure out what's wrong and fix it? s212 00:15:21.880 --> 00:15:27.280 The agent will look it up, will download what it needs. s213 00:15:27.280 --> 00:15:30.960 If description is like high-level information is enough, that's great. s214 00:15:30.960 --> 00:15:37.480 If not, it's going to pull relevant repos, relevant shards, agent logs, right? s215 00:15:37.480 --> 00:15:44.920 It's going to get all this information from the original session to reconstruct that state such that it can do the necessary fixes as shown here. s216 00:15:44.920 --> 00:15:47.120 He actually provided the fix, right? s217 00:15:47.120 --> 00:15:50.480 I only had to say, "This happened. s218 00:15:50.480 --> 00:15:51.440 There is a bug." s219 00:15:51.440 --> 00:15:52.440 That's it. s220 00:15:52.440 --> 00:15:56.600 No extra information was required for me to provide. s221 00:15:58.000 --> 00:15:59.000 Okay. s222 00:15:59.000 --> 00:16:04.640 So far, we have manually selected repos and sessions, but we don't have to, all right? s223 00:16:04.640 --> 00:16:08.720 Instead of selecting repos by hand, I can also tell the agent what I want. s224 00:16:08.720 --> 00:16:13.680 Remember that graph has all this intelligence, right, about how repos relate. s225 00:16:13.680 --> 00:16:20.120 I could tell my agent, "Find every repo that depends on a particular version of a library and update it." s226 00:16:20.120 --> 00:16:21.201 Right? s227 00:16:21.201 --> 00:16:23.201 [snorts] s228 00:16:23.760 --> 00:16:24.520 I mean, it knows, right? s229 00:16:24.520 --> 00:16:25.880 I I didn't have to select them. s230 00:16:25.880 --> 00:16:28.440 It knows a lot of metadata about what's going on. s231 00:16:28.440 --> 00:16:30.920 I can also ask loose questions. s232 00:16:30.920 --> 00:16:37.680 Things like, you know, uh "What if I I want to write a blog post, right, or an article?" s233 00:16:37.680 --> 00:16:45.400 I could describe it and it will figure out which repo is the most relevant based on relationships between repos and what's in them. s234 00:16:45.400 --> 00:16:46.839 Another example. s235 00:16:46.839 --> 00:16:51.680 Let's say I want to add vector index into the PR collection. s236 00:16:51.680 --> 00:16:57.360 And I want to know if anyone at any point did something relevant in any repo that I can draw from. s237 00:16:57.360 --> 00:17:03.776 So, in this case, if I do it, I'll see that it will find several sessions that appear to be relevant. s238 00:17:03.776 --> 00:17:03.800 [snorts] s239 00:17:03.800 --> 00:17:06.120 And I can load one of them or both of them, right? s240 00:17:06.120 --> 00:17:08.520 Um it's useful for many reasons. s241 00:17:08.520 --> 00:17:10.680 Uh let's just one small example. s242 00:17:10.680 --> 00:17:13.839 It helps with best practices and consistency. s243 00:17:13.839 --> 00:17:23.439 Instead of doing stuff from scratch, where, you know, every single implementation is bespoke, I can make it replicate the approach used in the session by an engineer I respect. s244 00:17:23.439 --> 00:17:26.240 Now, our code cross repos is consistent. s245 00:17:26.240 --> 00:17:28.040 That's a big deal. s246 00:17:28.040 --> 00:17:29.440 There is a lot more to it, of course. s247 00:17:29.440 --> 00:17:36.080 If you are in a repo, I can ask, you know, for sessions, it will prioritize sessions that's relevant to the repo, and vice versa. s248 00:17:36.080 --> 00:17:41.560 If I'm asking for repos, it will look at my session and see what similar sessions tend to bring in, right? s249 00:17:41.560 --> 00:17:49.040 There's a lot of interesting intelligence that make it a lot more useful that appear at first glance, okay? s250 00:17:49.040 --> 00:18:02.600 Lastly, uh everything so far I I used uh everything I shown uh used the Polygraph CLI, the current meta harness CLI, to start it, and then you can start Cloat or Cortex or whatever from within it. s251 00:18:02.600 --> 00:18:03.560 But, you don't have to use it this way. s252 00:18:03.560 --> 00:18:07.320 So, in this case, I'm already in a Cloat session, but it works with anything. s253 00:18:07.320 --> 00:18:11.040 And I could just say, "Hey, you know, I actually think a separate repo would be useful. s254 00:18:11.040 --> 00:18:20.960 Like, maybe I'm working on a Vitest plugin in this NX repo, and I could say, 'Can you add the Vitest uh repository to this session so I know what's going on?'" s255 00:18:21.560 --> 00:18:31.720 In this case, we'll engage Polygraph, and it'll set it up, you know, configure everything, and we'll bring the Vitest library, which is a the Vitest repo, the open-source repo, to my session. s256 00:18:31.720 --> 00:18:36.360 So, now uh my agent can, you know, explore it. s257 00:18:36.360 --> 00:18:41.440 It could, you know, uh figure out how it works, and maybe resolve an issue I have in my repo. s258 00:18:41.440 --> 00:18:47.600 I much prefer this to say context seven, because if I have the real code, the agent can go really deep. s259 00:18:47.600 --> 00:18:51.240 So, the deep problems are discovered all this way. s260 00:18:52.480 --> 00:18:53.400 All right. s261 00:18:53.400 --> 00:18:56.400 So, agents are constrained in space and time. s262 00:18:56.400 --> 00:19:02.200 They only see a small fraction of the code base, as they don't know the past, okay? s263 00:19:02.200 --> 00:19:05.560 Uh and both limits could be lifted. s264 00:19:05.560 --> 00:19:13.440 Polygraph uh gives agents access to the entire code your organization can reach, the one you own and open source. s265 00:19:13.440 --> 00:19:15.720 So, it's no longer constrained in space. s266 00:19:15.720 --> 00:19:18.840 Any agent can bring all of it. s267 00:19:18.840 --> 00:19:19.720 Right? s268 00:19:19.720 --> 00:19:23.520 And it gives you agent a perfect memory of what happened. s269 00:19:23.520 --> 00:19:28.040 Every session, every decision made is within reach. s270 00:19:28.040 --> 00:19:34.800 Because it crosses developer boundaries, not per developer, the agent can have more context than any single developer. s271 00:19:34.800 --> 00:19:41.720 Like a thousand engineers have an organization, create all these sessions, they all accessible to to each of them. s272 00:19:41.720 --> 00:19:43.400 Almost like sort of the Borg. s273 00:19:43.400 --> 00:19:49.200 Every agent can run by every developer contributes to kind of one big this hive mind, right? s274 00:19:49.200 --> 00:19:51.400 So, uh if it's interesting, my name is Victor. s275 00:19:51.400 --> 00:19:53.680 You can follow me on Twitter. s276 00:19:53.680 --> 00:19:58.360 If you want to check it out, go to try.poligraph.com and see if it works for you. s277 00:19:58.360 --> 00:20:00.560 Thank you.