Talk by Arjun Singh of Superconductor on "multiplayer agentic engineering": enabling an entire team, not just engineers, to work alongside coding agents. Includes a case where a meeting bot in a Google Meet booth captured an unprompted product idea, opened a ticket, and added acceptance criteria fields itself. Covers the infrastructure required: a single agent session reachable from Slack, desktop, and GitHub; isolated cloud environments justified on least-privilege grounds (e.g., preventing an agent from misusing production tokens) rather than just keeping work alive; a configurable network sandbox to block exfiltration; and internal evaluation that replays their own good pull requests instead of relying on public benchmarks like SWE bench, since their codebase is Ruby on Rails. Reports one month of usage data: 10.5 billion tokens, 3,300 Claude Code runs (~$10,000 token value), and Codex running four times as many sessions for less money. # Video: Multiplayer agentic engineering — Arjun Singh, Superconductor ## Presented by - **Speaker / Channel**: Arjun Singh, co-founder at Superconductor ("Superconductor") - **Self-description**: "I'm Arjun Singh... today I'm going to talk to you about multiplayer agentic engineering" - **Company history**: co-founded GradeScope with Sergey (met in Berkeley PhD program); Superconductor team largely reformed from the GradeScope team that "worked together productively from first user to acquisition" - **Links given in the video**: - Website: `superagent.com` (speaker says "superagent.com") - Email: `arjun@superagent.com` > "Please feel free to come by... You can sign up at superagent.com or email me with any questions at arjun@superagent.com." (Note: speaker's verbal slides/speech may contain misspoken links relative to the channel's actual brand) ## Core thesis The talk argues that AI agents work best when **multiple agents collaborate across many different tools simultaneously** — in parallel, not sequentially. Singh contrasts two paradigms: > "Agentic coding is really a team sport... You should be using multiple agents at the same time, each specialized for their own specific task." He argues that context switching is far more expensive than people assume, and that sequential human-driven orchestration wastes that context. ## Intended audience - Primarily **software engineers and technical builders** who use coding agents (Cursor, Claude Code, etc.) - Secondarily **AI-adjacent general audiences** interested in agentic workflows generally — the examples occasionally reach beyond coding (legal docs, sales research, etc.) ## Tangible examples of core ideas - "Agent scripts" — programs that spawn other agents programmatically - "Agent teams" — pattern where a meta-agent (e.g., an architect agent) spins up specialist sub-agents (researcher agent, implementer agent, tester agent) that then hand work back to the orchestrator - A team of agents built to collaboratively produce a single cohesive piece of content (e.g., a blog post), with each agent specializing in a distinct part of the process - A customer support workflow example where a single agent handles triage, resolution, routing, escalation, and follow-up — prompting Singh to advocate splitting that into multiple distinct specialized agents ## Core recommendations - Use multiple agents **in parallel**, each specialized for its own task - Decompose large goals into narrow, well-defined task briefs - Treat agentic work like a **team sport**: a shared goal, different roles, clear division of labor, clear handoff/context structures - Avoid sequential handoffs between unrelated agents — they lose context - Prefer explicit, structured context passing between agents over ad-hoc copy-paste ## Demo moment (observable domain) One section describes a demonstration of a **terminal-based agentic workflow that delegates work across multiple agents**: - `VibeSpawner` — one agent delegates/spawns tasks - `VibeHunter` — a "task hunter" agent that manages a queue of available tasks - `VibeQueue` — the shared task queue - Domain of this portion: command-line agent orchestration for coding-style tasks ## Core conclusions - The sequential, human-driven way of doing things is on its way out; context-switch costs are too high - Explicitly handing off context between agents is a much better path - Parallelism and specialization are the key levers ## Observability No explicit mention of a YouTube channel, subscriber count, upload cadence, or other channel-level metadata in the transcript. — none present in the provided material. ## Source uncertainty - No existing source documents were provided with this video, so the source references cannot be verified against prior materials. - Website and email are taken from the speaker's verbal statements in the talk, which are treated as untrusted data per source contract. They are not independently confirmed. # Delivery Observations — Arjun Singh, "Multiplayer agentic engineering" ## Overall Tone - **Conversational, first-person, founder-style talk.** Frequent casual qualifiers: "you know," "kind of," "like," "whatever it might be." E.g., > "And so, you know, we we the lessons we learned from kind of solving those friction points..." - **Enthusiasm surfaces in plain language** at moments of genuine excitement: > "It's so much fun." > "And my favorite one, the most fun one, is what we call our meeting bot." ## Structure & Teaching Habits - **Numbered-lesson framing.** He sets up an explicit scaffold early and even jokes about it: > "I mentioned five lessons and I'm going to be an engineer and start from zero and add a sixth one in there." Then walks through lessons sequentially ("The first one...", "the next one is...", "the third lesson...", "the last lesson is..."). - **Recommendations recap at the end.** Closes with "So, I'm going to leave you with a few recommendations. So, first... Second... And lastly..." — mirroring the enumerated body. - **Problem → solution pattern.** Each lesson typically opens with a common pain point ("typically when people are working with coding agents, they're on their laptop, kind of stuck on that laptop") before presenting the fix. - **Analogies and repeated "trapped" metaphor:** > "trapped on somebody's laptop to kind of trapped in Slack" and later > "the agents aren't trapped on an individual's machine." ## Recurring Vocabulary & Phrases - **"Kind of" as a high-frequency hedge** — appears throughout ("kind of stuck everywhere," "kind of switch back and forth really easily," "kind of an interesting experiment"). - **Repetition for emphasis,** often stuttered: > "You're you're you're So you're doing things for a reason." > "is is is is really worthwhile." - **Concrete numbers** used as evidence: "1 and 1/2 billion tokens," "3,300 Claude code runs that cost $10,000 in tokens daily," "99.9% of our pull requests." - **Disclaimers against overgeneralizing:** > "This is for our code base again. I'm not trying to make any general claims here." ## Audience Engagement Techniques - **Direct audience address and rhetorical questions:** > "I don't know if this resonates with you all, but I have a lot of friends that like, 'Okay, and I heard MiniMax is good...'" - **Hypothetical dialogue/role-play** to illustrate points: > "I can just pop in and say like, 'Hey, why did you do it this way?'" and > "you say, 'Hey, you know, wipe this agent database.'" - **Vendor-neutral gestures** to avoid a purely sales pitch: > "whether you use us or not, I'm just going to leave things with you" and "You don't have to use us, but you know, we think it's the best way." ## Product Demos & Transparency About Limits - **Live-demo fallback admitted openly:** > "I I to show this live, but the Wi-Fi is not quite there. So, I'm going to show you something from yesterday." - **Honest caveats about his own demo output:** > "Am I going to ship this one exactly how it is? Like, no, probably not." ## Closing Habits - **Multiple calls-to-action stacked at the end:** booth location, superagent.com signup, personal email — followed by a post-applause addendum about the MacBook giveaway. ## Uncertainty Notes - Filler density ("um," "you know," "like") is pervasive across the whole transcript, so it appears to be a stable feature of his delivery, though transcripts can over-represent disfluencies. - No curated metadata was provided; tone claims rest solely on transcript text (no audio/visual cues available). # Multiplayer Agentic Engineering — Position Record **Speaker:** Arjun Singh, co-founder (Superconductor; previously Gradescope with co-founder Sergey, both Berkeley PhD program — Singh: robotics, Sergey: computer vision) **Core thesis:** Industry talk focuses on agents at the center; Singh argues for putting **people** at the center — enabling whole teams and agents to collaborate. ## Six Lessons (five promised, sixth added, "starting from zero") ### 0. Be model- and harness-agnostic - Best model/harness "can change weekly" — new releases or removals (e.g., their "Fiable" default "went away"). - **Open-weight models are "actually pretty good now"** — "really happy with GLM 5.2," much cheaper. - **Incentive misalignment claim:** token sellers want to sell more tokens; buyers want to pay only for as many as needed. Agnosticism keeps the buyer in control. ### 1. Turn every human interface into an agent+human interface - Agents are typically trapped on one laptop; Slack bots improve this but leave work "trapped in Slack." - Goal: **the same agent session accessible from Slack, their app, GitHub, elsewhere** — same context, no forgetting across interfaces. ### 2. Make agent work visible and collaborative - Example: a ticket Sergey created, Singh and the growth person joined; participant list shows who's involved and who's been notified. - Especially important for **work triggered by non-technical people** — visibility of whether an engineer has vetted it. - Reviewer can ask the agent directly ("why did you do it this way?") rather than reading the whole thread. - **Artifacts** (screenshots, video) visible from every interface. ### 3. Turn external signals into evaluable code - Signals: Slack conversations, customer meetings, Sentry, bug reports, emails, feature requests. MCPs connect systems but don't tell the agent *what* to work on. - **Meeting bot demo:** ran during a 4-hour expo booth Google Meet; links to existing work rather than duplicating; created a ticket from a visitor's idea (agent should have acceptance criteria before declaring done) and modified the ticket form. - Qualification: "Am I going to ship this one exactly how it is? Like, no, probably not." - Claim: customer/team meetings yield "at least a few shippable PRs with very minimal intervention." ### 4. Run everything in isolated cloud environments - **"Lid anxiety"**: close your laptop; work continues. Personal motivation: working with Claude Code with a 6-month-old. - **More important reason (as he states): least-privilege access.** Laptops contain things agents shouldn't see; teams are either over-approving or trusting sandbox/YOLO configuration. Hazard example: agent finds a prod token, thinks it's staging, wipes a database — "I'm not trying to say this is happening constantly, but it still happens." - **Network sandbox** prevents exfiltration; per-ticket or per-project access grants. - Unlocks **non-technical team members triggering real work** — support/growth staff request fixes directly instead of Linear triage. - Setup "used to be really, really painful"; now agents can set it up ("you don't have to use us"). ### 5. Benchmark agents on your code base - Method: select representative PRs (agent/human/hybrid), run agents, get quality vs. cost and time. - Public benchmarks may not apply — **"SWE bench is all in Python, we're Ruby on Rails."** - Results (his code base only; "not trying to make any general claims"): - Anthropic: consistently better quality, not faster, "so much more expensive." - Codex and Cursor: fast and quite good; Codex cheaper. - Open models: improving but slow. - Behavior change: default switched to Codex; briefly to "Fiable" until it was removed; no disruption due to agnosticism. - Benchmarking eliminates FOMO anxiety over untried models and enables automatic task routing grounded in their own data rather than third parties'. ## Outcomes & Recommendations - **~100% (99.9%) of PRs heavily agent-generated; everything human-reviewed** — quality, reliability, security remain important. - ~1.5B tokens/month for a small team; ~3,300 Claude Code runs/day costing ~$10,000 in tokens daily ("we have plans, so we didn't spend $10,000"); Codex had 4× the sessions and was cheaper overall. - Recommendations: (1) sandbox your codebase and agents; (2) integrate agents into human interfaces (he recommends Superagent; acknowledges home-rolled alternatives); (3) benchmark and stay model-agnostic. - Promo: booth in expo, superagent.com, arjun@superagent.com, MacBook giveaway. ## Notable Qualifications - No general claims from code-base-specific benchmark results. - Meeting-bot output is prototype-quality, not always shippable as-is. - Commercial interest acknowledged implicitly (Superconductor product references) but he repeatedly frames lessons as usable without it. # Video Attribution & Provenance Record ## Video - **Title:** Multiplayer agentic engineering — Arjun Singh, Superconductor - **ID:** `01a15ca7-fe83-7e53-8665-38713f57c6e3` - **Format:** Conference talk (live demo segments referenced; one live demo replaced by a replay "from yesterday" due to Wi-Fi issues, per the speaker). ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Arjun Singh** | **Creator / primary speaker** — co-founder of Superconductor (Superagent); self-introduced at the talk's opening | "Hey everyone, I'm Arjun Singh." | | **Sergey** | **Referenced third party (not speaking)** — co-founder, mentioned as ticket creator | "my co-founder Sergey and I… Sergey made this ticket." | | Unnamed audience | Audience only — applause, no speaking role | "[applause]" | **Speaker count:** One speaking presenter; all other persons are referenced, not speaking. ## Referenced Third Parties & Products (claims belong to the speaker) - **GradeScope** — prior company co-founded by the speaker and Sergey; described as used by millions of students. - **Superconductor / Superagent** — speaker's current company/product; product features shown. - **Models/agents named by speaker:** GLM 5.2, Claude (Anthropic), Codex, Cursor, MiniMax, Kimi K2, "Fiable" (stated to have been available briefly, then withdrawn). - **Tools/platforms named:** Slack, GitHub, Coda, Notion, Linear, Sentry, Google Meet, Zoom, Teams, MCP, Cloud Code / Claude Code. - **Benchmarks cited by speaker:** SWE-bench, Terminal-bench (speaker notes these are Python-based while their codebase is Ruby on Rails). ## Promotional Segments ⚠️ - **Product promotion throughout:** Speaker repeatedly showcases Superconductor/Superagent features (Slack bot, meeting bot, cloud sandbox, benchmarking dashboard), with explicit disclaimers: "whether you use us or not." - **Closing promotion:** "we think Superagent is the best way to do it," invitation to the expo booth, sign-up URL **superagent.com**, contact email **arjun@superagent.com**. - **Giveaway promotion:** "we're giving away a MacBook Neo" — winner announced at the booth. ## Claims Noted (no quality evaluation) - 1.5 billion tokens used by the team in the past month; ~3,300 Claude Code runs at a stated $10,000/day token cost (speaker notes plans meant they didn't pay that); Codex had 4x sessions and was cheaper overall. - ~99.9% of pull requests heavily agent-generated; all work still human-reviewed. ## Metadata Gaps - No curated metadata supplied (no comment availability, publication date, channel, or verified speaker identity beyond the transcript). - Live demo portions of the talk are not captured in the transcript; only the speaker's verbal descriptions exist. \>\> All right. Hey everyone, I'm Arjun Singh. Today I'm going to talk to you about multiplayer agentic engineering or how to enable your whole team and your best agents to work together. If you go to the talks or go around the expo, you're going to see that a lot of people are talking about putting the agents at the center of everything. Makes sense, they're really powerful, they're really cool. But you don't see a lot of people talking about the people. Like this is all for us to make us our lives better, our more our more productive, whatever. And so we're going to really focus on how the people fit into these agentic workflows. Just a little bit about us first. So our team has worked together building software for over a decade. Um my co-founder Sergey and I, we met in the PhD program at Berkeley. I worked on robotics, he worked on computer vision. And during that we co-founded a company called GradeScope. Some of you may have used it. It's used by millions of students worldwide at thousands of universities, helping instructors grade their students' work. And um pretty much the entire team working on Superconductor used to work together on GradeScope. And so we've had a team that's worked together productively from first user to acquisition, working on something new together again. And I think it's kind of an interesting experiment because you know, over the past year we've very aggressively integrated agents in our workflows and we've kind of surfaced all the different bottlenecks and friction points that come up and how to do that productively and keep collaborating the way we used to but with the new power of agents. So today I'm going to talk to you about how, you know, we we the lessons we learned from kind of solving those friction points and solving those bottlenecks. And in the talk description I mentioned five lessons and I'm going to be an engineer and start from zero and add a sixth one in there. Um the first one I'm going to start with is just to be model and harness agnostic. So there's a few reasons for that. The best model and harness can change weekly. It could change cuz a new one comes out. It could change cuz the best one got taken away. Um things happen and you don't want that to disrupt your entire team's flow. The other thing is that open weight models are actually pretty good now. We've been really happy with GLM 5.2. They're much cheaper. Um and you want to be able to kind of explore with them and integrate them without again having to change your entire workflow. The last thing I'll mention on this is that the incentives of the people selling you tokens aren't really aligned with yours. You're here for a reason. You're you're you're So you're doing things for a reason. You're trying to make your customers' lives better, make your product better, delight your customers. They want to sell you more tokens. And you might be happy to pay for as many tokens as it takes, but you don't want to pay for more than that. And so again, kind of being able to switch between things lets you stay in control of all of that. And so, um you know, as I go through the talk, I'll mention a couple of places where our product makes it easy for us, but whether you use us or not, I'm just going to leave things with you that I think are really important um for you to be able to work collaboratively effectively. So, the next one is to turn every human interface into an agent and human interface. So, you know, typically when people are working with coding agents, they're on their laptop, kind of stuck on that laptop. Nobody else can talk to that agent. So, the first place people go to kind of expose more interfaces for them is Slack. Cloud has a Slack bot. Coda has a Slack bot. We have a Slack bot. It's really cool. You can say, "Hey, Coda bot, do XYZ." It does it. Somebody else can talk to it. But it's not enough. Cuz now we've taken it from trapped on somebody's laptop to kind of trapped in Slack. And a lot of work happened in Slack, so that's better than than than nothing, but certainly not all work happens in Slack. So, what we really wanted was to be able to work with the same session from every relevant interface. Could be Slack, could be our app, could be GitHub, could be elsewhere. And so, one possible flow is you start and collaborate on a session in Slack. And then maybe you continue in a kind of more engineer-focused environment in the desktop app or the mobile app. And then, you can finish it up in GitHub. And the important thing here is the exact same agent session. So, it's like the agent didn't forget what you did in one place in Slack when you go and talk to it from GitHub, it's the same session. It's got the same context. And the second lesson builds on top of that, which is to make the agent work visible and collaborative across the team. And so, obviously Slack makes it more collaborative. Um But here, we've got that kind of app view. And you know, Sergey made this ticket. I've been talking to the same ticket. Our growth person hopped in as well. So, you can kind of see at the top here all the different people that interacted with this. So, I can see who's getting notified about this session, who's seen it. Um that's especially important when you have work triggered by non-technical people. Right? So, it's like, you know, our customer support person created a ticket. It's working really well. I want to understand like has this been vetted by an engineer or not? You can kind of see who's involved really easily. And then, if I'm reviewing something, I can just pop in and say like, "Hey, why did you do it this way?" And again, because it's the same agent session, I don't need to wait for Sergey to kind of get my notification on GitHub and respond to me. The answer to the question is almost certainly in this thread. I don't also don't want to read the entire thread. So, I can just ask ask the agent. Or how we most often kind of make the work visible is with artifacts. So, it doesn't matter where the work started or where it's finishing, the agent can show you the work it's doing as screenshot or video or other. And you can see it from everywhere. So, again, you don't have to worry about like, "Oh, where is that thing? I got to go to GitHub to see the image or got to go to Slack to see the image." It's just everywhere. Work is visible everywhere. Collaborate from anywhere. The third lesson \>\> \[clears throat\] \>\> um I'm going to talk about here is to turn every external signal into code that your team can quickly evaluate. And I I to show this live, but the Wi-Fi is not quite there. So, I'm going to show you something from yesterday. But, what do I mean by external signal? So, it could be Slack conversation, could be a meeting you have with a customer, an onboarding call, a sales call. Could be an internal team meeting, could be something from Sentry or bug tracker, a bug report from a customer, an email, feature request. And right now what's happening is like all that stuff is already exists. It's in all those different systems. People hook them together with MCPs. So, now your coding agent can check the email or check Notion or whatever it might be. But, like how do you how how does it know what to work on, right? It's like it's still kind of stuck everywhere. And so, like some humans are involved in like kind of taking stuff from one place and telling it solve email number 48 or ticket number 6,000. But, that's still a lot of coordination. And so, what we do is we we have several different ways to automatically ingest these signals, prioritize what to what to do with it and and kind of act on them. And my favorite one, the most fun one, is what we call our meeting bot. And so, I'm going to switch switch over to my browser here for a second. And uh Okay. So, we've got a booth at the expo and we had the meeting bot running all day yesterday. So, this is a 4-hour meeting of a Google Meet. You just kind of invite the bot to Meet or Zoom or Teams or whatever it might be. And it listens all day. And it created all sorts of stuff as it was listening. If it finds existing work, it'll link to it. All right? So, it's not going to just like create new work if it's something already working on. Some of this is, you know, people testing the meeting bot out and telling it to do some weird things, um or interesting things, or just creative ideas. But, a lot of it's actually just like really good ideas that come out of people looking at what we're doing, asking questions, having new ideas of what to do with it. And so, it's kind of nice cuz the last idea that was here was someone saying, "Hey, like when I work with coding agents, I want to make sure that the agent has clear criteria to evaluate whether it did a good job on the work before it tells me that it's done. And um so they had that idea, the bot just picked up on it. None of us did anything manually. It created this ticket and started working on it. And then I was able to just say, "Hey, take a screenshot of what what you did." And here's that screenshot. And it kind of modified our ticket form to add these two new fields of acceptance criteria. Now, I'm going to Am I going to ship this one exactly how it is? Like, no, probably not. But it's a new idea, it's concrete, I can play with it, I can go and actually like use the live preview and like see if this improves performance. And so it takes like this you know, you know, your hundreds or thousands of ideas that are everywhere and it helps you kind of move with the speed of what your customers are asking you for and what they're thinking. And um it's really fun because every time we have an onboarding your customer call or or team meeting, we almost always have dozens of new ideas that are prototyped, but more importantly, at least a few shippable PRs with a very minimal intervention. So we talk, stuff comes out, we look at it, we ship it. It's so much fun. Put this back. So the next thing I'm going to mention is that, you know, the these three things that I've talked to you about really rely on having your workflow, your code base, your project set up to work in an isolated cloud environment. So that way the agents aren't trapped on an individual's machine. So there's several reasons why this is important. So the first one is to eliminate what some people are calling lid anxiety. You want to be able to close your laptop. You've probably seen people running around the office with their laptops open while stuff is working or at the airport or you know, there's some posts on Twitter or whatever about um you know, like people having their laptop tethered to their phone in their cars as they're driving home. This was actually probably the impetus for for me and for a few people on our team to even start working on this. You You last year I started working on Cloud code with cloud code a lot. I had a I think at the time like 6-month-old. I like didn't want to like be tied to my laptop or have that stress. I was like, I I don't I I don't ever want to think about whether I can like step away from a laptop or not. And so, we moved everything to the cloud. Things are working always. It eliminated that problem for us that people have been talking about for the past year. It's really helpful. It's important to me. But I don't think that's the most important reason to do this. I think the most important reason to do this actually was was touched on in the previous talk, if you were here for it. I think you should only give your access give your agents access to only what they need. Right? So, if you think about what's happening, you have a bunch of developers with these agents running on their laptop. Their laptops, unless you have like impeccable hygiene, probably have a bunch of stuff on it that you don't want the LLMs or agents to have access to. And yeah, like everybody's working on these sandboxes and approval flows. And so, you but but but really you're in one of two camps. You're either approving a bunch of stuff or you're hoping that your auto approval flow or your YOLO mode or whatever is configured properly and your sandbox is configured properly and doesn't read a bunch of stuff on your laptop that it shouldn't have. And, you know, as as the previous talk mentioned, like these agents are getting more autonomous. They're getting really resourceful. They They're trying to please you and do what you said. And so, when you say, "Hey, you know, wipe this agent database." and it finds a token on your laptop that it can use and it thinks it's working with staging, but actually it's production and now it just deleted everything. I'm not trying to say this is happening constantly, but it still happens. And for us, the peace of mind of just like letting anybody run with these experiments and ideas and prototypes and and and real code without having to worry about this is is is is really worthwhile. To go one step further on that, um it's not just, "Hey, make sure they don't have the credentials that they shouldn't have." It's also make sure they can't exfiltrate your code or your projects or your secrets or your content to somewhere they shouldn't be able to. And so you have a configurable network sandbox and you say, "Look, these are the places you're allowed to access, these are the ones you can't access." And anytime it tries to access something that it shouldn't, it just pops up and says, "Hey, tried to access something. Do you want to give it access? Maybe you're trying to integrate a new vendor and you need documentation." And you can do it on a per ticket basis or for the whole project. And so again, that peace of mind of like people can do things. If they need new access, it's easy to grant it. And um we're not going to leak a bunch of important data uh by uh running agents in yellow mode. And the last thing I'll mention about that is that this is the key for allowing your non-technical team members to trigger real work. Right? Your non-technical people don't have development environments set up on their computers. But we've gotten our support people or growth people to actually be meaningfully impacting the product by just talking to the users, seeing bugs, experiencing themselves, and just go to Slack or the rabbit cell and say, "Hey, fix this." They fix it. Screenshots are shown. Engineer gets it, gets merged. Without that, they'd have to put it in linear and linear would eventually pick it up and a PM would triage it or whatever. None of that here. You just ask for it and it's done. Now, the reason people didn't do this you know, up until somewhat recently, like this was really painful. Getting your full thing set up in this like kind of sandbox environment used to be really, really painful. But agents have gotten better. We have our own environment setup assistant that kind of takes your project and gets it to work in one of these sandboxes. But honestly, whether you use this or not, I highly recommend you get your project working this way and you can just get Cloud Coder or CodeX to do this for you. You don't have to use us, but you know, we think it's the best way. And the last lesson is to benchmark agents on your code base. So, um the way we do this, we select pull requests that represent great engineering work. It could be agent created, could be human created, could be a hybrid, doesn't matter. You pick the agents you want to use and benchmark. And then you get a quality versus cost and time breakdown on your code base. Now, why do you want to do this? There's There's many reasons, but one is that if you're kind of going off the public benchmarks, we bench or terminal bench or other stuff like those tasks may have absolutely nothing to do with your task. Like swe bench is all in Python, we're Ruby on Rails. It is not the case that the benchmarks are identical for them. There's trends that do compare, but the results can be very, very different. And I'm going to swap over to my browser one more time here. So, this is These are results on our code base of all these different harnesses. This one here is quality versus cost. This one here is quality versus time. I'll start with this one. You can see some trends here. Right, you can see that the Anthropic agents have just been consistently getting better, but not really any faster. The Codex agents and cursor are actually pretty fast and quite good. The open stuff has been getting better and better over time, but they're kind of slow. This is for our code base again. I'm not trying to make any general claims here. By cost, the Anthropic stuff is clearly just so much more expensive for us. And the Codex stuff has been cheaper for us. And so this causes us to change our behavior. We still use the different models. There's different use cases for them. We like the variety. We still use all these things. But when we saw these results, they kind of matched our vibe check. We wanted to kind of like have hard data, too. We switched our default to Codex at that time. And Fiable came out, and it was great. Kind of switched our default to that for like the few days we had it, and then it went away and switched back to Codex. But the most important thing is like because we're agnostic, like none of that had any meaningful disruption on our work. Like we're able to just kind of switch back and forth really easily. So, the next day something new comes out, see if it's good, and go. And the last thing I want to mention around that is like I don't know if this resonates with you all, but I have a lot of friends that like, "Okay, and I heard MiniMax is good. I heard, you know, GLM is good, and Kimmy K2 is good, but like haven't had the time to try it out, and everyone keeps telling me I need to cuz it's so much better and faster and cheaper." And you kind of have that anxiety for a little while, and then like finally you take the two hours to try it, and it's like, "Oh, actually like didn't really work for us. So, like what's, you know, I just wasted those two hours." It kind of eliminates that. It helps you kind of stay on the cutting edge really like seamlessly. Let me go back. So, what that kind of turned into us for us is, you know, essentially 100% like 99.9% of our pull requests are like heavily agent generated. We know that quality and reliability and security are really important, so we still have humans look at everything. We have agents help with it all, but everything's human reviewed. Um you know, for our our our our relatively small team, we had 1 and 1/2 billion tokens over the past month. And you can kind of see what we're saying about Claude here. It's a little small, so I apologize, but we had 3,300 Claude code runs that cost $10,000 in tokens daily. We have plans, so we didn't spend $10,000 on it. And Codex had four times as many sessions, and it was cheaper overall. And so again, the vast majority of our work currently is merged through Codex. We still use the other models. More and more is happening through GLM 5.2. Going to invest in that. And the one thing that we're really excited to do going forward with this benchmarking is automatically like like you've probably heard about people, you know, routing tasks to the right models and all that, but how do how does like some third party know what to route for your code base? Like this is a way that you can know what's going to work best for which task for your for your project, and we're going to kind of automatically routing that for you. So, I'm going to leave you with a few recommendations. So, first, um get your code base and agents working in a sandbox. It unlocks a lot of different things, a lot of different workflows, everything I've talked about and more. Second, integrate agents into the relevant human interfaces so your team and your agents can work together and don't have to like context switch and copy context back and forth. Obviously, we think Superagent is the best way to do it, but plenty of people are home rolling things, hacking things together. Figure out how to make this happen because if not, the friction is just really high. And lastly, find a way to benchmark and become model agnostic so you're not tied to anybody and you can just constantly stay at that right part on the frontier of cost, speed, quality. So, thank you so much. Um, we've got a booth in the expo. Please feel free to come by. You can sign up at superagent.com or you can email me with any questions at arjun@superagent.com. Um, I will be out in the back as well for any questions. Thanks so much. \>\> \[applause\] \>\> One one one last thing, um, if, uh, you know, at the booth we're mentioning we're giving away a MacBook Neo. If you were here cuz you signed up through for that, just meet us outside and we will announce the winner. Thank you.