AGI Inc. is a research lab building on-device models that allow AI to autonomously interact with millions of third-party mobile applications.
Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host, Ryan Donovan, and today we are talking about what it takes to engineer agentic processes, tool use, and on-device AI on mobile. My guest is Div Garg, founder of AGI Inc. Welcome to the show.
Div Garg: Hi. Great to be here.
Ryan: Before we get into the topic of the day, tell us a little bit about how you got into software and technology.
Div: Yeah. I’ve always been fascinated by software. I was around nine years old. We used to have a bunch of PCs in my house. I was always tinkering around, seeing what you could build. I was always fascinated — what is this box, and how can it do all these things? This was in India. Then I did a lot of stuff with international Olympiads and came to the US when I was 16. I was doing a lot of work in physics at the time — International Physics Olympiad — and I thought I’d become a theoretical physicist. I was actually thinking, okay, I should try to get the Nobel medal in physics or something. (Laughs)
Ryan: Yeah.
Div: And then it kind of hit me that one of the biggest things that’s going to happen in my lifetime is AI. I said, as soon as you have artificial intelligence and all these things are working, that is the next evolution of computers and where things are going. It’ll be very fascinating to work on that. So that’s actually what got me into computer science for my undergrad. I said, okay, this is happening and I should go study it. That’s what made me a CS major. Eventually I ended up joining Stanford’s PhD program, focusing on AI and agents.
Ryan: Nice. Obviously with AI it’s branched out into agents. Ever since the announcements around computer use, everybody’s been thinking about how these agents can run on their computers. But today we’re talking about running AI on a mobile device — entirely on the mobile device. Is that right?
Div: Yeah. Our goal is — imagine you could replace your whole computer with a phone. Theoretically that’s possible because all the compute is already there. Phones now have almost infinite memory and disk space. The question is just, how do you make your phone useful enough that all your work can be done from it? And can you have a smart enough AI to do this?
Ryan: And I think that’s the thing. Anytime you talk about programming devices, there are a lot of constraints, especially when it comes to AI, where even on desktop you normally have a hop to the cloud. How are you thinking about getting the AI to live entirely on the device?
Div: That’s where we’re doing a lot of innovative work as a company. Fundamentally, we are a research lab, and a lot of our work is around on-device models. We have the world’s best models that can run on a device to take actions for you, and they work across any third-party apps. You can ask it: can you call me an Uber? Can you order me something on Amazon? Get food on DoorDash? It generalizes to anything. There are millions of apps out there, and our AI just works across everything.
Ryan: “World’s best on-device model” is a big claim. So are you doing that by creating a specialized model that’s just doing tool-calling actions, that sort of thing?
Div: No, it’s more than that. It can actually mimic a human’s interaction. The industry term for this is computer use or mobile use. The AI has learned how to interact with the screen — touch, type, scroll. Whatever you can do on the phone, it can basically do the same thing as a human.
Ryan: What sort of model is that? Is that the transformer architecture that’s gotten all the press, or a more standard deep learning model?
Div: It’s a transformer-based architecture. And we do a lot of this work ourselves. In most of the industry, people are running on Nvidia hardware — V200s, V300s in the cloud, including Anthropic — and you can compile models to CUDA, which is the standard framework for running code on those GPUs. But when you’re working with mobile devices, you can’t use Nvidia because everything is powered by edge computing chips, largely Qualcomm or other providers. So we have to write all the kernel-level code ourselves. We’ve done a lot of innovation around how you make the compiled code for the model run very fast and efficiently on a mobile processor, and how you optimize for the available memory.
Ryan: Yeah, we’ve done some work with Qualcomm covering quantization as a big topic there. Are you both quantizing and programming directly on the Qualcomm chips?
Div: Yeah, we do both. Quantization is a big part of making the model smaller, and then you have to do a lot of compilation work on top of that. We actually just published a technical blog post that got a lot of views about our auto-compilation engine. We basically taught an AI agent how to write the best optimized code for a particular mobile chip — it can figure it out itself and self-optimize.
Ryan: Wow. What’s the training data for that? Are you writing the best optimized mobile code yourselves, or does Qualcomm provide something?
Div: We’re writing a lot of it ourselves. When you’re working with Qualcomm libraries, a lot of that is not really public. There aren’t enough standards or community resources around it, so a lot of it is something you have to figure out yourself — they have a lot of private APIs. Luckily we have a direct collaboration with Qualcomm, so we get some touchpoints. But we had to figure out a lot of the edge cases ourselves to make this really, really good.
Ryan: For the optimizations, if you’re teaching it to write highly optimized code on a mobile device, what are the specific optimizations you focus on?
Div: I’d say it’s broader than any single optimization. Suppose our agent wants to do something for you — say, book you an Uber to your office. That’s something you could do yourself, but if the agent is doing it for you, you want it to be faster than a human. So a lot of it comes down to how do you beat people on speed? The model has to be small enough and the code has to be efficient enough to achieve that speed performance. That’s one major area — getting the best speeds possible. We’re also number one in the industry when it comes to reliability. Our agents reached an accuracy of 97.4% on one of the most recognized leaderboards in the space, called Android World. This is what everyone in the space uses for evaluating Android-based agents, and it’s been a big validation of our approach. We couldn’t have done it without writing all the kernel code ourselves.
Ryan: How do you verify that it’s both the most efficient code and that it produces accurate results?
Div: We have a bunch of testing suites we created internally. We actually built the first sandbox environment for these kinds of agents, way back in 2024. The New York Times wrote an article about us. It’s a public app called realevals.xyz, where we cloned the top ten websites on the internet — DoorDash, LinkedIn, Amazon. These look like real websites. We actually had a clone of United Airlines, and then United gave us a legal notice to take it down.
Ryan: (Laughs)
Div: Because it was just too realistic. (Laughs)
Ryan: And when you say clone, what do you mean exactly?
Div: We literally built a facsimile of the actual website. You obviously can’t book a real flight on it, but it’s very useful for training an agent.
Ryan: When you were training on these facsimiles, what did you find that your models and agents struggled with most? What tripped them up?
Div: There are obviously a lot of things, but one big area was how do you build safety and align with humans? For example, coming back to flights — if I say go book me a flight to Japan, that might be a thousand-dollar purchase. You don’t want it to automatically choose something and book it, then just tell you, hey, by the way, I got this flight. You want it to be more human-in-the-loop, where the agent surfaces options and confirms with you before taking irreversible or high-stakes actions. Designing that kind of graduated autonomy — knowing when to proceed and when to pause and check in — turned out to be one of the harder engineering and design challenges we faced.
