How AI changes the math for startups, according to a Microsoft VP

For 24 years, Microsoft’s Amanda Silver has been working to help developers — and in the last few years, that’s meant building tools for AI. After a long stretch on GitHub Copilot, Silver is now a corporate vice president at Microsoft’s CoreAI division, where she works on tools for deploying apps and agentic systems within enterprises. Her work is focused on the Foundry system inside Azure, which is designed as a unified AI portal for enterprises, giving her a close view of how companies are actually using these systems and where deployments end up falling short.

I spoke with Silver about the current capabilities of enterprise agents, and why she believes this is the biggest opportunity for startups since the public cloud.

This interview was edited for length and clarity.

So, your work focuses on Microsoft products for outside developers – often startups that aren’t otherwise focused on AI. How do you see AI impacting those companies?

I see this as being a watershed moment for startups as profound as the move to the public cloud. If you think about it, the cloud had a huge impact for startups because it meant that they no longer needed to have the real estate space to host their racks, and they didn’t need to spend as much money on the capital infusion of getting the hardware to be hosted in their labs and things like that. Everything became cheaper. Now agentic AI is going to kind of continue to reduce the overall cost of software operations again, because many of the jobs involved in standing up a new venture — whether it’s support people, legal investigations — a lot of it can be done faster and cheaper with AI agents. I think that’s going to lead to more ventures and more startups launching. And then we’re going to see higher-valuation startups with fewer people at the helm. And I think that that’s an exciting world. 

What does that look like in practice?

We are certainly seeing multi-step agents becoming very broadly used across all different kinds of coding tasks, right? Just as an example, one thing developers have to do to maintain a codebase is stay current with the latest versions of the libraries that it has a dependency on. You might have a dependency on an older version of the dot-net runtime or the Java SDK. And we can have these agentic systems reason over your entire codebase and bring it up to date much more easily, with maybe a 70 or 80% reduction of the time it takes. And it really has to be a deployed multi-step agent to do that.

Live-site operations is another one – if you think of maintaining a website or a service and something goes wrong, there’s a thud in the night, and somebody has to be on call to get woken up to go respond to the incident. We still do have people on call 24/7, just in case the service goes down. But it used to be a really loathed job because you’d get woken up fairly often for these minor incidents. And we’ve now built an genetic system to successfully diagnose and in many cases fully mitigate issues that come up in these live site operations so that humans don’t have to be woken up in the middle of the night and groggily go to their terminals and try to diagnose what’s going on. And that also helps us dramatically reduce the average time it takes for an incident to be resolved.

One of the other puzzles of this present moment is that agentic deployments haven’t happened quite as fast as we expected even six months ago. I’m curious why you think that is.

If you think about the people who are building agents, what is preventing them from being successful, in many cases, it comes down to not really knowing what the purpose of the agent should be. There’s a culture change that has to happen in how people build these systems. What is the business use case that they are trying to solve for? What are they trying to achieve? You need to be very clear-eyed about what the definition of success is for this agent. And you need to think, what is the data that I’m giving to the agent so that it can reason over how to go accomplish this particular task?

We see those things as the bigger stumbling blocks, more than the general uncertainty of letting agents get deployed. Anybody who goes and looks at these systems sees the return on investment.

You mention the general uncertainty, which I think feels like a big blocker from the outside. Why do you see it as less of a problem in practice?

First of all, I think that it’s going to be very common that agentic systems have human-in-the-loop scenarios. Think about something like a package return. It used to be that you would have a workflow for the return processing that was 90% automated and 10% human intervention, where somebody would have to go look at the package and have to make a judgment call as to how damaged the package was before they would decide to accept the return. 

That’s a perfect example where actually now the computer vision models are getting so good that in many cases, we don’t need to have as much human oversight over inspecting the package and making that determination. There will still be some cases that are borderline, where maybe the computer vision is not yet good enough to make a call, and maybe there’s an escalation. It’s kind of like, how often do you need to call in the manager? 

There are some things that will always need some kind of human oversight, because they’re such critical operations. Think about incurring a contractual legal obligation, or deploying code into a production codebase that could potentially affect the reliability of your systems. But even then, there’s the question of how far we could get in automating the rest of the process.