WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=xxfMT-bPEmU NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/xxfMT-bPEmU.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:13.080 --> 00:00:14.080 Uh hey folks. s3 00:00:14.080 --> 00:00:18.880 Uh I'm Karan Vedya, co-founder and CTO of Composio. s4 00:00:19.640 --> 00:00:23.480 Most agentic tool calls today are still happening in one field. s5 00:00:23.480 --> 00:00:26.160 No guesses, it's software engineering. s6 00:00:26.160 --> 00:00:29.680 Every other kind of work is trailing far behind. s7 00:00:29.680 --> 00:00:35.760 If models keep getting better, then why are we still limited to just agentic coding? s8 00:00:35.760 --> 00:00:39.960 That's the trillion-dollar question I'm here to answer. s9 00:00:43.640 --> 00:00:47.160 Three years ago, coding agents were just auto complete. s10 00:00:47.160 --> 00:00:50.840 Today, software engineering is fully autonomous. s11 00:00:50.840 --> 00:00:56.800 We went from pressing tab tab tab to let just Claude cook. s12 00:00:56.800 --> 00:00:59.360 That's just magic. s13 00:01:00.520 --> 00:01:04.400 And why did it happen so fast in coding? s14 00:01:04.400 --> 00:01:07.040 Most people would think it's models. s15 00:01:07.040 --> 00:01:11.480 Yeah, models got really better over time over the last two to three years. s16 00:01:11.480 --> 00:01:14.520 And so did the harnesses. s17 00:01:14.520 --> 00:01:16.960 Claude code, Codex, Cursor. s18 00:01:16.960 --> 00:01:20.520 But on their own, it wouldn't have been enough. s19 00:01:20.520 --> 00:01:28.320 It only worked because all the infrastructure and systems around coding were literally meant for agents. s20 00:01:28.560 --> 00:01:32.160 Code came with the support that agents needed. s21 00:01:32.160 --> 00:01:40.280 You have got the repo, the commit history, tests, CI/CD, review, linters, revert if anything goes wrong. s22 00:01:40.280 --> 00:01:46.600 The kind of stuff that makes you trust the agents, the systems around code. s23 00:01:46.840 --> 00:01:51.640 Now, we're pointing these same amazing agents at everything else. s24 00:01:51.640 --> 00:01:54.160 Support, finance, sales. s25 00:01:54.160 --> 00:01:59.400 But the agents that were doing phenomenally well in coding, are just working blind. s26 00:01:59.400 --> 00:02:05.106 Because the infrastructure around coding doesn't even exist in other fields. s27 00:02:05.106 --> 00:02:05.600 [snorts] s28 00:02:05.600 --> 00:02:11.680 So, how do we close the bridge between coding agents and knowledge work agents? s29 00:02:11.680 --> 00:02:23.959 We think it's core six primitives and coding had all six of them while knowledge work doesn't have any and that's what we need to build. s30 00:02:23.959 --> 00:02:26.720 First is centralization. s31 00:02:26.760 --> 00:02:34.040 Coding agents work so pretty well partly because they were very near the source of truth. s32 00:02:34.040 --> 00:02:37.320 They knew the what, the why and how. s33 00:02:37.320 --> 00:02:44.040 You give them the repo, the infrastructure as code and you close the loop and let the model cook. s34 00:02:44.040 --> 00:02:51.560 The agent starts at everything with everything they need all in a single place, that is the code base. s35 00:02:51.560 --> 00:02:55.440 This is exactly what knowledge work miss today. s36 00:02:55.440 --> 00:02:59.959 For example, a single deal is scattered across five different platforms. s37 00:02:59.959 --> 00:03:09.040 The records are in Salesforce, the docs in Notion, the emails in Gmail, conversations in Slack and the support history is in Zendesk. s38 00:03:09.040 --> 00:03:13.600 There's no single source of truth, single place to get all the information. s39 00:03:13.600 --> 00:03:17.920 Everything is separate and every app has its own login. s40 00:03:17.920 --> 00:03:27.160 Before a knowledge work agent can even start to do thing, it has to go and pull all the threads and kind of tie them together itself. s41 00:03:27.160 --> 00:03:30.560 And that's still the base point where coding agent had started. s42 00:03:30.560 --> 00:03:32.200 It already had it all. s43 00:03:32.200 --> 00:03:38.560 So, how can you expect knowledge work to do knowledge work agent to do the same level of work as coding agent? s44 00:03:39.080 --> 00:03:42.400 So, the first thing we build is the missing center. s45 00:03:42.400 --> 00:03:47.160 One place where all your apps, all your connections, all your logins exist. s46 00:03:47.160 --> 00:03:51.360 So, the agent doesn't need to do the hard work of stitching them all together. s47 00:03:51.360 --> 00:03:53.800 They find it all in a single place. s48 00:03:53.800 --> 00:04:02.680 And they get the baseline with the coding agent started with, which is the repo, the information across all the stacks in one single place. s49 00:04:02.680 --> 00:04:09.000 That's the foundation you start with and you can give right accesses to your agent. s50 00:04:09.320 --> 00:04:12.760 The next thing agent needs is a sense of history. s51 00:04:12.760 --> 00:04:16.120 The ability to look back in the past. s52 00:04:16.799 --> 00:04:19.120 In code, you get it for free. s53 00:04:19.120 --> 00:04:24.040 Git keeps a record of every single thing that went in, every single change that was made. s54 00:04:24.040 --> 00:04:31.680 So, the agent can always look back and see how a certain change was made, why something worked, why something didn't work. s55 00:04:31.680 --> 00:04:35.040 Think about the kind of thing you actually ask your agent to do. s56 00:04:35.040 --> 00:04:41.120 We had to revert a change in the past because of some failure, but that was pretty hard to pull off. s57 00:04:41.120 --> 00:04:43.400 Can you look at it and get it back again? s58 00:04:43.400 --> 00:04:47.520 It just reach to the history and get it back and cook it. s59 00:04:47.520 --> 00:04:47.548 The s60 00:04:47.548 --> 00:04:47.600 [snorts] s61 00:04:47.600 --> 00:04:49.840 history isn't just for agent. s62 00:04:49.840 --> 00:04:53.440 It's also for you to keep a record what the agent is doing. s63 00:04:53.440 --> 00:05:07.040 You can see what the agent is doing, where it is up, where it is doing successful things, and like instead of trusting what the agent is saying you, you can just go to those particular apps and look at what it has done. s64 00:05:09.400 --> 00:05:12.000 Now, ask those same questions about knowledge work. s65 00:05:12.000 --> 00:05:16.040 What led to the CRM being in a state where it is today? s66 00:05:16.040 --> 00:05:22.919 How did the How did my colleague craft that amazing mail that led to the closing of the deal? s67 00:05:22.919 --> 00:05:27.080 What's the actual process to escalate a support issue or even close one? s68 00:05:27.080 --> 00:05:31.880 The answers are smeared across hundreds of apps and none of them keep the history. s69 00:05:31.880 --> 00:05:33.760 So, the agent has no memory. s70 00:05:33.760 --> 00:05:36.520 It starts from blank state almost every time. s71 00:05:36.520 --> 00:05:40.760 No idea what was tried before, what worked, what didn't work. s72 00:05:40.760 --> 00:05:44.240 And you you have nothing to look at all as well. s73 00:05:44.240 --> 00:05:49.480 Once the agent runs, it tells you it has done successfully, you don't know if it has actually done successfully. s74 00:05:49.480 --> 00:05:52.880 There's no way to know if it is right or not. s75 00:05:52.880 --> 00:05:56.680 And that's what's missing, a record of work. s76 00:05:57.080 --> 00:06:06.560 Now, because everything finally runs through one single place, that centralization, we can build a layer on top of it, the record. s77 00:06:06.560 --> 00:06:12.840 Every single like action that agent takes can be logged across every other app. s78 00:06:12.840 --> 00:06:17.320 Whatever it touched, whatever it skipped, what worked, what didn't. s79 00:06:17.320 --> 00:06:20.680 Via this, firstly, the agent gets memory. s80 00:06:20.680 --> 00:06:28.440 It can look back at how similar tasks were done before, what was successful, and replicate it again. s81 00:06:28.440 --> 00:06:31.560 It doesn't start with a blank state all the time. s82 00:06:31.560 --> 00:06:33.320 Second, you get trust. s83 00:06:33.320 --> 00:06:36.240 You can finally see exactly what the agent is doing. s84 00:06:36.240 --> 00:06:44.160 So, instead of hoping it will do the right thing, you can just go back and check and catch it if it does something bad. s85 00:06:44.160 --> 00:06:51.040 And as you kind of see it more and more doing the right things, you'll develop the trust and offload more tasks to it. s86 00:06:51.040 --> 00:06:54.080 The next thing an agent needs is context. s87 00:06:54.080 --> 00:06:57.680 And there are really two kinds of context, if you think about it. s88 00:06:57.680 --> 00:07:01.160 The first the shape of shape of the platform, the architecture. s89 00:07:01.160 --> 00:07:05.040 How things flow into each other, how things are tied, the data flows. s90 00:07:05.040 --> 00:07:12.440 Like kind of like a map which a senior engineer carries in their head, and a junior engineer takes probably 3 months to develop. s91 00:07:12.440 --> 00:07:13.640 The second is style. s92 00:07:13.640 --> 00:07:19.000 This isn't what's objectively correct, but more like what good looks like in your company. s93 00:07:19.000 --> 00:07:29.720 So, how you do things, things like linter, type checks, etc. And maybe you use a TypeScript decorator which nobody else would. s94 00:07:29.720 --> 00:07:34.080 This is not exactly somewhere in a playbook, it's more in your code base. s95 00:07:34.080 --> 00:07:47.840 It's all available in your code base, so the agent can just go and look and figure out the specs, what you like, the like linters, the formatters, etc. Now, coming to knowledge work, s96 00:07:47.840 --> 00:07:48.600 the same thing. s97 00:07:48.600 --> 00:07:50.800 Say you're writing a doc to a customer. s98 00:07:50.800 --> 00:07:58.280 To even start, I would have to open the database to pull their usage, check PostHog of how they have been actually using things. s99 00:07:58.280 --> 00:08:01.520 And Salesforce to look at their deal details. s100 00:08:01.520 --> 00:08:05.560 Only then I can even start writing the first line of the doc. s101 00:08:05.560 --> 00:08:09.240 The answer wasn't isolated in just one of those tools. s102 00:08:09.240 --> 00:08:15.600 I'm able to write this is doc because I'm pulling the threads across all these tools into one single context in my head. s103 00:08:15.600 --> 00:08:20.960 So, putting history and context together, that's how you map how the organization works. s104 00:08:20.960 --> 00:08:25.160 And that part is not available to agent handily. s105 00:08:26.360 --> 00:08:38.360 So, as we did centralization and logging, the record we just built, the one that gives the agent memory and lets you check what it did, also does one more interesting thing. s106 00:08:38.360 --> 00:08:42.719 It If you log enough of what every agent is doing, you start to see patterns. s107 00:08:42.719 --> 00:08:44.960 You start to see how the organization works. s108 00:08:44.960 --> 00:08:51.760 And you start to form skills, which is some sort of distillation of how the organization has been working. s109 00:08:51.760 --> 00:09:00.960 Which approaches work, which don't, which what led to failures in the past, etc. The The record isn't just history of what happened anymore. s110 00:09:00.960 --> 00:09:03.920 It's a picture of how your company operates. s111 00:09:03.920 --> 00:09:06.480 And it actually works at three different levels. s112 00:09:06.480 --> 00:09:15.880 How a tool works in general, which is applicable to every person, how a company does things, and how you prefer to do things, what good like looks like to you. s113 00:09:15.880 --> 00:09:19.600 And that's the context that context that was missing for a knowledge work agent. s114 00:09:19.600 --> 00:09:27.520 How the work actually gets done, the real playbook of sorts, and the preference of a company of a personal user. s115 00:09:27.520 --> 00:09:32.839 And now the agent can query it and stop guessing how the company operates. s116 00:09:34.280 --> 00:09:38.400 The other reason coding agents work so well, they test themselves. s117 00:09:38.400 --> 00:09:40.040 The work checks itself. s118 00:09:40.040 --> 00:09:41.440 Verification. s119 00:09:41.440 --> 00:09:44.920 The moment the agent writes a code, a stack of checks follow. s120 00:09:44.920 --> 00:09:47.640 The unit tests can catch small mistakes. s121 00:09:47.640 --> 00:09:52.360 The integration tests catch the ones that only affect components three blocks away. s122 00:09:52.360 --> 00:09:57.840 The type system would not even work and run if anything is going wrong. s123 00:09:57.840 --> 00:10:00.280 The compiler will not even build. s124 00:10:00.280 --> 00:10:12.880 On top of it sits the softer checks, linters, formatters, bugboard.md review skills, etc. And these ensure that the code matches the way your time team likes to follow the standards of your team. s125 00:10:12.880 --> 00:10:14.120 None of it needs you. s126 00:10:14.120 --> 00:10:21.400 The agent completes the loop on its own and makes sure that it follows the standard and is able to make the code run. s127 00:10:21.400 --> 00:10:28.600 Now, think about like so, there's an a while back I pointed my open claw at a hiring outreach. s128 00:10:28.600 --> 00:10:30.280 Mass emails to candidates. s129 00:10:30.280 --> 00:10:31.320 It ran. s130 00:10:31.320 --> 00:10:34.880 It sent tons of emails. s131 00:10:34.880 --> 00:10:37.560 Uh some of you might have also gotten it from my open claw. s132 00:10:37.560 --> 00:10:40.040 It did exactly what I told it to do. s133 00:10:40.040 --> 00:10:41.920 It was also a disaster. s134 00:10:41.920 --> 00:10:46.120 The kind that ends up on Twitter with my name on top of it. s135 00:10:46.120 --> 00:10:51.000 Uh yeah, I think you can see a you Karan Vaidya. s136 00:10:51.000 --> 00:10:54.440 Uh I was not the happiest when it happened. s137 00:10:54.440 --> 00:10:58.480 And here's the thing, every check from the past slide would have passed. s138 00:10:58.480 --> 00:11:00.920 The emails were valid, their addresses were real. s139 00:11:00.920 --> 00:11:04.240 It actually got to real people who posted. s140 00:11:04.240 --> 00:11:10.680 Uh there was no best tool in the world to actually uh question what really mattered. s141 00:11:10.680 --> 00:11:13.320 Should this have gone at all? s142 00:11:13.320 --> 00:11:15.080 That's the gap in code. s143 00:11:15.080 --> 00:11:17.320 These tests tell you what's wrong and right. s144 00:11:17.320 --> 00:11:21.120 Here, the internet told me that I was wrong. s145 00:11:21.839 --> 00:11:24.560 So, we build the checks that are missing. s146 00:11:24.560 --> 00:11:28.080 The problem in the above thread was wasn't the outreach was wrong. s147 00:11:28.080 --> 00:11:31.480 It was that it went out before even I getting to know. s148 00:11:31.480 --> 00:11:33.320 So, the fix is simple. s149 00:11:33.320 --> 00:11:35.440 Catch before it's even real. s150 00:11:35.440 --> 00:11:37.240 So, we have two ways in which we do that. s151 00:11:37.240 --> 00:11:43.560 One, before the agent senses anything, it checks the draft emails that I've sent before. s152 00:11:43.560 --> 00:11:47.440 If it matches my style, if it matches the goodness that I like. s153 00:11:47.440 --> 00:11:59.360 The second, before doing anything destructive in the real world scenario, we provide the agents and boxes, which mock the real tools, and they can send they can do action on top of these sandboxes. s154 00:11:59.360 --> 00:12:07.920 So, instead of the blast radius hitting the real world, it will hit a sandbox, and then I can review it before the agent does the real thing. s155 00:12:07.920 --> 00:12:11.560 Put those two together, and you've got something knowledge work never had. s156 00:12:11.560 --> 00:12:16.240 A way for agent to check its own work before it's even real. s157 00:12:16.240 --> 00:12:20.120 It can finally close its own loop instead of stopping to wait for you. s158 00:12:20.120 --> 00:12:29.000 And with all that, you can trust the action it is taking without you getting bombarded with the tweets that I shoot. s159 00:12:29.320 --> 00:12:32.120 Next thing the agent needs is governance. s160 00:12:32.120 --> 00:12:34.720 Building trust is controlling what the agent can do. s161 00:12:34.720 --> 00:12:38.240 Putting up the right walls around the agents. s162 00:12:39.720 --> 00:12:44.160 In code, this is mostly solved and like has multiple layers. s163 00:12:44.160 --> 00:12:49.120 The agent can do whatever it wants on its own branch, but it can't merge to main. s164 00:12:49.120 --> 00:12:52.320 A human reviewer sits in between it merging to main. s165 00:12:52.320 --> 00:12:54.000 The critical files have code owners. s166 00:12:54.000 --> 00:12:57.960 So, whenever it touches one of them, the right people are getting involved. s167 00:12:57.960 --> 00:13:00.360 Uh we use agents to ship to preview deployments. s168 00:13:00.360 --> 00:13:04.240 Never let it touch the production deployments, so we control it there. s169 00:13:04.240 --> 00:13:12.720 The governance is not a single gate, but multiple of them, and each varying its sizes depending on the blast radius it exposes. s170 00:13:12.720 --> 00:13:15.880 None of it slows the agent down in safe paths. s171 00:13:15.880 --> 00:13:19.640 Just prevents it from up production. s172 00:13:19.640 --> 00:13:25.800 And the tighter those lines are, the more you can trust the agent and let it go berserk. s173 00:13:26.200 --> 00:13:27.600 You probably saw this one. s174 00:13:27.600 --> 00:13:36.080 The director of alignment at Meta Superintelligence Lab hooked up an agent to its email and it started destroying its email, deleting a lot of them. s175 00:13:36.080 --> 00:13:37.480 She told it to stop. s176 00:13:37.480 --> 00:13:38.520 It kept going. s177 00:13:38.520 --> 00:13:41.960 Finally, she had to run to a physical machine to stop it. s178 00:13:41.960 --> 00:13:45.920 But by then, 200 emails had actually vanished. s179 00:13:45.920 --> 00:13:50.840 She had told it beforehand in prompt to confirm before acting on such cases. s180 00:13:50.840 --> 00:13:54.280 But that was just a prompt which probably would have compacted away. s181 00:13:54.280 --> 00:14:03.480 And if someone whose sole job is AI alignment can't prompt it the agent correctly, then probably none of us can. s182 00:14:03.480 --> 00:14:08.520 And that's the real reason these agents are so hard to trust. s183 00:14:08.520 --> 00:14:12.720 Not because they're worse than the coding agents, but because there's no wall around them. s184 00:14:12.720 --> 00:14:17.200 In code, the wall was already built into the system while we were developing earlier. s185 00:14:17.200 --> 00:14:19.920 Knowledge work also has some bits and pieces here and there. s186 00:14:19.920 --> 00:14:23.320 For example, Gmail has scopes, Salesforce has permission levels. s187 00:14:23.320 --> 00:14:32.040 But it's so scattered all over the place that it's very hard to have real control and mostly people end up doing it via prompting. s188 00:14:32.040 --> 00:14:34.680 And prompting is fragile. s189 00:14:34.680 --> 00:14:36.880 The agent will find those loopholes. s190 00:14:36.880 --> 00:14:38.480 Things will get compacted away. s191 00:14:38.480 --> 00:14:47.240 And at scale, uh one of these fence will break and you'll also be in the same condition where 200 of your important emails are vanishing. s192 00:14:47.240 --> 00:14:49.440 So, what would actually stop it? s193 00:14:49.440 --> 00:14:57.960 Not like a better instruction, but wall that the agent can't cross even if it forgot that wall existed. s194 00:15:00.960 --> 00:15:03.720 So, we build these walls in two layers. s195 00:15:03.720 --> 00:15:09.040 The first layer is deterministic, control over what the agent can reach, what it has access to. s196 00:15:09.040 --> 00:15:13.040 Um a hiring agent can probably just read the emails. s197 00:15:13.040 --> 00:15:17.600 A support agent can create a draft email, but not actually send it. s198 00:15:17.600 --> 00:15:19.920 The boundary lives outside these agents. s199 00:15:19.920 --> 00:15:24.360 It can't be argued with by the agent or forgotten or compacted. s200 00:15:24.360 --> 00:15:28.840 Use instruction failed because it lived in agent's memory in the prompt. s201 00:15:28.840 --> 00:15:30.480 This doesn't. s202 00:15:30.480 --> 00:15:36.320 Uh but access alone wouldn't have saved her because she was actually building an email agent. s203 00:15:36.320 --> 00:15:39.800 So it definitely needed access to that email. s204 00:15:39.800 --> 00:15:49.000 Um the other thing that we do is provide policies, which is you can define natural language policies of what the agent can do even with those accesses. s205 00:15:49.000 --> 00:15:53.760 So things like never delete more than 10 emails without my permission. s206 00:15:53.760 --> 00:15:56.880 Never email outside a particular domain. s207 00:15:56.880 --> 00:16:00.760 Rules that with even those access control the behavior. s208 00:16:00.760 --> 00:16:09.360 So between those two things, one layer controls the what the agent can reach and the other layer can control the behavior with what it can do with that reach. s209 00:16:09.360 --> 00:16:11.760 Together, it's real governance for the agent. s210 00:16:11.760 --> 00:16:16.880 Not asking the agent to behave, but enforcing it what it can do. s211 00:16:18.320 --> 00:16:20.440 The last pillar, reversibility. s212 00:16:20.440 --> 00:16:25.880 And this is the one of the Uh this is where we reach when things go wrong. s213 00:16:25.880 --> 00:16:27.920 Can I undo it? s214 00:16:27.920 --> 00:16:30.920 In code, you almost always can. s215 00:16:30.920 --> 00:16:32.280 Every change is recorded. s216 00:16:32.280 --> 00:16:33.920 Things can be walked back. s217 00:16:33.920 --> 00:16:40.400 You can get revert the last commit or you can get bisect to the commit that broke your production and revert it. s218 00:16:40.400 --> 00:16:44.400 Um now Like I'm not saying it's good. s219 00:16:44.400 --> 00:16:46.000 I I won't pretend like that. s220 00:16:46.000 --> 00:16:50.200 If things go in production and break, it's always bad, but it's still not permanent. s221 00:16:50.200 --> 00:16:51.920 You can still walk back from it. s222 00:16:51.920 --> 00:17:02.960 And that's what gives you confidence to let your agents cook and let them do some magic because even if they they break the things, you can you have a pathway back. s223 00:17:03.280 --> 00:17:05.439 For knowledge work, there is no undo button. s224 00:17:05.439 --> 00:17:07.720 Things Like think about use inbox. s225 00:17:07.720 --> 00:17:09.560 Those 200 emails are gone. s226 00:17:09.560 --> 00:17:10.480 They have vanished. s227 00:17:10.480 --> 00:17:12.040 That's the normal case, by the way. s228 00:17:12.040 --> 00:17:15.439 The disaster case is a sent email, which you can't revert back. s229 00:17:15.439 --> 00:17:17.199 A wire that has already been made. s230 00:17:17.199 --> 00:17:18.880 So you can't get that money back. s231 00:17:18.880 --> 00:17:20.920 A deleted record, gone forever. s232 00:17:20.920 --> 00:17:25.000 Most actions actually in knowledge work don't have an undo button. s233 00:17:25.000 --> 00:17:27.280 And that changes the whole equation. s234 00:17:27.280 --> 00:17:29.160 Uh that changes the blast radius. s235 00:17:29.160 --> 00:17:31.880 Uh with code, you can trust the agent after the fact. s236 00:17:31.880 --> 00:17:34.800 Let it run, check the result, undo if it's wrong. s237 00:17:34.800 --> 00:17:36.240 Out here, there's no coming back. s238 00:17:36.240 --> 00:17:40.840 The only place left for you is to is to trust before the agent acts. s239 00:17:40.840 --> 00:17:44.880 That's what makes these agents feel dangerous in a way coding agents never did. s240 00:17:44.880 --> 00:17:46.560 It's not that they fail often. s241 00:17:46.560 --> 00:17:50.000 It's that out there failure is forever. s242 00:17:50.000 --> 00:17:55.200 So, either you completely go up front or never let it act. s243 00:17:55.400 --> 00:17:59.280 Let me be honest, reversibility is the hardest to replicate in knowledge work. s244 00:17:59.280 --> 00:18:04.720 Real undo, the way it exists for code, probably doesn't exist in all the scenarios in knowledge work. s245 00:18:04.720 --> 00:18:09.640 But we have some scenarios where undo exists and we call them. s246 00:18:09.640 --> 00:18:11.800 So, let's say you add a label. s247 00:18:11.800 --> 00:18:14.080 You can remove the label afterwards. s248 00:18:14.080 --> 00:18:25.640 But for actions that you can't undo at all, like hard deletes that disappear the emails from your inbox, we again provide a sandbox where the agent can do the thing first in the sandbox s249 00:18:25.640 --> 00:18:30.080 and you can review it and then actually goes into the production environment. s250 00:18:30.080 --> 00:18:31.560 None of it touches the real world. s251 00:18:31.560 --> 00:18:33.200 That's the whole flip. s252 00:18:33.200 --> 00:18:35.680 In code, you can undo the mistake after it happens. s253 00:18:35.680 --> 00:18:37.600 Here, you catch it before it does. s254 00:18:37.600 --> 00:18:41.040 Different timing, same result, a mistake that won't stick. s255 00:18:41.040 --> 00:18:42.160 Think about you again. s256 00:18:42.160 --> 00:18:45.400 The actions we could reverse, we would give it a reverse button. s257 00:18:45.400 --> 00:18:52.840 The ones we couldn't, the agent would hit the sandbox first and she would be notified, your 1,200 emails are going to get deleted. s258 00:18:52.840 --> 00:18:55.040 Do you want it? s259 00:18:55.040 --> 00:18:57.240 It's not done yet. s260 00:18:57.240 --> 00:19:07.120 Uh but across billions of actions that we're going through, we are learning on the way which ones can be walked back, which ones can't, and preparing the sandbox accordingly. s261 00:19:09.240 --> 00:19:11.560 If you take one thing away today, take this. s262 00:19:11.560 --> 00:19:14.040 For 2 years, the model was the bottleneck. s263 00:19:14.040 --> 00:19:17.200 So, everybody was racing towards better and better model. s264 00:19:17.200 --> 00:19:23.120 Now, the models have gotten good enough where software engineering is 100% autonomous. s265 00:19:23.120 --> 00:19:26.040 But, now everything else is the bottleneck. s266 00:19:26.040 --> 00:19:36.080 This the same model that writes your code can also do your hiring, sales, and other knowledge work. s267 00:19:36.080 --> 00:19:39.440 Um but, it right now it's working blind. s268 00:19:39.440 --> 00:19:44.640 No history, no context, no ways to verify, no guardrails, no undo. s269 00:19:44.640 --> 00:19:48.160 So, the bottleneck has moved. s270 00:19:48.280 --> 00:19:51.000 Now, it's infrastructure that nobody has yet built. s271 00:19:51.000 --> 00:19:54.040 And that's what we are building at Composio. s272 00:19:55.160 --> 00:19:56.400 Yeah. s273 00:19:56.400 --> 00:19:59.640 We are powering billion plus tool calls in total. s274 00:19:59.640 --> 00:20:02.440 Uh 300 million tool calls happening every month. s275 00:20:02.440 --> 00:20:08.000 And if you are building an agent, just point it to Composio and see the magic happen for knowledge work. s276 00:20:08.000 --> 00:20:13.720 And if you want to build the future of substrate of AI agents, then please come to me. s277 00:20:13.720 --> 00:20:17.400 We are definitely hiring, and there's a lot lot left to do. s278 00:20:17.400 --> 00:20:19.400 The models will keep getting better. s279 00:20:19.400 --> 00:20:21.240 The bottleneck won't be models. s280 00:20:21.240 --> 00:20:22.760 It will be the things around it. s281 00:20:22.760 --> 00:20:25.000 Thank you.