Microsoft’s Vision for an Internet Made for Agents With CTO Kevin Scott (Best of the Pod)
Description
In 2025, Kevin Scott bet that the agentic web would be the next big thing in AI. The Microsoft CTO argued that for agents to be genuinely useful, they'd need to be able to take action on our behalf—which would mean giving them access to the same sprawl of tools, data, and systems that make up the internet. Today, that bet is starting to pay off, as the foundational infrastructure for the agentic web is now being built. On this week's AI & I, Dan Shipper revisits his conversation with Kevin. They discuss Microsoft's role in the agentic web, why openness doesn't have to come at the expense of security, and why programmers should stay curious about new tools rather than resist them on principle. If you found this episode interesting, please like, subscribe, comment, and share! To hear more from Dan Shipper: Subscribe to Every: https://every.to/subscribe Follow him on X: https://twitter.com/danshipper Go to https://attio.com/every and get 15% off your first year. Timestamps: 0:00 Start 1:44 Introduction 2:49 The race to close the "capability overhang" 4:31 How agents will evolve into practical, useful tools 6:48 The role Kevin sees Microsoft playing in the agent ecosystem 12:05 How robust security measures can coexist with open ecosystems 15:39 Kevin's philosophy on being a craftsman in the age of agents 20:52 How the landscape of software development agents will evolve 25:33 The future of agentic workflows Links to resources mentioned in the episode: Kevin Scott on X: https://twitter.com/kevin_scott Model Context Protocol (MCP): https://modelcontextprotocol.io NLWeb: https://github.com/microsoft/NLWeb GitHub Copilot: https://github.com/features/copilot
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: Kevin Scott argues that AI capability now exceeds most product implementations, and the next critical layer is an open, secure “agentic web” that gives agents persistent memory, standardized access to tools and data, delegated identity, and permissioned ability to act.
- Why it matters: This is a platform-level view from Microsoft’s CTO on the emerging control plane for agents: MCP-like interoperability, enterprise authorization, and the transition from prompt-response assistants to long-running asynchronous workers.
- Best use: Use it to pressure-test agent architecture and platform strategy—especially protocol adoption, identity/entitlements, tool access, and which problems warrant specialized agents rather than generic infrastructure.
Executive Summary
Scott’s central argument is that the industry has moved past debating whether scaling laws will continue: model reasoning has advanced faster than product deployment, creating a “capability overhang.” The near-term bottleneck is not merely better models, but turning that capability into useful, trustworthy agents that remember context, use external tools, retrieve from diverse systems, and take real actions.
He frames the required infrastructure as an agentic analogue to the web. In this framing, MCP is analogous to HTTP: a deliberately simple, composable protocol for connecting agents to tools and information sources. NLWeb is presented as a moral equivalent to HTML. Microsoft’s goal is both practical—make its own agents more useful—and strategic: help establish an open platform layer rather than let every company’s agents be constrained by bespoke integrations and organizational silos.
Security is acknowledged as unfinished, particularly around MCP, but Scott rejects the premise that openness necessarily requires weaker security. His proposed direction centers on agent identity, acting-on-behalf-of delegation, scoped entitlements, explicit user consent for requested access, and administrator approval. He also sees agents themselves becoming active security monitors that can triangulate suspicious activity across communications and systems.
For software and product development, Scott expects a pluralistic ecosystem of agents rather than one dominant agent. Differentiation will come less from novel base infrastructure and more from a company’s unusually precise understanding of a user problem and its ability to assemble or tune available infrastructure around that problem. His one-year prediction is a shift from synchronous prompting to asynchronous delegation: users will ask agents to pursue multistep work across systems and return later for a decision or final action.
Key Takeaways
- Claim: The industry’s immediate challenge is closing a gap between model capability and what users can actually delegate to products, not proving that scaling laws still work. | Evidence: Scott says scaling laws have continued to hold year after year, while reasoning capabilities have become “a little bit ahead” of what products are using them to do; he labels this gap “capability overhang.” | Implication: Do not treat stronger models as the complete roadmap. The highest-leverage work is converting reasoning into dependable workflows, product surfaces, memory, integrations, and action systems.
- Claim: Useful agents require persistent/coherent memory and the ability to act across rich, diverse external systems. | Evidence: Scott describes current agents as largely transactional: memory can remain coherent during one task but may disappear before the next, limiting delegation of increasingly complex work. He says agents must use tools, change systems, and consult diverse information sources. | Implication: Agent systems should be designed around durable task state, context recovery, tool execution, and reliable cross-system coordination—not just a chat interface and a model call. | Caveat: The transcript does not specify a technical memory architecture or a resolution to the privacy, retention, and retrieval-quality problems that persistent memory creates.
- Claim: Open, simple, composable protocols are the foundation for an agentic web, and MCP is positioned as a key interoperability primitive. | Evidence: Scott compares MCP to HTTP and NLWeb to HTML, arguing that existing websites, APIs, and information sources need to be “plumbed through” so agents can interact with them. He emphasizes open-community activity and the need for protocols to reach ubiquity. | Implication: Favor standards-based tool and data interfaces over one-off agent integrations, while treating provider incentives and operational guarantees as first-class design requirements. | Caveat: Protocol adoption alone does not solve incentives, reliability, commercial terms, data quality, or authorization; Scott explicitly notes that providers need a viable business-model reason to participate.
- Claim: Standardizing internal agent access prevents organizations from exposing their org chart through fragmented integrations and duplicated implementation. | Evidence: Scott says he is pushing Microsoft’s internal systems to speak a standard protocol to every internal agent. He invokes Conway’s law—the tendency to “ship your org chart”—and calls the resulting inefficient, nonstandard agent-building pattern an engineering “horror show.” | Implication: Ken should establish a common agent/tool protocol, shared service contracts, and reusable identity/access layers before individual teams build incompatible agent stacks around their own systems.
- Claim: The right security direction for open agents is delegated identity plus scoped, inspectable permissions—not either a closed ecosystem or unrestricted access. | Evidence: Scott proposes that agents identify themselves as acting for a person, query which systems and entitlements a task requires, request those permissions from the user, and remain subject to administrator approval. He says this should be built openly on top of MCP. | Implication: Do not grant agents ambient credentials. Require task-scoped authorization planning, user approval, policy enforcement, auditable delegated identity, and admin-level controls before enabling consequential actions. | Caveat: Scott concedes he does not know the final security model and characterizes the work as relatively straightforward rather than easy. The interviewer specifically flags that MCP lacks some web-like protections such as same-origin policy.
- Claim: Agent markets will be diverse because the durable competitive advantage is product insight into a particular user problem, not necessarily proprietary agent infrastructure. | Evidence: Scott says the most interesting startups are not primarily differentiating through infrastructure; they understand a problem better than others, then pick up, modify, or tune infrastructure to solve it well. He expects many agents because developers value tool choice. | Implication: Focus investment and build decisions on proprietary workflow understanding, domain context, evaluation criteria, and distribution—not on assuming a generic agent stack itself is defensible.
- Claim: The important behavioral shift will be from synchronous prompt-response use to asynchronous, long-running delegation. | Evidence: Scott predicts users will increasingly say “go sort this out”; agents will make calls across systems, wait for actions to complete, integrate responses, iterate, and later return with a result or a point requiring human action. | Implication: Design agents as job systems with state, retries, checkpoints, observability, escalation paths, and human-in-the-loop decision boundaries rather than as instant-answer copilots. | Caveat: This mode increases the importance of recoverability, monitoring, approval gates, notifications, and clear handoff semantics, none of which are detailed in the interview.
Detailed Brief
Openness, security, and permissionless innovation
- Claims: Scott calls the closed-versus-open tradeoff a false dichotomy: open systems can retain robust security while preserving permissionless innovation.; He believes some existing intermediary layers impose gatekeeping without adding enough value to either the maker or the eventual user.; AI may improve security operations by continuously monitoring signals across a person’s communication channels and systems.
- Evidence: Scott uses a personal example: alerts showed someone changing two-factor-authentication settings on his wife’s account, so he verified via text rather than email in case the email account had been compromised.; He imagines a security agent that knows a user’s sharing preferences and risk posture, detects anomalous behavior, and triangulates whether it is legitimate through multiple resources.
- Caveats: An agent with broad visibility into communications and accounts creates its own concentration-of-privilege and privacy risks; the interview does not explain how that supervisory agent would itself be governed.; “Permissionless” distribution may increase innovation, but it also raises the burden on identity, provenance, consent, abuse prevention, and incident response.
- Implications: A security layer for agents should be designed as a policy and verification system, not only as a static access-control check.; Evaluate open agent ecosystems by whether they can support least privilege and accountable delegation, rather than by openness alone.
Craft, adoption, and the future developer workflow
- Claims: Scott treats resistance to coding agents as a recurring craft debate rather than a uniquely valid objection to AI.; He distinguishes cases where makers value the process itself from cases where they prioritize the outcome and should use the most effective available tool.; His practical advice is experimentation: be curious, try new tools, retain them only where they improve the work.
- Evidence: He compares coding-agent objections with woodworking debates over hand tools versus power tools and CNC equipment.; Despite Microsoft making Visual Studio Code, Scott says he still uses Vim, knowingly accepting a potentially suboptimal choice because personal tool choice matters.; He delayed learning 3D printing and later regretted it because it became broadly useful across his work.
- Caveats: The interview offers a philosophy of adoption rather than a framework for code quality, review practices, liability, or how teams should measure whether agent assistance is genuinely improving delivery.
- Implications: Allow heterogeneous developer tools where possible, but set outcome-based engineering standards that are independent of whether work was produced manually or with agents.; Avoid waiting for perfect capability or cost curves before piloting; the larger strategic risk, in Scott’s view, is falling behind through inaction.
Notable Concepts & Terms
- Capability overhang: Scott’s term for the gap between what current models can reason about and what product teams have successfully packaged into useful user-facing capabilities.
- Agentic web: An interoperable ecosystem in which agents can discover, access, and act through websites, APIs, tools, and information sources using shared protocols and aligned incentives.
- MCP: Presented as a simple open protocol with a role analogous to HTTP: connecting agents to tools and external systems.
- NLWeb: Presented as a moral equivalent of HTML for the agentic web, helping expose web content or services in a form agents can use.
- Conway’s law: The tendency for system architecture to mirror organizational communication structure; Scott uses it to argue for standardized internal agent interfaces instead of team-specific integration silos.
- Delegated identity and entitlements: The proposed basis for agent security: an agent declares whom it represents, identifies the resources needed for a task, obtains permissions, and operates under user and administrator policy.
- Asynchronous agent: An agent that undertakes a multistep task over meaningful elapsed time, interacts with outside systems, iterates, and returns later for human review or final action.
Operator Notes / Why Ken Should Care
- Define a standard internal contract for agent-to-tool and agent-to-data access; prohibit new agent projects from creating unmanaged bespoke connectors where a shared protocol can be used.
- Implement an authorization-plan step before tool execution: enumerate requested systems, scopes, purpose, delegated principal, expiration, and required approval.
- Prioritize one asynchronous agent workflow with a clear business outcome, then require job state, logs, retry behavior, failure escalation, approval checkpoints, and a human handoff before expanding autonomy.
- Create an evaluation rubric for specialized agent opportunities: unique workflow insight, proprietary context, measurable user outcome, integration feasibility, and required permission surface.
- Monitor MCP security standards and enterprise identity extensions rather than assuming present-day protocol simplicity is sufficient for high-consequence actions.
- Run adoption pilots now on problems that are valuable but reversible; do not use marginal current cost or imperfect capability as the sole reason to defer learning.
Source/Metadata
- Title: Microsoft’s Vision for an Internet Made for Agents With CTO Kevin Scott (Best of the Pod)
- Transcript words: 5195
- Duration seconds: 1683
- Timestamp note: No timestamps or chapter markers were present. The transcript includes repeated passages and a duplicated promotional outro.
Transcript
You're someone who I think cares a lot about the craft of things. One of the knocks on using agents for coding is it gets rid of some of that feeling, or something like that. How do you feel about that? I love the fact that my people, makers writ large, software engineers or mechanical engineers or woodworkers or potters. If you are really passionate about what you do, you're going to have very strong opinions about how you do it. I've been a woodworker for almost as long as I've been a programmer. This is not the first moment in the past four decades where the nature of software development has changed in a non-trivial way. If agents are going to be useful, they have to take action on your behalf. They have to be able to use tools and make changes in systems and consult information sources that are diverse and rich. In order for that to really be great, you need an ecosystem that looks a lot like the internet. If you have a source of information, you already have a website, you already have an API that's doing something for people out there, you've got to figure out how to plumb things through where agents can talk to those things. One of the things, as CTO, that I've been pushing for at Microsoft is I want all of our systems internally to speak a standard protocol to all of the agents that we're writing inside of Microsoft. Be curious, try stuff. And if it works for you, use it. And if it doesn't, don't. Kevin, welcome to the show. Thanks for having me. One of the things that's interesting is I was here last year. Yep. And you said two things. There are two big themes. One was agents are going to be everywhere. That's one of the things you said, which I think really came true. That was very prescient. Another thing is I noticed a big emphasis last year on scaling laws. Yep. There are a lot of graphs of we're building big infrastructure, we're building these bigger models, and every two years we're going to get these big performance improvements. Yeah. This year the emphasis is really on the agentic web. Yep. So what has changed? What have we learned from last year to this year? Yeah, I think there's a bunch of things that have changed. One of the things is that I think last year people were really in this state of mind that they were doubting that the scaling laws were going to continue to work really well. Whereas I think we've demonstrated year after year after year that they are intact and working quite well. That's not a thing that people need to be reminded of anymore. And I think the other thing, too, that's happened, honestly, is that the reasoning capabilities of the models have actually gotten a little bit ahead of what we're using the models to do in products. So I've been talking a lot lately about this thing called the capability overhang. And I think we actually have some work to do collectively across the whole industry to close the gap between what the models are actually capable of and what we're delivering to users of that capability. So that's one of the big thematic things why scaling laws might not be as interesting to talk about at this year's Build as last. And then the other thing, too, is that what we've just discovered is all of these agents have emerged over the past year. And so both the number of agents and the amount of time that people are spending doing stuff inside of these agents or with these agents is that there's a bunch of other stuff, other than reasoning, that has to get sorted out in order to make them as useful as they should be. So the things that I was talking about at the keynote today at Build were we need better agentic memory. Our agents right now, because memory is constrained in a bunch of interesting ways, are a little bit transactional. So you use them for one thing, and memory is coherent across the course of that task. But then it may or may not completely go away, and you're starting from scratch the next time, which really inhibits your ability to delegate increasingly complicated tasks to these things. And then there's this real issue that if agents are going to be useful, they have to take action on your behalf. They have to be able to use tools and make changes in systems and consult information sources that are diverse and rich. And in order for that to really be great, you need an ecosystem that looks a lot like the internet, where if you have a source of information, you already have a website, you already have an API that's doing something for people out there. You've got to figure out how to plumb things through where agents can talk to those things and where all of the incentives are aligned for everyone to have all of this stuff participating in ways that make sense to them in this agentic web. And so I think that is the big story this year. It's like you've seen the first glimmers of real progress with super awesome, simple open protocols like MCP that are serving the same purpose in this agentic web as HTTP does on the internet, and where you have things like NLWeb that are serving the same moral-equivalent purpose as HTML does on the internet. And so I think you're going to see these things, simple things that are composable and layering, and lots of activity in the open community, and a bunch of things hopefully getting to ubiquity so that agents can actually do stuff. Right. So I think, to play that back, one of the things I hear is we have agents, agents are starting to work. And in order to make them powerful, agents need access. They need access to whatever is out on the internet, whatever is on your computer, all that kind of stuff. Yep. And you need protocols and processes for agents to be able to access that stuff. So you're looking at different parts of the stack. So absolutely the runtime layer where you're building memory and all this kind of stuff, and then MCP, which allows you to connect into the wider internet to get more information into agents. Yep. I guess why is that important to Microsoft, and what role do you want to play in that kind of an ecosystem? Well, look, I think there are two, maybe three things that are super important. So one is we make agents, and in order for our agents that we're building for folks to be useful, we need to solve these problems inside of these agents. And even if you scope it down narrowly to enterprise agents, one of the things, as CTO, that I've been pushing for at Microsoft is I want all of our systems internally to speak a standard protocol to all of the agents that we're writing inside of Microsoft, so that we're not exposing the entire world to Conway's law, which is organization. So Conway's law is a really funky thing in compilers where this guy Conway said that the number of stages or passes in your compiler is going to be dictated by the number of teams you have working on the compiler. You ship your org chart. Correct. You ship your org chart. And so you certainly, inside of the confines of a company like Microsoft, don't want to be shipping your org chart when you are building your agents. And it's just kind of a horror show to watch, as an engineer, all of this inefficient building when you don't have those standard protocols and services that everybody's using. But I think if you really imagine what agents could do and what users, not me, but people who are hoping these things can be more useful than they are right now, need, things need to start happening the same way that they were happening with the web. And I see it right now. MCP is a really great example. So it is a really simple protocol that solves a really important problem, not just for people who are making agents and building platform infrastructure, but for users of these systems who want them to be more useful, and for people who are providers who are like, hey, I want to be participating in this new agentic web. If people are doing less of one thing, which I knew how to connect to, and they're sitting here using these agents, how do I get my stuff wired up into this? And how does it make sense for me, even from a business model perspective, to do that? And so that's the two things. That's make our own agents more useful. And then we're a platform company. Even more important than the agents that we're going to write ourselves, that platform layer that Microsoft has been building in technology for 50 years, we just want to make sure that we are helping solve the problems that are emerging as this agentic web is happening. Yeah, it's really cool to see you guys leaning really hard into MCP and integrating it into all of Windows and all that kind of stuff. That's really awesome. How do I get my stuff wired up into this? And how does it make sense for me? Even from a business model perspective, to do that. And so, that's the two things that make our own agents more useful. And then we're a platform company. Even more important than the agents that we're going to write ourselves, that platform layer that Microsoft has been building in technology for 50 years. We just want to make sure that we are helping solve the problems that are emerging as this agentic web is happening. Yeah, it's really cool to see you guys leaning really hard into MCP and integrating it into all of Windows and all that kind of stuff. That's really awesome. And it brings up for me, I've been starting to hear rumblings from people who are thinking a lot about MCP that the security model needs a lot of work. Yeah. And I'm curious for your take on that, because you're making a lot of comparisons between this stack and the internet stack. And the internet has a bunch of things in its security model, like the same-origin policy, that makes sure that if a website is serving you code, it's only able to execute on its own data. And MCP doesn't really have that. So how do you, what do you think the right security model is for this? Well, look, I don't know that I know exactly what the right security model is. But the interesting thing about MCP is it is so coherently simple that it's going to be relatively easy for the community to decide what the security model is. We have a bunch of enterprise things that we care a lot about and that we're doing really good work with the MCP team to get done. And so we need agents to have identities so that you can build entitlement systems. So you can say this agent is acting on behalf of this person, and they are entitled to see these resources in this system. And even having a way for an agent to go query a bunch of systems and say, these are the things that I would like to do. These are the systems I need to touch in order to do the thing. What entitlements do I need to ask for in order to do this? And so I can request permission from the user, the person who's delegated this task to me. Can I present to them, can I have permission to these things in order to do this thing you asked me to do? Yes or no. And then for the administrators of all of these systems, is it OK for all of this to be happening? And so all of that's going to be relatively straightforward to do. Not easy, but relatively straightforward to do on top of MCP. And the important thing is let's do it in an open way. We don't need it to be proprietary to our agents or our systems. We've just got to figure out how to get this done, where things kind of work like the web works. Yeah. Well, it's an interesting question for me because I feel like there's maybe two potential models, or potential go-to-markets, for AI stuff that you guys have been talking about. One is this sort of verticalized model where you own the model and you own the UI layer. You do all the applications and everything in between. And the thing about that model, which maybe you could say that the App Store or Apple iPhone model is a good example of, is you can guarantee security in a lot of ways. In an open model, it's harder to do security stuff, but you get much more innovation because there's no central authority. So how did you guys think about making that decision? Yeah. So look, I know that that's the argument that a lot of people make. Yeah. I think it might be a false dichotomy. There is a thing that you have in these open systems where they are permissionless. Yeah. And there's a real advantage in having permissionless innovation. So the thing that, as an individual, excites me most about what's happening right now is the extent to which you can go innovate and build things without having to seek someone's permission. Yeah. Where you have to have them grant you permission for distributing your things to other people and having all of these complicated gatekeeping things that are sitting in between you, who are the person who had the idea, and the people who might benefit from it. I think some of these middle layers that have emerged over the past handful of years just aren't contributing much value, honestly, to the two parties in the transaction that matter, which is the person who did the hard work to make a thing, and then the people who are going to either spend their attention or their money or some other currency that's valuable to access the thing. So I get excited about that. And so that's one of the reasons why we've made the decisions that we want to. But I also think that there are ways that you can get real robust security in these systems, leveraging some of the AI capability that you have now, where you may be able to have better security. If you have an agent that you are running that is attending to your personal security requirements, these are things I'm willing to share, these are things I'm not willing to share, and that has some kind of knowledge of risk assessment. And yeah, for instance, my wife this morning, while I was getting ready to jump on stage, I got this flurry of emails because I'm the backup security account for my wife, where somebody was fiddling around with two-factor authentication on her account. And the first thing I did was I texted her. I didn't want to email her because somebody might have gained unauthorized access to her email account. I texted her. I was like, hey, are you screwing around with the configuration? And she's like, yes. And so you could imagine having an agent that is privy to a whole bunch of your communication modalities, being able to notice that something funky is going on and then using a bunch of resources to triangulate whether that's legit activity or illegitimate activity. So I think there's just a bunch of stuff like that, that you can have both. I don't think it needs to be one or the other as you framed it. Yeah, that makes sense. One other thing that I'm curious about is, it just seems pretty clear that software engineering is changing. Yeah. And you're someone who's been involved in software engineering for a long time. You're someone who also, I think, cares a lot about the craft of things, the craft of how things are made. We were talking earlier about how you do a lot of ceramics, you make your own bags, you love having your hands in things. Yeah. And I think one of the knocks on using agents for coding is it gets rid of some of that feeling or something like that, which I don't necessarily agree with. But I'm curious, for you, as someone who cares about the craft of code, looking into this future of coding with agents, how do you feel about that? Well, let me start by saying that I love the fact that my people, and when I say my people, I mean makers writ large, so software engineers or mechanical engineers or woodworkers or potters or just pick your thing, where people are trying to create things from raw materials or nothing. If you are really passionate about what you do, you're going to have very strong opinions about how you do it, the tools that you use, the materials that you use, how things get put together. It is a necessary thing for you to be great at your job. The interesting thing is people have lots and lots of different opinions. And one of the events, you said I've been doing it for a long time. I am. I'm an old fart. I wrote my first program when I was 12, which means I've been programming for 41 years. And so the thing that you get to see when you've been doing a thing for a very long time is this is not the first moment in the past four decades where the nature of software development has changed in a non-trivial way and where people have very strong opinions about the change and what it means. And so I think the reality is that people will have choice. I still, when I go into a text editor, I probably shouldn't say this because we make Visual Studio Code, I'm such an old recalcitrant fart that I still use VI. I use Vim at least. But my text editor of choice is this extremely antiquated thing. And I just refuse to go use something different, even though I know for sure that that is suboptimizing a part of what I'm doing. And so the thing that you get to see when you've been doing a thing for a very long time is this is not the first moment in the past four decades where the nature of software development has changed in a non-trivial way and where people have very strong opinions about the change and what it means. And so I think the reality is that people will have choice. I still, when I go into a text editor, I probably shouldn't say this because we make Visual Studio Code. I'm such an old recalcitrant fart that I still use VI. I use them at least. But my text editor of choice is this extremely antiquated thing, and I just refuse to go use something different, even though I know for sure that that is suboptimizing a part of what I'm doing. But I make the decision anyway because I get to choose. And then in other aspects of my making, either software or something else that I'm doing, I will be like, OK, the important thing here is not the way that I'm doing this particular part of it. It's the outcome that I'm trying to get to. And I'm going to use the most powerful or most convenient way to go get to the outcome, and I don't care who's going to throw rocks at me for doing it. And it's literally everywhere. I've been a woodworker for almost as long as I've been a programmer. And when I was a teenager, the big debate was, oh, are you a real woodworker if you use power tools? Real woodworkers only use hand tools. There's still a little bit of that debate today. But the real debate is, are you a real woodworker if you use CNC tools, computer-controlled power tools, versus just power tools? And I understand it. I actually think the debate itself is interesting. But sometimes people are going to make different choices because they value something different than you do. If you value the process more than you value the outcome, sometimes you'll make different decisions than people who value the outcome more than the process. And I think the, is it are you a real woodworker, a real programmer? You're saying you're only real if you do it the way I grew up doing it. And when you ask that question, in a lot of ways, you know. But it's just so varied, right? And so the thing that I will say is I would never in a million years tell anyone not to have strong opinions about their craft. Have them. It's great. The advice that I would give people, and this is not me telling, it's just advice, things that I found useful for myself, is just have an open mind. When the tools are changing, I can't even tell you the number of times where I have looked at a new technology in some other non-software dimension of making that came along where I'm like, I don't want to learn. 3D printers: I waited forever to learn how to use 3D printers, and I regret it. I should have started earlier. They're so damn useful for almost everything that I do. And for a whole variety of complicated reasons, I didn't let myself be curious about that, which is odd. And so just be curious, try stuff, and if it works for you, use it. And if it doesn't, don't. Yeah. What do you think is the future of software engineering agents? Is there going to be one agent to rule them all, or are you just going to use many different agents with different tastes, or how do you see that ecosystem shaping up? Yeah. Look, I think it's going to be a lot of different agents. I mean, it's good to have a lot of agents, and we certainly, with GitHub Copilot and the GitHub agent stuff that we're working on, I think we will compete very hard to be a tool that lots of people will choose because it's very useful to them. But I think it's unrealistic in the universe of developers to think that every developer on the planet is going to snap to using one tool for an important part of their job. Part of the joy of being a developer is you actually have that choice, and you can choose and play around with a bunch of different things and do irrational things and do rational things. And it's just one of the very consistent things that I've seen over the past four decades of my programming life, that people choose to change their tools all the time. What are the dimensions? Do you have an opinion on the dimensions along which the different agents might differ? Well, I think the most important thing about agents is probably the product-making part of them. And so the most interesting startups that I'm seeing right now are not trying to innovate by building some kind of differentiated infrastructure. They're innovating because they think they have an understanding of a problem that someone has that is better than anyone else. And they think that they can pick up infrastructure or modify infrastructure or tune infrastructure to go solve their understanding of that problem in a world-class way. So I think that's what we need a lot of right now, and that's what's going to dictate the diversity of agents and which things get used for what. And I think honestly, because it's so much easier now to have that nuanced understanding of what someone's problem is and to pick up these tools to go take a swing at solving it, you're just going to have a lot of companies building a lot of things. You can even see it with the software development tools. It's crazy how many things have come out over the past year, and they're interesting, all of them. Yeah. Yeah. Yeah. It's a lot to respond to when you're a company building software development tools yourself, but it's super, super interesting. And what we've seen is if you've got some kind of nuanced understanding of what someone needs, people have high tolerance and high interest in giving things a try. Yeah. Yeah. So we're almost out of time, but I'm curious. Let's say it's a year from now. We're back at Build. Yep. What are some things that are a hot topic right now or big questions that people have right now that are not going to matter in a year, and what is going to matter in a year? And what are your predictions for what we're going to be talking about? Yeah. I think people who are still hanging on to these ideas that, oh, the technology is not ready yet because I tried to do something and it was marginally too expensive or it was marginally capable of doing the thing that I wanted to do, I think anyone who is using those as excuses to wait to get started are going to be super behind. Because everything's going to get cheaper and everything's going to get more capable every year. And I think this is actually not a hard sell in 2025. Yeah, it was this loud chorus of, oh, the progress is about to end and everything's going to stop and everybody's going to be super disappointed. I mean, there's still some people out there saying that, but I don't think folks are paying much attention to them anymore. Mostly because what do you win by paying attention to some crank who's saying the thing's about to stop? You're betting on failure, and the cost of betting on failure versus betting on optimism is a real big difference there. So yeah, I think we're going to see a ton of progress on the level of ambition of problems that people are tackling with agents. And then I think modalities that are going to be really different is, as this agentic web starts to get more complete, more plumbed out, and the models' reasoning and planning capability get better and better, you're going to start to get to the point where you're able to go from this synchronous mode of interaction with agents to asynchronous. Right now, most of what people do is they sit down, they've got a thing they want to do, they issue the prompts, and they wait until the thing comes back and do something with that response. And so I think by next year, you're going to see people using these agents to say, hey, go sort this out, and the agent is going to take a lot of time. And then I think modalities that are going to be really different are: as this agentic web starts to get more complete, more plumbed out, and the models' reasoning and planning capability get better and better. You're going to start to get to the point where you're able to go from this synchronous mode of interaction with agents to asynchronous. Right now, most of what people do is they sit down, they have a thing they want to do, they issue the prompts, and they wait until the thing comes back and do something with that response. And so I think by next year, you're going to see people using these agents to: "Hey, go sort this out." And the agent is going to take a lot of time. It's going to go make a lot of calls out to systems. The things that it's taking action on are going to take a while to come back. Then they're going to integrate all of those responses and do something. And that whole thing may iterate a bunch of times. And then, at some non-trivial amount of time later, you're going to say, "Okay, here's the, here's the, here's as far as I got. Now it's your turn. Go take some action now." Sounds like a future I want to be in. Yeah. Yeah. Me too. Right. Well, Kevin, thank you so much. It was really great, really great to talk to you. Yeah. Good to talk to you as well. Thank you for having me on. Of course. Oh my gosh, folks. You absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about chat GPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat craving for more. It's not just a show. It's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor. Hit like, smash subscribe, and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you. Dan Shipperstein Fancy. That's how you know it's the real deal. Yeah. Excellent. So congratulations. congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations Yeah. Good to talk to you as well. Thank you for having me on. Of course. Oh my gosh, folks. You absolutely positively have to smash that like button and subscribe to AI and I why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about chat GPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat craving for more. It's not just a show. It's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor. Hit like, smash subscribe, and strap in for the ride of your life. And now without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you. Dan Shipperstein Fancy. That's how you know it's the real deal. Yeah. Excellent. So congratulations. congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations congratulations