Block CTO Dhanji Prasanna: Building the AI-First Enterprise with Goose, their Open Source Agent

Our approach has been to not over engineer it. So we like to let Goose learn from doing things. So we also have this feature called recipes where if you try a workflow with Goose and you really like it, you can bake it into a sort of script or what we call a recipe and then share it out with your with your teammates. We find that Goose is more capable than if you tried to figure out how to make a tool Goose friendly. So it figures things out in surprising ways that you wouldn't think of as a human and it does it quicker than you might do it as well, which is quite surprising.

Today on training data, we're joined by Block CTO Dhanji Prasanna. Earlier this year Block released Goose, which is an open source extensible agent that can do work on your computer for you. Goose is used widely for everything from Jack Dorsey's first rev of Bitchat to non engineers vibe coding side projects to the Goose team actually writing the vast majority of net new code for the Goose code base itself. Talk about recursion. In this episode, Dhanji unpacks for us the role of tool use, MCP and agent middleware in enabling AI to really have an impact and gives us a peek into how AI is transforming Block both as a product and as a company. Enjoy the show.

Well, we're delighted to have you here today, Danji, who's the CTO at Block.

Thank you for having me. First of all, I have a thought.

Provoking question to get us going. There's a lot of talk about the disruption that AI is going to cause. We at Block primarily focus on providing financial services and software to consumers and to businesses, largely small medium sized enterprises. And there's a lot of talk about how AI might completely disrupt that, that you wouldn't need a company like Block to exist anymore. So my question to you is, is AI friend or is AI faux?

Well, I have two answers to that. First of all, I think like any new technology, you can think of nuclear energy as an analog. It really depends on who is developing it and to what purpose they're putting it. So nuclear medicine saves lives. Nuclear energy can be revolutionary for us, but if you build bombs with it, it's terrible. So, so I think AI is very similar in that regard. Like it has a lot of potential to do a lot of good. We've already seen that with AlphaFold and all of the great things similar to that. But it can also be used for some nefarious things. So I think that's one that's my Answer to friend or foe. It really depends on who's holding it and what their purpose is.

But I was thinking about it specifically for us at Block.

Yeah.

Is it going to enable disruptors to usurp our position or can we at Blockchain successfully wield AI to strengthen our business?

Yeah, I mean, I obviously believe that it's going to be good for us. I've always thought of Block not as a financial services company, but as a technology company. So we've always been early to embrace whatever new technology there is and then figure out how best to serve our customers with it. So I don't see it as a threat. I mean, it's only a threat if we're asleep at the wheel and not doing the things that we're used to doing. So, yeah, going all the way back to the very first card reader that was powered by the velocity of the card going through the reader, which was incredibly clever innovation on the technology side all the way through all our work with Blockchain. And we've always embrace new technology, so I think it's really good for us. It's really good for our customers. We're already seeing the benefits there.

So you've been with block now for 10 years. You joined in January 2015.

That was my most recent stint, but I actually my first commit to the GitHub repo and block goes back to 2011, so.

Oh, I didn't realize that.

Yeah, yeah.

Oh, that's amazing. But you went a full time employee at the company?

I did a couple of stints and then I came back full time in 2011.

Oh, that's interesting. Okay, so I didn't have that full history. That's really interesting. So I've been involved with the company a little bit longer than you have. I joined the board at the end of 2010, so it's been a long time. So maybe for some of the listeners out there, it'd be useful to level set a little bit. What does Block do today? What is the full range of products and services? And as cto, you obviously have an incredibly wide view of all the activities at the company.

Yeah.

Just to help us understand what all the businesses we're involved with today that matter.

Sure, absolutely. Our two main pillars are Square and Cash App. So Square serves merchants and sellers and Cash App serves consumers as a financial services app and they're both growing as ecosystems. And then on top of that, we also have Tidal, which is our music streaming service. And we have a number of open source initiatives in addition to that. Including bitkey, which is a new initiative that helps you securely hold Bitcoin. And we just launched Rig, which is our mining hardware. So you can install mining rigs in your home and it runs bitcoin for you.

That seems unusual. Why are we doing bitcoin mining rigs?

Well, we had a thesis that we can build an incredibly powerful mining rig that competes with the best in the industry and is also energy and cost efficient. And I believe we've done that with Rig. So it's an impressive first attempt. But yeah, Jack, our founder, believes very strongly in Bitcoin and the power of making it everyday money. And this is one of our attempts to advance it.

You know, one of the secrets about the AI infra industry is that many of the top AI infrastructure vendors used to be crypto mining providers. Right. So I see an Act 2 for your crypto mining business.

Yeah, look, it's not gone unnoticed and we have talked about that and dual use sort of technology in that sense.

But no, we're focused on that specs though, right?

Yeah, I think it veers off the core mission as well, which Rig has done a great job at chasing. So we want to focus on that for now.

You mentioned that Jack has driven a lot of the kind of bitcoin focus at Block. I'm curious about who's driving the AI agenda at Block. It seems like you guys are doing so much on the AI side. Is that also a personal passion project of Jack's and. Or is it yours? Or is it everybody at the company?

Yeah, I mean, I would say Jack and I are pretty aligned on that one. So before I took on this role, I wrote a long email to Jack saying we really need to invest in AI and we need to do it centrally and we need to transform our whole company into doing it. And he 100% agreed and he flew out to Sydney and spent two days with me and we talked it through up and down. So I would say it's both of us being aligned and being in sync about what was necessary and how to push AI. And yeah, I think we've done a pretty good job of getting us off the ground. There's.

Yeah, we have a long history of implementing machine learning at the company.

Correct.

So how do you. How do you distinguish between what used to be called machine learning or what is now called AI and is it a ship versus a boat and there's a blurry line and you're not quite sure where it crosses over or how do you frame those two different concepts?

Yeah, I think that generative AI is the difference, right? It's. It's deep learning and the ability to do more than just classification or clustering or those common machine learning use cases that traditional ML was aimed at. And our use of ML at block was always on the risk side. So we would always focus on fraud, on spam and abuse and things like that. And I think we got really good at it. But when you start to look at what deep learning can do, you're opening up the world to so much more, to literally every single vertical and function that we have at the company and beyond. So that's where I draw the line. It's basically deep learning versus traditional ML.

What was on that email you sent Jack? What was the AI manifesto for how you become AI native?

I said, hire someone, not me, who can be CTO and get our company transformed to using AI because we're well behind the eight ball and we need to get ahead. And he sort of followed half of that advice and the other half he did end up hiring me.

No good deed goes unpunished. What were the other components of the manifesto? And I guess you mentioned it was kind of almost centrally driven to make the organization more AI first. Can you talk more about how you drove that?

Yeah, we did it sort of progressively. Initially, we invested in a number of special projects bets. So we had maybe two to five engineers working on eight different projects. And some of these projects were ideas that I had had. Some of the projects were things that we had already worked on or hack week ideas, things like that. And we funded them and pushed them along. And then progressively we started to unwind our GM structure, which was, I think, keeping a lot of the value of square and cash, app and title locked away within those silos. And we brought them all together and actually adding our platform teams to that, which were ironically separate from all of these, made it that much more powerful and gave us a really strong springboard. So as we sort of centralized each part of the company into a functional org structure, we drove engineering excellence, technical excellence, and we could unify policies. A lot of things just fell in. And the transformation, yeah, it's proceeding at pace now.

It's really interesting. At different points in time, organizational design serves different purposes. And there was a time where our GM structure seemed to have the right merits for the problems we needed to solve at the time. And it didn't in this case because centralization and the sort of functional organization is the way that we're succeeding right now.

Yeah, you're exactly right. It's like courses for courses, as they say. And I was part of the era when we spun out into a GM structure. So when we went from purely functional. So I was head of engineering for Cash App from when we were about 10 engineers to 200 plus. And I worked very closely with Brian, who was our Cash App CEO and Jack to help create this separation. And a lot of the reasoning behind that was giving Cash App the autonomy and the focus to go and build what it was after and not muddy the mission with what Square's mission was and, and keep that crystalline. As well. So, yeah, it's. And I think. But in this era where you need to go deep in technology and where seismic shifts in the industry are happening on a weekly basis, having this depth and singular focus, singular organizational focus, is really important. And Jack was a huge proponent of that view as well.

Have you had to embrace a different, almost product building mindset to build around LLMs and generative AI compared to how your developers are used to working?

Well, I would say there are a couple of different approaches that we've tried. There's no panacea to this. There's no sort of simple answer to getting AI into our workforce. We've tried the approach of here's every single AI tool there is, go ahead and use it, tell us what's working, what's not. And that has had some mixed success. Goose is used by the majority of the company now, but they also use several other AI tools, which I'm very happy to do. I think if we can't compete on Goose with those tools, then Goose isn't doing its job. So we're very happy to provide licenses to any other AI tool that people want to use. And I'd say that the other half of it is we use all of these systems which provide capabilities to the enterprise. So be it something as simple as issue tracking or Salesforce for customer management and everything in between, but using AI with those tools is something that has remained elusive until we started thinking about this holistically. And so we looked at Block not as here's an enterprise and here's some tools and here's our products and here's our business, but everything is a capability at Block. So whether it's the ability to take payments or move Bitcoin or buy stocks, whatever it is, issue invoices, listen to music on title, and we treated the corporate side like that too. So creating an issue, opening a pr, all of these are just capabilities. And then we put an agent middleware layer on top. So effectively, Goose and all our UIs are now evolving to talk to our capabilities through this agent layer. And that's unlocked an enormous amount of value. We're just at the beginning of that transition, so I expect it will continue to unlock a lot more utility over time.

You've used this word, goose. I don't know if all our listeners are familiar with this. It's not on the menu. It is a capability that we've built and we've open source. Tell us what it is.

Yeah, very simply, Goose is a general purpose AI agent. So it's a program that you can download and use on your laptop and it's got a ui, so you can either use it on the command line or in the ui. And it is built using what's known as the Model Context Protocol, or the mcp, which you might have heard of. And Goose was one of the earliest adopters of the mcp. And the MCP is just a fancy way of saying we're going to create a set of formalized wrappers for existing tools or capabilities and expose them to your AI agent. And Goose has been able to connect to all of our systems. So all of our existing systems, be it Gmail or Google Docs, be it Square, payments any of these things and orchestrate workflows between them completely on its own. So you give it a little prompt and say, I want a marketing report of how we did in Q3. And then it goes away, looks in Snowflake, pulls out the data, it might look in Looker, Tableau, any of these other systems, builds a bunch of charts using programming tools that it knows about, and then it can deliver all of that as a PDF or Google Doc and even email it for you. So this is a, kind of gives you a flavor of the orchestration capability of Goose. But other than that, it was one of the earliest AI agents, I believe, and certainly one of the leading open source agents. And we helped shape the mcp. In fact, we're on the initial announcement of the MCP as a early contributor to the protocol. And we've extended in a couple of ways and yeah, continue to see the benefits.

How did the project come to be and who built it? How long did it take to build? It's super cool what you've built.

Yeah, thank you. Well, when I took over as cto, I kind of rummaged in the back closet to see what all the cool ideas our engineers were cooking up. And Goose was one of them. There were about seven or eight others and they took different approaches. Goose was developed by One of our engineers, who. His name is Brad Axon and he had been developing this thesis that agents would be the future of how we realize utility from AI. And it turned out to be right. And we ring fenced him and gave him a team of six or seven people and they've really punched above their weight.

Why is it called Goose?

That's a Top Gun reference.

Okay, it is. I wasn't sure.

Yeah, Brad looks. He's a ringer for Goose, so.

Ah, okay. There's no resemblance.

There's a couple, yeah, a couple of angles. Yeah.

Well, it's a great story of how big companies can find talent and give them the space to flourish. I sometimes wonder that bigger companies are more at risk of infanticide than anything. They kill their own ideas. And instead I think Block has done an incredible job, whether it was Cashapp originally or now this, with Goose, giving that space to individuals to really run with ideas.

Yeah, that's exactly right. I think a lot of it comes down to Jack and the culture of experimentation that he promotes. A lot of us carry that same set of values. The reason I get up to come into work is to build something cool, build something that no one else has ever built before and realize some utility or some value from it that people have been struggling with for a long time. And there are a lot of engineers who are like that at our company. And so it's been an incredible journey to see that and just to have the freedom to ring fence and let these people go after crazy ideas. Not a lot of these work out. So like we've tried many, many more things than we've actually hit home runs with. But certainly cashapp and Goose are two big ones. I would add bitkey and Proto to that too. They started as very simple sort of experiments.

Is the way that people use Goose, is it almost like if you're using it in the command line, it's almost like a cloud code, and if you're using it in the application interface, it's almost a ChatGPT equivalent. Is that how I should think about how people get value out of it?

That's a reasonable analogy. I would say. Engineers tend to use the command line because that's what we're used to and we like working in. And it does do a lot more of the coding style of work on the command line better. Both workflows or both UIs are effectively the same underneath, so they both have access to the same MCPs, the same capabilities. It's just how they're surfaced. So some of our Users, especially our non technical people, are much more comfortable with a ui. And so that's why we have the ui, but they use it to build software too. And this is something that's been an incredible insight for us. You know, we, we never expected this, we never expected sort of our sales guy or our financial person to be writing software dashboards for themselves. But it turns out it's possible and it, it doesn't take long, it doesn't take much work to do. So that's been the reason why we have these two UIs. But at its core, Goose is very much about pushing autonomy. So we let the Agent loop run as far as it can, so if it stumbles, if it hits obstacles, it'll back up and it'll try another approach. And this is something that a lot of AI agents learn from us over time as well. And it turns out if you take that approach, you can build some fairly competent software without knowing anything about coding.

I think we'd love to get some examples both within engineering and outside of how it's used. But maybe since you asked that or probed that particular aspect, how do you secure it if it truly is autonomous? How do I know it's not writing emails that will embarrass me or accessing data? It shouldn't, you know, is there role based access control? How do you prevent it from deleting a bunch of stuff that it shouldn't?

So this is something that a lot of Goose users, early adopters, were quite worried about. And in my experience it's been that the worry is much greater than the reality of what happens. It turns out that Goose and the way it's structured. But LLMs, generally they're designed to be fairly cautious with tool use. But of course, beyond that, we have a laddered safety structure. So you can use Goose in a make me, you know, in the loop for everything mode. So it won't take any destructive action unless you say, okay and get to review it. Or once you get comfortable with it, you can push it to fully autonomous mode. And a lot of people start to see the value of how strong it is when they start to do that, and especially when they realize that before it does some destructive action, it will sort of let you know, even on its own, even when it's not in the safety mode, and give you a chance to say, hey, don't do that. You can also interrupt it at any time and say, take a different path. Which is an interesting way of using Goose that a lot of our engineers use. And finally, Goose acts as you. So it's not like a wild robot going off running into our data centers and doing its own thing. It follows the same access controls that each user has. And so it's blast radius is highly limited to any actions humans take or.

To that individual's authorization level.

Correct.

So if you're in sales, you're not going to have access to the financial information and vice versa, just to give an example. So it's a sort of, it's really a sidekick then for the individual.

That's the way the core Goose application or tool was developed. We've since spawned many other sort of Goose inspired tools or extensions to Goose, if you want to think of it that way, that do operate outside, you know, being on someone's laptop. So we have this really cool tool called Headless Goose and it runs for example in our CI pipeline. And every time there's a vulnerability ticket filed by Infosec, Headless Goose will go and try to fix that vulnerability automatically. But all our code follows very strict audit and review procedures. And so a human has to agree, read everything and be sure that this is the right fix before it enters any production environment.

Headless Goose is a great. You guys have too much fun.

Don't try to ask an AI to draw it for you. That's all I'll say.

What are some of the most common use cases that people are building with Goose?

So the most interesting thing that I've noticed has been non technical people finding creative uses for Goose. So everything from taking a figma and saying build this into a functioning site, to I saw someone who was taking a holiday in Paris who had Goose build her a map of all of the interesting sites in Paris and do a little traveling salesman walk for her to get through all of those sites. And this was just an app that, you know, she was able to consult while on her on her trip. So all of those things are great. But people have also built treasury dashboards, reporting tools that they can then one click share out to any of their colleagues and a whole host of things in between. Jack has built bitchat, which is a completely decentralized chat application, social networking application that runs on Bluetooth. So there have been some incredible things that people have done with Goose.

We were using Bitch yesterday. It's amazing. It was built on Goose.

Yeah, the initial version was built using Goose and I think he's since tried. There have been other contributions to it. So I'm not sure if it's all 100% goose now, but it's a Big part of it. We also use Goose to build Goose. So the vast majority of Goose's code is written by Goose, and so we almost fully bootstrapped it. There's still some human written code in there that's at a level of complexity that Goose hasn't reached yet. But our goal is for it to be completely autonomous and for each release, for it to rewrite itself 100% from scratch. But I'd love to share the craziest thing that I've seen someone build with Goose. It's a little hard to stomach, so you really have to be strong about this. So we have one engineer who's really into Goose and AI, and he's on our Goose team. And he has Goose watching literally everything he does, including Slack or Google Meet calls, everything in between, and it intervenes for him in really surprising ways. So he'll be talking with one of his colleagues about a new feature idea, and then a few hours later he'll see that Goose has already tried to develop this feature and open to PR for it. He's not asked it, he's not sat. Sat there sort of telling it anything. It's just taken the totality of his communications and understood that this is something he might want. It will sort of break him out of a flow. If he's late for a meeting and he needs some travel time to the office or something like that. If he communicates with a colleague or someone else and says, let's reschedule this, it'll do it automatically for him on the calendar. So there's a lot of wild things. You have to have the stomach for it. But these are the capabilities that are possible with AI agents.

Now, Goose under the Hood uses a variety of different underlying foundation models, is that right?

Correct. Yeah, we have a pluggable provider system, so we can essentially use any LLM that's capable of tool calling.

So should I think of Goose as a LLM tool? Tool use loop? Is that. Is that the foundational architecture?

I would look at Goose as the arms and legs. If you think of the LLM as a brain in a jar that's not capable of anything except chatting with you, Goose gives it arms and legs to go out and act in the real world. So it can take all of that thinking capability, all of that generative text capability, and apply it to real systems, digital systems that we use every day.

And are there any tips and tricks for how you've made your systems, I guess, primed to be usable by Goose? You know, if you just take your existing GitHub and Salesforce and kind of connect them over MCP to Goose. Is Goose just immediately able to, you know, use those tools effectively, or are there things that you do to make Goose more likely to be successful?

I would say that our approach has been to not over engineer it. So we like to let goos learn from doing things. So we also have this feature called recipes where if you try a workflow with Goose and you really like it, you can bake it into a sort of script or what we call a recipe, and then share it out with your with your teammates. We find that Goose is more capable than if you tried to figure out how to make a tool Goose friendly. So it figures things out in surprising ways that you wouldn't think of as a human.

Interesting.

And it does it quicker than you might do it as well, which is quite surprising. And with the rate at which LLMs are evolving, that capability is improving rapidly as well. So even if we did find something that we could build some engineering scaffolding around to make Goose more effective on some particular tool, the next release of the LLM provider might just blow that capability out of the water. It might just do that on its own.

That's so interesting.

Yeah, you have to stop thinking like an engineer. This is one thing that's been really hard for me to learn, but it's a worthwhile lesson and you have to start thinking more like a data scientist, for lack of a better term.

Yeah, that's so interesting. Are different of the LLMs better at tool use and figuring out how to use the tools than others?

Yeah, absolutely. The, the big LLM providers are all pretty good at tool calling and there's some variation within them, but they leapfrog each other regularly and they all have native tool calling support. The open source providers have no tool calling support, so they just generate text. Although some of them are fine tuned to be better at tool use. So we have this system called toolchim which basically adapts those LLMs to be able to use the MCP and that's been pretty effective for us to be able to enable open source LLM models.

Could you share the split of underlying model attribution of inference calls within Goose? Is that something you measure? Does it not matter?

We allow people to use whatever they want. So we have a gateway of, I don't know, 10 or 20 models that we support. And then Goose itself, particularly the open source Goose has got a lot more plugins to support open source providers. Things like Ollama and I just built one on the plane on the way here, which was using an embedded model provider, which is blindingly fast on our latest MacBooks. So there are a variety and people use different ones based on their area of need. So some people are very privacy conscious. They don't want a single token to leave their laptop. So they'll use Quin and models like that, Deep Seq. But I think a lot of coding use cases they like the Claude family of models. And GPT5 is now getting pretty close in capability as well.

So there's been some talk in the industry that for all the AI experimentation, big companies at least are not seeing a lot of value. There was a report that came out recently, I think from MIT that suggests that very few Fortune 500 companies are truly benefiting from AI. We've been running it long enough. What is the real impact for us? Are we really seeing a change in developer productivity? Are we seeing faster shipping cadence? Are developers not having to do some of the mundane work? How do we measure it?

We have a metric internally which we track on a weekly basis and that metric is very simply manual hours saved by Goose. And that's. That metric started at 0% and now it's going to hit probably 25% of manual hours saved by the end of the year. That's our target and we're pretty close. We're definitely on target. That's a complicated metric that takes into account several qualitative and quantitative signals. But I think there is some truth to the fact that these LLMs have general purpose capability. So they're really good at very general things. So if I want to know some historical fact about the Soviet Union, it's going to tell me that instantly. But if I am a researcher in neuroscience like my wife is, and she wants to know something very particular about a type of dementia that she's researching, then it starts to struggle there. And really when you put people with a lot of depth in an organization together, they tend to outperform the basic LLM capability. So it's identifying what the strengths of the LLM are and how you apply it to the enterprise that really is going to unlock the value. And for us, I think that is automating workflows and getting work about the work, all the drudgery manual things out of the way. And that's really where we've seen most of the progress. And then we have another layer of advancement which we're trying, that I described earlier with our agentic middleware layer that's I think, going to unlock a whole Lot more utility for us, but it's early days. I would say the utility phase of LLMs and agents is still ahead of us and we're just starting to see some of that.

So if we have 25% saving of man hours.

Manual hours saved.

Manual hours saved, yeah.

So engineers report 8 to 10 hours per week right now with Goose in particular, but with the whole suite of AI tools and interventions like Headless Goose and other systems that we're encouraging, I fully expect that number to keep ticking up.

So Block has a long history of participating in the open source community, not just consuming open source software, but actually giving back. I know that this is something that matters to Jack a lot. And actually there's a conversation he and I had a few years ago that inspired us at Sequoia to start an Open Source fellowship where we just give funding to people who devote their time to building open source software. Because it has such a massive benefit to all of us in the industry. We made the decision to Open source Goose and I think the company does a lot in other aspects of Open source. So maybe can you talk more generally about Block's commitment to open source development, how he contribute back and then specifically the decision to Open Source Goose?

Yeah, absolutely. It's very core to our values. It's in fact how I got hired at Block, through my Open Source contribution. So I used to work with Bob Lee, who was our CTO before me, our first cto. And it's been a mainstay for us right from the beginning. Not just because these are useful tools that we get to build on. Pretty much all tech companies are built on an open source stack of some kind, whether it's Linux or using tools like Git and so on. But also I think the quality of code is incredibly high in open source. The bar to keep something open source maintained and available to the community is quite high. And there's a certain ethos and commitment that goes with that. And it has a very long lineage going all the way back to the early days of GNU and things like that. So it's really important to us, to Jack. It's been a part of my career right from the beginning. I've always enjoyed contributing to Open Source. I've learned so much from Open Source. And one thing I tell engineers when they say why would we spend all this time and give this source code away for free, is well, we can either have our community of 3,000 plus engineers work on something, or we could have the broader community of 30,000 plus engineers have a look at what we've worked on and contribute their ideas and benefit from that too. So I think as a core value, it's really deeply ingrained in our DNA and particularly in Android is where we've had a lot of success with open source, I would say. Our technologies run on close to 4 billion mobile devices all over the world. And yeah, we think Goose should follow in that tradition and try to uplift everyone and show the way for everyone like it did when we first released it.

What about as it comes to the models themselves, do you have a preference for using open models versus proprietary models?

My preference would be for all models to be open source and open weights. I think that there's some trickiness to it just because of the scale involved in that. Unlike Goose, you can't really download these multi trillion parameter models and run them. But I think the models that are open source, Qen in particular is lately one I've seen that's not just really fast, but really capable with tool use and improving very fast as well. But there are a whole host of others and they're all improving readily. We don't develop LLMs ourselves, but we do develop SLMs, like smaller language models that are focused around customer service and risk. And we also develop other frontier models that we're doing purely for research. So we're working on a speech to speech model which we will open source and we'll publish all our findings. Yeah, so I think it should all be open, so everyone should be able to benefit from this core technology. It should be like a utility, the way the Internet was imagined to be.

And I'm wondering if you believe that the open models will always be, you know, just a step a year behind the best closed models. And if you draw forward the lines, will we be at a point a few years from now where the open models will be fantastic for coding?

It's a very difficult question to answer purely as it's framed. My belief is that this way in which we're using these models is going to change dramatically. So far we have one model, maybe like a couple, and we have an AI agent on our laptop or desktop and it makes calls to that model and it writes code for us. And that's how Goose works as well. But I really think the future of unlocking coding capability from these models is swarm intelligence. So it's not just one agent doing work with you in a sort of co pilot style way. It's how do you unlock 50 instances of the agent or 100 instances of goose or geese if you Will to go off and work with each other to build fairly complex applications. So right now, our core tool calling loop probably finishes on average two to three minutes in each turn it takes. But what if it worked for hours with a whole bunch of other geese? Like, could it build complex applications the size and scale of Cash app? That's certainly where I think things are headed. And if we head there, then it doesn't really matter so much how capable these single model providers are. So the competition may not be is open source model X as good as closed model Y? But can you leverage open source model X because it's small enough and it's cheap enough to run 50, 60, 500, 1000 copies of and that accumulated capability is greater than any single large language model. So that's my bet. And I think a little bit of this comes down to the philosophical question of can an infinite number of ants build a spaceship?

I was thinking about etymology, actually, as you had this analogy, I was thinking about colonies of small units that are not that capable collectively, they're capable of so much.

So I think there is a question around that and it's a worthwhile research direction. I'm not exactly sure how it would. How it's going to play out. It could be a hierarchical swarm where you leverage some large language models, like some very capable models to do the planning for you or to do the reintegration for you, and you break things down into very small, almost nano services that these simpler models can bite off and consume. But yeah, that's a hot research area for us. Yeah, sounds good.

Interesting. Wow. What's on your wish list? I mean, you're at the forefront of deploying AI at scale in a major corporation. You know, we touch tens of millions of consumers and businesses, we move a lot of money.

Yeah.

So it's fun to do it at scale. There must be things that you wish you had.

I always wish I could move faster. That's always been a bugbear for me. Like there's a certain responsiveness to tools that you use locally that are really energizing and that let you build momentum. And so I want that for teams. I want that for entire projects or organizational size initiatives. And so I think these tools can give us that for the very first time. We can start to crack some of the friction in that. But that's definitely on my wish list is like, how do we move faster on all fronts, how do we get more feedback from the data that we do have? And ultimately all of this stuff is so we can build Useful things for our customers and our community. So being able to do that rapidly and iterate would be. Would be the dream. Yeah.

One of the things the audience may not appreciate is Block is committed to being a remote first organization. As our cto, you live in another country in a different time zone and our teams are obviously massively distributed. That seems to fly in the face of speed, or maybe it doesn't. So help us debunk the myths around how to make a remote organization effective. And what are the trade offs that you've experienced? What are the good and what's the bad?

Look, it's definitely true that there are trade offs. I'm not going to sit here and say remote is perfect in every way. I think that there's a very simple fact about remote that gets missed and that is there are some employees that we can only have because we support remote work. So we have certain employees who, you know, there's sort of the leading lights in their industries or in their fields and they would just never work for us if we weren't able to employ them, say in Sweden or in, in Sydney as well. Like there are people other than me who live in Sydney as well. And I think that from the very beginning, especially at Cash App, we've had this DNA of working distributed. And while you do trade off some amount of velocity and serendipity, like coming together with the water cooler conversations and those kinds of things really do accelerate work, I think the benefit clearly outweighs that cost because we're able to hire these incredible engineers and retain them for six, seven, eight years in markets that don't have the same level of competition at Silicon Valley for example. And we were very early to tap into that. So we were in Australia. We opened our engineering offices in Australia pretty much a decade ago and we've never looked back. And the same is true for many other offices around the world. So it is a trade off, but I think it's a worthwhile trade off, particularly when you talk about the talent involved.

I want to ask about whether you all are embracing Vibes coding. So we were just with Sebastian from Klarna who mentioned he'll notice something is off in the app and he'll go and Vibe code it himself, which is just really, really cool. I'm curious, you mentioned some of your non technical people are now able to spin up a site or a dashboard on the side. I would imagine you're not giving them access to the production code base. Do you think that changes over time?

Well, two questions. There so let me unpack them. Vibe coding. I think Goose basically pioneered Vibe coding. I don't think it's too much of a statement to say that, or at least it was very early in the Vibe coding world and we were able to experiment with that a lot. I write code every day, and it's all through Goose, it's all through Vibe code, or through some of the other AI agents when I'm evaluating how good they they go. So I very rarely manually write code. I might make some edits or comment out things here and there just to see how things work. So we're already in the Vibe coding era.

And are all your engineers doing that as well? They're not actually manually writing code anymore.

A lot of our engineers are still transitioning to the Vibe coding way of thinking. I think that it's a difficult proposition, the more complex the code goes. And this is why I think it's more effective to Vibe code these smaller tools like dashboards and reports and interactive kind of systems on a per individual basis rather than make massive changes to 10 million line code bases. And that's purely a limitation of the context window and the ability of the LLMs to scale to that size. So, no, I would say there's still very much a call for manually writing code, but that's because our legacy systems are so complex.

You don't think there are instances where if you want to design something that is truly performant, uses crypto, it needs to be really secure because it's a financial payment system or something like that, where an experienced developer can write very performant, compact code that the LLMs can't yet rival.

I think that's probably true in some very narrow cases, but I would argue that even there, the developer is better off starting with an LLM to code first and then seeing where they can make improvements. So it's a little bit like a sculpture, or if you're writing a short story or something like that. Just having a skeleton to work from is much more productive than trying to sit there and come up with something on your own. The LLMs are surprisingly good at writing performant code. You just have to get them to write it in a particular way. Well, where they do fail is understanding how to call proprietary APIs, because these are not in the training set often and especially if you have very complex proprietary frameworks, then they can struggle to reason about them. And for that you definitely need manual intervention. Where I think humans are called for is in the higher level architectural design, in understanding race conditions and coordinating orchestrating across multiple systems in a topology, those kinds of things we definitely need people in the look for.

Can we make Goose more accessible, by the way?

Yeah, absolutely. How would you want us to do that?

We have, you know, because we're a registered investment advisor at Sequoia, so, you know, we have to comply with all these rules as a regulated entity. And the administrative controls prevented me from fully deploying Goose because I don't have those kind of administrative rights on my machine, unfortunately. So I've been negotiating with it to give me even more access. But I guess if you really want to unleash the potential it needs to.

Have access, we could do that. I think you could still get a lot of value from Goose without that. And we do have experiments of versions of Goose that will run, for example, in a browser or in a fully hosted environment. And those I think could be made deployable in organization like yours. Yeah, but happy to do any and all. And it's all open source, so we can tinker and modify however it needs to be for anyone's use case and we encourage people.

Well, our technology team in Sukhoi is actually a customer, by the way. I don't know if a customer is the right word. They're using Goose internally to build some of our own applications. It's just that I'm not able to. I can confront fully use it myself yet, but I'll go negotiate with them. I know people.

I think giving AI access to your machine might be a little scarier than most people's machines.

Well, it does have a safe mode, so if that helps at all, we're very happy to show them how to set it up.

Diva. And if you can't share, it's okay. But I'm curious if you even look at how much of the code base is being written by Goose or being written by AI today. And. And do you have a guess for how that might evolve over time?

Yeah, we are measuring it and there's different numbers for different teams. Like I said, engineers in the most engaged engineers with Goose probably generate about 30 to 40% of the code they write in existing legacy code bases, which are very, very complex and difficult for agents to work with. As I told you before, in AI first teams, it's pretty much all entirely Vibe coded. So Goose itself, every PR that's open is written by Goose and there are many other similar, more sort of serious production apps that we have that are also deployed that way. But there's still a while before you get to the scale of every single app. Being written by a majority AI code.

Really cool. You mentioned at the beginning of our conversation that generative AI is the big difference between what you were doing with machine learning before and how you're hoping to embrace AI. Now, we've talked a lot about the kind of internal productivity and developed for productivity parts of Generative AI. But what about in the customer facing product? How do you imagine generative AI will reimagine that?

So I think you've got the same types of productivity gains, maybe even more on the customer front. And the challenge is just unlocking all of that utility with the existing systems. And that's why we're so excited about mcp and that's why we work so hard to advance that protocol along with Anthropic and others. So we launched Square AI into public beta not long ago. And Square AI is essentially a way in which you can talk to a goose like Bot that understands all of your merchant financials. And so you can say, you know, build me a bar chart of Q3 results, sales results, and you can, you could go much more detailed than that. And you could say like, hey, if we wanted to close an hour early and I'm running a wine bar or something like that on Thursdays, how much would I lose? And this is actually a real example, by the way, from a business. And it turns out that the people that wanted it closed, who were the waiters, they made a lot of their tips in that last hour. So they decided after talking to Square AI not to do that. So, yeah, we've got it working for our customers on the merchant side right away. We are working on it on our entire product suite. Then as I said before, we see all of our internal tools and all of our products is essentially collections of capabilities. And so we think tools like Goose and AI agents generally can unlock their value by sitting on top of them. And the challenge is just to evolve the interface so that customers understand it, are able to engage with it, and get all the value that that's in there.

One of the things that Jack talked about at a board meeting was that when he breaks it down, it's capabilities and interfaces and sometimes people overemphasize the capabilities without thinking about the UI and how it delights the user and enables the user to really fully embrace a particular product and putting a lot of emphasis on that. That's why we have such a big design culture and we honor design so significantly at the company. Jack's also spoken about the potential of voice as an important interface. We haven't spoken about that. Do you see Voice as having a big role in some of our products as well?

Yeah, absolutely. So, just getting back to the design point, we're very much committed as a company to putting design and engineering on a pedestal. So that's something that we've always done from day one. I think even the very first square reader that launched looked beautiful in design and worked very, very simply, and it hid an enormous amount of complexity. We did the same thing at Cash App. There's only a single balance at Cash App, but it orchestrates all sorts of money in the back end. There's a whole amount of complexity that it suppresses, and that's the uniqueness of design and engineering coming together. So I totally agree with that. And this insight about capabilities and interfaces with the AI agent as the middleware was something that we talked about quite deeply. And I think we came up with that insight probably end of last year. And we've really been pushing to evolve all our products to think like this and to work on the interface first, because the interface is really what the user cares about and what the customer sees. They're not interested in the fact that you have all of these capabilities. If they can't use them to make a sale or to move money, that's really what they care about. So that's where we're focused and trying to unlock all of these capabilities to get there as quickly as possible.

Maybe a last question for me. Any predictions? What does Block look like three years from now?

I think there are a lot of predictions that are possible. I will say that given our recommitment to being a technology company and really pushing the boundary of open source, but also increasing access for everyone and increasing autonomy for everyone is going to push us much further along the road towards coming up with things like Goose over and over again. So watch this space. But I think in three years time, we'll see the next evolution of what agents are like and how they're deployed and used, and if they're even called agents anymore, if there's some other new technology. And I hope, and I strongly believe that we'll be at the forefront of that.

Okay, we're going to have flocks of geese. Any other predictions? What's going to be the big topic for next year?

I think unlocking utility will be a big topic. I do think that many companies have rushed towards AI without understanding truly how to unlock utility from it, and so they're concluding that AI is hype, or they're concluding that it's not. Worth the investment and all these incorrect conclusions. And I just think it's sitting on the curve of capability versus utility. And I think you're really going to see the companies that understand how to do that next year, and that's going to be the topic of conversation.

Well, the pattern historically is that we tend to overestimate the impact of new technologies in the short run and we underestimate it in the long run. I mean, that's the consistent pattern. It was a Stanford computer scientist who coined this back in the 1970s, and I think we're there for AI. I suspect 2026, in my mind, will be the trough of disillusionment as people feel it didn't quite live up to the expectations and will double down. And I think it'll end up surprising us to the upside by 2030.

Yeah, I think you're pretty much on the money. I do think, though, there's a small chance that the LLMs continue to improve at the rate that they've been improving, and that's a really exciting prospect. So if you look at some of the performance of these models that are coming out, combining diffusion and transformer technologies and all of this, there's a lot to be had there. So I think there's a small chance things could really take off. But in the main, I think you're right. There's going to be a. A little bit of a plateau before we pick up again. But I think the companies that realize this and stay the course and really look at value for their core reason for being, that is, in our case, our customers and economic empowerment, they'll do well. And the companies that are chasing dollars or hype will be left behind.

I might be too easily excitable, but I've been excited about AI at every turn. I'm not in any trough of disillusionment. And when I see what you guys have done with Goose and what's possible with it, and the fact that Goose is now writing its own PRs, there's so many examples of just this is a magical new technology and really great people are building really great things with it.

Thank you. Thank you so much for saying that.

And thank you for joining us, Tanji.

Yeah, absolutely. Anytime.

Sam.