Hello, everybody. Welcome to the Builderl ab Studio. My name is Lucas, and I'm a product manager on Buzz and Builderlab, and I'll be your host today. I'm really excited about the event today to share with all of you what we've been working on. Thank you all for coming. Thank you all for taking the time to be here with us this afternoon. I know some of you traveled to be here for the event, so hopefully we make it worth your time. Thank you all to everybody that helped organize this event. It's a really, really great venue. Over the last year, we've rebuilt Block as an intelligence. To do that, on our own terms, we've built our own tools.
Today, we're sharing those tools with all of you, and this event is an opportunity for you to see how we use them, how they work, and maybe get a chance to see for yourself how you might want to use them too. We have a great set of speakers to kick off the event today, and followed by, we'll have about an hour and a half for everyone to walk around the venue, get to know all the different stations that we've set up, and we'll come back here for Q&A with the speakers, and finally, we'll have a happy hour out by the terrace. In terms of the speakers today, we have a really great lineup. Jack is going to kick us off, followed by John and Alex from the design team.
Brad will wrap it up by telling us how it all comes together as part of Builderlab. Building our own tools while rebuilding the company takes a special leader who really understands what it means to operate as an intelligence. It's my pleasure to welcome our Block head, Jack Dorsey.
Just to set the tone, I am not one of the great speakers. But I will provide some context, and I want to start with some gratitude for you all. It means a lot that you're spending time with us here in San Francisco. This is where we started it all. We're really excited to bring everyone together, and we know that there's so many things you could be giving your attention to, and so much that demands of your time, so it's really important and special to us that you're spending a little bit of it with us. We thrive on critical feedback. Everything that we see and that we show you, I should say, and we present, please be critical, please be frank, please be upfront, and we'll make it better.
The goal here is to make something that works for everyone and that we can truly build together. I wanted to provide a little bit of context, and my slides are going to be very minimal, but I have a lot to say, but I don't want to overshare, so I am going to read my notes a little bit as well, which I never really do, but I want to get this right. I wanted to start with a very simple idea, which is a company itself is a technology. We don't often think about companies as technologies, but if you really dig into it and you meditate a little bit on it makes a lot more sense. We think of them as groups of people. We think of them as products, brands, organizations.
A company is actually one of the most important technologies we've ever invented, that I am aware of. It's a way of organizing people, information, decisions, and resources towards a common purpose. It enabled us to accomplish things together that none of us could accomplish alone. I think most of us who've been in companies have definitely felt that. Over time, we've developed a fairly standard architecture for making companies work. We organize people into functions, we define roles, we create hierarchies, we establish processes, reporting structures, management systems, all the things that we end up despising about companies, and we really haven't questioned them. We build all this software to help manage all of it, but none of this is a requirement. It's all made up, it was all designed, and it's a design that emerged from a fundamental constraint a long time ago.
For most of human history, intelligence existed only in people. If you wanted your company to know more, you needed people who knew more. If you wanted your company to do more, you needed people who had more capabilities. As the number of people increased, so did the complexity of coordinating them. We invented structures to solve that problem. Departments, management, meetings, approvals, hierarchy, so on and so forth. They're inventions that have allowed us and enabled us to build really amazing things, but they're still inventions for the moment of time that they were in. The important thing about technology is realizing that when the underlying constraints change, we can completely rethink the design of what we're working with. I believe that's exactly where we are today. We've thought a lot about this principle of companies move fast or slow based on information flow.
If you think about what actually determines how fast a company moves, it's not simply how talented its people are or how hard their work. It's how quickly information can move through the company, become understood, and turned into action. Imagine someone noticing a problem with a customer. They have all the information that matters, but what happens next? They have to write it down, they send a message, they create a ticket, they schedule a meeting. Someone else needs to understand the problem, then someone needs to decide what to do about it, then someone needs to act, and at every single step, information moves from one person to another. It's super lossy. Context gets lost, questions get repeated, decisions wait. I am sure you all have experienced that and maybe put some frameworks in place to minimize that.
Sometimes the same information is explained five or six times before anything actually happens. It is true even when everyone involved is exceptional, even if they are highly capable. The problem is not necessarily the people, it is the very architecture that we are working in. A small group of people with shared context can move remarkably fast. You have all felt that, especially if you are in startups where there are no doors, everything is shared, everything is on the same surface. Everyone understands what they are trying to do, they know what is happening, they make decisions, and they act. As a company grows, that becomes much harder. We create more structure to manage the complexity, and eventually, much of the company's energy goes towards coordinating itself, and that just feels super wasteful and inefficient.
We spent decades building software to make that coordination more efficient despite that, messaging, documents, dashboards, project management, collaboration tools. But we have mostly been improving how information flows through an existing structure through tiny little iterations. What if we could rethink the structure itself? We had this realization that all this work and thought has gone into, how do you integrate intelligence into a company? I think it might be the wrong question, and it is what we have been exploring at Block for quite some time, especially this whole past year. We are living through a fundamental change in the availability of intelligence. For the first time, intelligence is not limited to people. Machines can reason, write software, analyze information, use tools, and increasingly carry out complex work. These capabilities are improving quickly. We are all feeling that every single day.
Every company is asking how to integrate machine intelligence, but I think it might be the wrong question. We are asking how to fit this new technology into companies we have already built. How do we add AI to our products? How do we add AI to our workflows? How do we give every employee access to AI? They are useful questions, but they are not the most important question. What kind of company would we build if we were starting from scratch today? Just ground zero, from zero, what would we build? Knowing that intelligence is becoming abundant, knowing that machines can participate directly in the work, knowing that information does not always need to travel through a human hierarchy before something can happen.
We build something fundamentally different, something that is not simply a collection of people operating a collection of software tools, but a company that can understand itself, that can act through its capabilities, anticipate what is needed, and continuously improve. A company that operates as an intelligence, and the best way to integrate this machine intelligence that we are all participating in and all have access to now is to try to become it itself. But there is a really important distinction here, which is if you just add a thousand AI agents to the problem, that does not equal an intelligent company. Imagine a company with a thousand employees, and every one of them has an incredible AI assistant or thousands of them. The engineers are writing software faster, the designers are exploring more ideas, people in finance are analyzing more information.
Everyone's producing more work, and that could be great, that could be not so great. What happens when that work needs to move to another part of the company or actually be actioned upon? Someone still has to reconstruct the context, someone has to coordinate the people involved, someone still has to understand the decision, figure out who can make it, and ensure that something actually happens. We've accelerated the individual work, but the company itself may still be operating exactly the same way as it had in the past. In fact, we may have made the coordination problem even worse, because now everyone can generate more work than ever before, and I know we have felt this significantly over this past year. All that work still needs to move through the organization, and this is why I think we need to distinguish between two fundamentally different things.
One is a company that uses intelligence, the other is a company that is an intelligence. One is a collection of increasingly capable individuals and tools, and the other is a shared system. One where understanding persists beyond individual conversations, where people and agents work from common context, where capabilities can be coordinated across the company, and where intelligence recognizes what needs to happen and helps make it happen without constantly starting over, and importantly, without losing human accountability. That's a fundamentally different architecture than we're used to, so what would we actually need to build? We've been thinking about this in terms of four essential layers. The first is a world model. This is what does the company know about itself? What does it know about its customers? What does it know about its own employees? Today, a company's understanding of itself is fairly fragmented.
Some of it lives in databases and documents and conversations and the heads of its people. Much of it's disconnected. People can't easily bring it together. A world model brings these things together into a shared, evolving understanding that's constantly updated. The company, its customers, its products, its resources, its environment, and what it's trying to accomplish. It's not just a collection of information, but it's an understanding of how things relate to one another and how they're changing. The second is capabilities. This is what can a company do? What are the tools it has access to? Intelligence that understands a problem but can't do anything about it is only so useful. It needs the ability to act, to write software, to work with customers, to analyze transactions, operate systems, and execute tasks.
The important part is connecting intelligence to real capabilities with clear boundaries around what it can and can't do. The third is action prediction. This is really what should happen next. What can the company anticipate and initiate, more importantly? We want to notice something, understand it, decide what to do, open an application, and tell software what action to take. If a company already understands its goals, its current state, and the capabilities available to it can begin to anticipate what needs attention, recognize the opportunities before it, identify problems before they become urgent, and initiate appropriate work within the boundaries that people in the company establish. Instead of waiting for every instruction, intelligence can help us help the company move forward much faster. Fourth and finally is interfaces. This is how people direct and shape the company and the intelligence.
How do we express what we're trying to accomplish? How do we understand what the intelligence is doing, question it, correct it, and shape its behavior? These interfaces might look like conversations, they may look like applications, or they may look like entirely new ways of interfacing with computers and intelligence that we haven't dreamed of yet. We want to make this accessible, understandable, and useful to people. This is the intersection of where I interact with the company and how I actually shape it going forward. What's new is not these layers, but actually putting together in one cohesive architecture that can effectively be queried by anyone in the company. Just to put this in something very concrete, which is very close to our heart, these are sellers, these are small businesses. Imagine you're running a small restaurant.
You care about the food, the experience, the people who come through the door, but running the restaurant also means managing inventory, suppliers, schedules, payments, payroll, and dozens of other things that you have to worry about constantly. Now imagine the restaurant itself as an intelligence. It understands the business, it knows your inventory, your costs, your suppliers, your historical demand, and what you're trying to accomplish. It has access to the capabilities required to operate the business. It can anticipate you're likely to run short of something before a busy weekend. It can identify the best options, prepare an order, and explain the trade-offs. Through this interface, you can understand what's happening, make a judgment, and improve the action. You're still running the restaurant, you're still making it special, but now you have access to capabilities that required a much larger organization.
It's not four separate applications that you're working with, it's one company, one interface that fully understands what needs to happen, where we are, and what needs to happen next. When people hear about intelligent companies and intelligence in general, there's often an assumption that the goal is to minimize people's contributions. That's not how I think about it and not how we think about it at Block. In fact, I think the people become a lot more important. No world model will ever be complete. The world is constantly changing, customers change, conditions change, new problems emerge, new opportunities appear, things are moving very, very fast, and people are closest to those changes. They're closest to the customers, they're closest to the unexpected. They can see and feel serendipity and think in different ways, closest to the things intelligence just doesn't yet understand.
People bring the judgment, they bring creativity, they bring taste, relationships, ambition, and also values. They decide what matters, they challenge assumptions, and they recognize the possibilities that no one else has considered before because they're very close to it. We believe that people are the edge, and they're every company's edge, and they only make the intelligence better and vice versa. They're the connection between the intelligence of the company and the reality of the world. The purpose of machine intelligence should be to amplify their ability to act, not to create another system they have to manage, but to give them a lot more agency, more ability to experiment, more ability to make decisions, more ability to turn an idea into something real.
We should be able to take enormous amounts of coordination and administrative work out of the way and free people to focus on making things they think are exceptional. The goal is to remove the things that keep people from doing their best work, and that is exactly the company I want to build and the company that I want to work at. Speaking of, this is what we are trying to do at Block.
I want to be clear, we have not completely figured this out yet, but we want to figure it out in the open. We want to figure it out with all of you. We are experimenting, we are learning, we are challenging a lot of the assumptions about how a company should be built, how it should operate. But we have realized something really important. You cannot fundamentally change the intelligence of a company without changing how the company works.
We have looked deeply at how our company works and questioned every single thing and have some principles around how it moves forward. We have to think about and rethink about responsibility, decision-making, how people collaborate, how work gets done. We have been moving towards a much simpler operating model. Everyone we consider to be a player. Players are the ones that get the work done. They do the work, they exercise judgment, they experiment, they create. Every initiative has someone directly responsible for its outcome, someone who establishes direction, ensures the right decisions get made, and remains accountable for the result. Everyone has a coach who helps them master their craft and become more capable. So we have players, we have directly responsible individuals, and we have coaches. We are trying to separate the work of building something exceptional from the organizational machinery that often surrounds it.
We are using machine intelligence to make that possible, obviously, to make context available, to connect capabilities, to reduce the effort required to coordinate, and to make it possible for people to move directly from understanding something to actually acting on it. But none of this happens simply because we introduce AI models or AI tools. It requires changing the technology and the operating model together in unison. That is one of the biggest lessons we are learning. The tools shape how the company operates, and how the company operates shapes how the tools we need to build. They evolve together, and this is why we started building Goose. We built it to give our engineers a more capable way to work with machine intelligence. But as we expanded what it could do and how it could connect to our systems, we began to see something much bigger.
We needed environments where people and agents could work together, where context could be shared, where intelligence could use the capabilities of the company, and where people could understand what was happening and remain in control. We are rebuilding Block itself as an intelligence, and we are building these things because we need them ourselves. Block is our first experiment, and as I said, we are still super early, but the more we work on this, the more convinced we become that it is not just a better way to operate Block, but it is the beginning of a different way to build companies. The problems we are solving are not unique to us, and this is why we created Builderlab.
Every company is going to have to figure out how people and machine intelligence work together, how to give intelligence access to the right information, how to connect it to real capabilities, how to make it useful across people and teams, how to give it the ability to act while preserving human control and accountability. We don't think everyone should have to build all of this independently, and we don't think that the answer is just another collection of disconnected AI applications. We believe the foundation should be open and extensible, and we're taking these tools and infrastructure we've been building for Block and making them available to other builders. Buzz is a shared workspace where people and agents collaborate, and probably the greatest manifestation of a company as an intelligence.
Builderlab brings together the infrastructure, the models, the tools, permissions, and execution environments that help make that collaboration practical. We're building it because we need it ourselves, and we're opening it because we think the possibilities are much bigger than Block. We don't know exactly what this looks like in the future or where it ends up going, and we don't want to be the only ones figuring it out. We want other people building it with us, experimenting, challenging our assumptions, as I said to start this, and creating things we haven't imagined. Because the opportunity is to make an entirely new kind of company possible, and that really, really excites me. We started Block over 17 years ago because we believe more people should have better tools to participate fully in the economy, to create, to build something that they own.
We believe intelligence should follow the exact same principles. What if the smallest companies could have capabilities that were once available only to the largest? We're seeing that and feeling that every single day today. What if a handful of people could build something that previously required thousands? What if the limiting factor wasn't the size of our organizations, but the quality of our ideas and our ability to make them real? We're at the beginning of something we feel is pretty amazing. We get to question some of the oldest assumptions about how companies work, which is very, very exciting to me. There's a lot I love, but a lot I hate dealing with every single day, and invent something entirely new. And we want to build all that out with all of you together.
We believe fundamentally, good ideas could use some company, and that's why we're here today. And with that, I want to bring up our folks and show you what we've been working on. Thank you so much.
Okay. Hi. I'm John, and this is my dear friend Alex and Creative Director partner. We are coming from Block Central Team, representing design intelligence, and we want to talk to you today a little bit about what it's been like going through this transformation process and how we've approached it. Starting with the fact that I think the path to Builderlab started when we released our open-source agent, Goose, back in January of 2025. For context, this is before Claude Code was a thing, Chat was on GPT-4o. This is fairly early on in the agentic landscape developing, and we have been busy since that point, really tinkering and playing around and understanding what it means like to change our company based on these new technologies that we're all dealing with.
We want to talk about how the transformations happen within the company, starting with the culture of Block. Because as Jack mentioned, it really doesn't matter how many agents you have developing models and changes in technology that are going on, without acknowledging that Block was actually well primed for this type of transformation, and how we've taken things that have been in Block all along and sort of rolled them into the new way that we're transitioning into an intelligence. So when I think about culture at Block, I think about these three things. These are not pillars, these are not things that we have on a hashtag wall in all of our offices. They're not part of a rubric that you need to hit all of these things every time we ship something at Block.
They're more of an ethos that I feel like live inside all the decisions across every function in the company and how we work. The first one has to do with Block's history of experimentation. One of the things that I feel like brought many of us to Block is this deep sense of tinkering and playing around with technology to create things that simply haven't been invented before. The original Square Reader enabled small businesses and people at flea markets and local artisans to accept card payments at a time back in 2009 when that simply wasn't possible. You had to be a much bigger business with bigger budgets and a lot more established to be able to do this.
While this tinkering and refining took years to make something very simple, the understanding of hardware and understanding of software, compliance, security, and really thinking about that transaction experience, this is something that's been in Block and still exists today, almost 20 years later. While I don't know that that build and refine loop is something unique to Block, the amount of space we hold and the way we think about experimentation as a foundational thing that we make is unique to Block. Earlier this year, we released something that also took years of time tinkering with hardware, software, our domain expertise of understanding how restaurant and kitchen operations work to create, yet again, something that feels like an extension of a small business or anywhere this device sits in a super exciting way.
Block is not a company typical like every other tech company who says they have some 20% time for you to tinker and play with technology in your spare time. We are experimenting as the core way we work 100% of the time. When Jack first asked us to start thinking about how to fundamentally reimagine our roles, this came into play big time, because it didn't feel like a thing that we could do with 20% of our time. It's really a full-time job. The second thing that I think is a major culture contributor to how we've made this transition at Block is a concept that I think about is working in the open by default.
It's really an extension of the protocols and things that we know from the open source engineering world applied to design and a lot of other functions of Block that you don't usually think to work in that way. The way that we stumbled on this is, earlier this year, Jack made a declaration to everybody across Block that everyone is now a builder. While this idea was a bit of a head-scratcher for many people, the idea was quite simple. It's that it's no longer just design and engineering's job to figure out what to do with new technology. It's now everybody's job, no matter what function or what your expertise is. It's up to you to figure out what this new version of your job is, with you being more technically enabled and being a builder alongside the rest of us.
Culturally, it meant that we got to look at the fear of being automated out of a gig into redesigning and thinking about this new version of our job together as one. This was very polarizing for design. If you Google the design process, you're going to find something like this. It's called the Double Diamond, and it has this very clean, nice way of thinking about how we solve problems and how we deliver design experiences. While this sounds very good, every place that I've ever worked at, design actually feels a lot more like this process. There are messy files, artifacts, screaming matches, tears, late-night conversations, doubt, and eventually you create artifact after artifact after artifact, and you get to a place where you create a final deliverable or some sort of spec to start building something.
Once this creative process takes off, it is nearly impossible to intervene or participate in. It's like trying to make sense of a 10-year-old's birthday party. There are decisions that were made and conversations you weren't a part of. There's version 506 over here that we can't find. There is just a lot of things that you really can't make sense of, and it's really hard to jump in as an outsider to figure out what to do. We learned the hard way that it gets even worse when you give designers AI, because it allows us to generate chaos at a pace that we've never experienced before, and it also allows us to really abandon the design process entirely because it's so easy now to take an idea, put it into one of these new technologies, and get something that you can play around with.
On the design team, we started thinking, what would it be like to open source design? Of course, this thing isn't directly translatable, but if we took the qualities and the principles around open source engineering and started thinking about them design, we thought, what would that look like? For starters, it meant that all of these side conversations and 11th-hour conversations needed to happen in a place where everybody can actually see. We need to be able to see when decisions were made, what that led to, and where people need to see all the context of one specific project for them to be able to contribute, so that anybody can come in at any point in time and feel more effective in their ability to add value to the project.
This is fairly uncomfortable for design, and I'm sure it is for many other functions, because it's a level of diligence and thought put into the way we communicate and collaborate with each other that we haven't done before. While it's still a long ways to go and we're thinking about this, we do feel like it's inevitable that this is the way of working in the future, because it's not just a better way to work with each other, it's also the way that agents need to work and for us to work with them. We think that an agent doesn't know what to do with sloppy files. They can't be helpful in a context where they missed half the conversation that were had about a project and they don't know where decisions are making.
We feel like a big part of the culture shift that we've made is to try to work more in the open, try to be more conscious of the way that we hand files off, and really try to take that ethos that lives in open source engineering and bring it to every other function across the company. Okay. Last thing. Floating in the air at Block, we talk a lot about sovereignty. This one a lot more than the others is out there, and I think about it at two different altitudes, both in how we design experiences for our customers around sovereignty and how we, in return, think about designing Block so that it's a lot less reliant on other systems and things that are out of our hands.
The mission at Block is to build technology for economic empowerment, and one of the things that I've learned the most about working here is that's why a lot of us are here. Whether or not you came in at a time when Square was enabling mom and pop's local businesses, or local artisans, or people that you had a very personal relationship with, or you've been on a team at Cash App where you're serving people that are traditionally denied or left out of the financial system in this country, or you work at something like TIDAL, where we're designing for artists who simply want to make a living off the work they're trying to create and not be gouged by streaming services, really, we all have the thing in common where we design for people who are usually not designed for.
When you do that, you think a lot habitually about things like access, safety, choice, and things that you don't think about when you're designing for people who have all the choice in the world and a lot of options there. We know our customers need their money when they need it. They need to be able to do with it whatever they need instantly without reliance on one single financial institution or the fear of their assets are going to be frozen or something's going to go away because they made one wrong move. We've spent over a decade thinking about this, and it's not something that you can just stand up overnight.
It requires fluid systems and infrastructure, it requires organizational adaptability, and it requires a lot of grit and culture where you just are ready to take whatever comes next, because a lot of the things that we do stands between some institution or system that we're dealing with and a customer and a simple experience. The good news is that we think the way that we've approached designing financial sovereignty for money is actually very relevant to how we think about designing sovereignty in the world of AI and what's kind of missing. With the jumpstart that we have on that, earlier this year, we released another one of our open-source projects called Berd. Berd is an open-source agent. It's model agnostic, it's extremely customizable, and it's really meant to be built on top of and something that you can make your own.
We believe that you should have ownership over your memory, your context, and your agents, and you should feel in control of them the same way we think you should be in control of your money. This has been pretty transformational for us because it's felt like a pretty organic shift from everything that we've been doing for the past 17 years, starting to look at it and through the same lens in these tools. Lastly, the biggest cultural shift that comes with sovereignty is this idea that we're finally starting to design tools around the way we work instead of the other way around.
For decades, we've obviously had to deliver the customer experience that we're used to by way of using an entire SaaS marketplace of tools, which means we've always had to bend the way that we work around other tools and the integrations and the paralysis that comes with those things. This is the first year we finally feel like we're in a place where we're designing tools around the way we work instead of the other way around, which is very exciting. All right.
If that is sort of the culture shift and the things that we have been thinking about as we have gone through this, we know this might not be relevant to a lot of other companies, and you might not have the same things that led to some of the logistics that created our values, but we do hope it gives you an insight into the way that we have started to shift and work with the tools while the tools have also shifted us in order to change. All right. Back to January 2025 and the launch of Goose. Of course, our culture did not magically change and everything just worked out and has not been super easy when I sit up here and talk about the fact that we have done all this.
It took a lot of time creating, playing with agents, and figuring out how to work with them in a way that felt like they were teammates with us. We want to talk about two of the biggest mindset shifts that we made this year that felt like it led to the place that we are at now and what we are sharing with you today. The first of which is when we stopped thinking about an agent as a chat interface, and instead, like a super teammate that we could actually design ourselves. We first started feeling this paradigm shift not at the interface layer, but much more in the technology and the open source landscape around the architectural decisions of how agents were starting to move earlier this year.
We had been asking ourselves at this point for probably over a year, what was going to happen after the chat interface? At that point, we had all hit a lot of AI fatigue. We were looking at a lot of tools that felt exactly the same, and we felt like we had lost touch of where and how to insert the soul and a touch of humanity into the things that we were creating that were known for at Block. That was our first big aha moment, is that we needed to stop thinking about this as a technology and a functional problem and think about it as a brand and a creative problem.
Yes. Right now, anyone in this room can describe an idea and have something pretty decent in a matter of moments, whether it is an image, a brand, a website, a whole app if you want. That is amazing, but making something great is still really hard. It requires a lot of thought and consideration and craft. The process of being creative has not fundamentally changed, but the tools have. Look, humans are feeling creatures. AI is not. It is never going to be the thing that moves you, right? That is what is so critical right now. On top of the skepticism and the fear that we have with AI, I think frankly, there is just a lack of joy and soul in how we work right now.
I'm someone who is quite particular about the things that I live with and that I own, things that are beautiful, a little strange, but generally just bring me joy. I don't see why the tools that we work in every day shouldn't be any different. When we started redesigning Berd earlier this year, the sentiment around agents was a little ominous. They were these elusive things that would do a task on your behalf, but they were very rarely represented by anything more than a gray chat box, and if you were lucky, a little sparkle. It felt rather faceless and hollow and kind of serious. At the same time, as we're tapped into culture, we were understanding this sort of cultural hunger that is for something weird, something whimsical, something original, almost like the antidote to the sameness and the mediocrity of AI.
Which is why levity and play became such important tenets in designing an experience that felt different and kind of bucked the status quo. Cue Gloopies, otherwise known as nightmare fuel for a lot of folks. Sorry about that. These began as a sort of antithesis to the sheen of AI. Yes, whilst we did use AI to create these, they're a creative expression that feels distinctly human in its creativity and care. Whilst Gloopies were the most popular, well, maybe I should say most contentious collection, we did actually launch with three collections, Fuzzies, Figgies, and Gloopies, making sure that anyone that used Berd had a choice of the avatar that would bring them joy. Essentially, Berd was our room for experimentation. As our own internal tool, it gave us space to test ideas, and a lot of which have now carried forward into Buzz today.
Once we made Berd and the agent avatars open source, as you can imagine, we were thoroughly entertained and delighted to see the reactions from people online. I think maybe this one's my favorite. Berd agents are an excellent example of how sometimes you need to be a little psychotic to differentiate yourself. I wear that with a badge of honor. This just goes to show that when you put care and creativity and try to do something different, people pay attention. I guess what I'm really trying to say to everyone here is that Gloopies will save the world. No, they won't. But they do bring people joy and a sense that a human actually touched this, and that's what I think matters, especially right now. They're also an example of how we design at Block.
We experiment, we explore, and we're not afraid to listen to the ideas that maybe sound a little unhinged at first. We don't shy away from the things that make us uncomfortable. That work really only happens when you bring together different people, disciplines, and perspectives in a room together early on before anything is fully resolved. Of course, we should have seen it coming. The most popular feature request was, can I make my own Gloopy? We could have just made one avatar for Berd and called it a day. But when we think about personalization, sovereignty, and choice, it felt wrong to keep the fun to ourselves. We designed a systematic way that everyone could create their own. What started as a creative decision ultimately became a catalyst for product direction.
Luckily for the people here today, you can actually create your own custom Gloopy, terrifying or not, in the Agent Studio a little later today. Also grab yourself a blind box Gloopy for free if you want one.
Okay, so shortly after we released Berd internally, it became the number one used tool inside Block. So much so, that is why we decided to open source that as well and let everybody have it, though we were much more focused on Buzz. We were feeling really good. We had moved culturally from a place where agents and the idea of them crawling a computer felt kind of scary to something more like this, where people were sharing videos of their kids seeing Gloopies for the first time, debates around who had the best bench of Gloopies and what their teams, all of a sudden, we were in this world where the idea of multi-agent workflows were alive and well across the organization. But we knew that, just like humans, that was not the end of it. Agents need context about the information that our services offer.
They need information about how we make brand decisions, what to use when they create stuff with us, if they were ever going to be really good teammates. The other big thing that hit us over the head this year is how much more design was becoming architectural. We were moving away from thinking and brainstorming that ended in solutions that had to do with sort of handcrafted experiences that were at the interface layer, a lot of us started to feel like we were being more helpful creating systems and infrastructure that distributed things like context and routing and design intention behind the way that we think of creating things on the Block brands and creating things for those.
We thought, if we are ever going to be in a place where we feel like agents can really fundamentally render things for us instead of us making the interfaces all by hand, there is a lot more things we needed to do there. One of the other things that we are giving you a sneak preview of today that we are super excited about is called the Brand Hub. It is something we have been building all year. It is a take on our own digital asset management tool that brings together all the central libraries for all the brands of different things at Block that we do.
It has guidelines, it has generative asset tooling, and really brings together for the first time at Block one sort of place where both humans and agents can come together and understand and get all of the information they need to make things at Block. The second sneak peek that we want to show you today is an experiment that lives much more behind the scenes, but it takes everything that lives in the Brand Hub and all those assets and intelligence and guidance on how we're supposed to build really fun products at Block, and it gives people a way to just access that in whatever agent, Buzz or Berd or whatever harness you want, and actually create things that feel very on-brand for this company.
We have both two stations out in the main hallway today if you want to learn more about this within the design team. There's a ton of other experiments that we've been doing, but these are all part of things that come together as what we've talked about as the Builderlab. We want to wrap up by sharing that, even though we had made agents feel like something you actually want to play and talk about, and that we have a bunch of things that we've been experimenting on with infrastructure, intelligence, and systems that they need to sort of do work with us in one place, we still felt like most days we were sitting in between copy and pasting things from our dream team of agents and our dream team of humans. That was the start of Buzz.
Buzz is the place where all the context, all of your teammates, humans or agents, come together in an interface that is completely personalizable to the thing that you were doing at that exact moment, with plug-ins and more that you're going to hear about from Brad in a moment. But it really is the thing that Jack mentioned. It's the closest we've felt like being able to tinker and play with intelligence together as a team. That's the Builderlab. Thank you so much. We look forward to playing with you all outside today. Ladies and gentlemen, please welcome Brad to the stage to talk about Buzz in more detail.
Hello, everybody. All right. Hello, everybody. I'm Brad Axen. I lead AI capabilities at Block, and I'm very excited to be the person giving you a live demo of the tools that we're launching today. That's both some of the backend that you'll see from Builderlab and the 1.0 version of Buzz that brings it all together into that one interface that Alex and John were talking about. The core idea behind Buzz is to bring together the people on our team, the agents that we're working with, and the projects that we're working on into one place.
That gives us so many more opportunities to collaborate, and as I'll walk you through in a minute, it puts together the context of our whole company so that the people see all the work that's happening and the AI tools can see all of the decisions that we're making, and really gives us a lot of time back and lets us automate more and more of what we're doing. I'm going to be demoing all of this. It's going to be pretty quick demos, but as you go out through the event today, you'll get a chance to try all of this yourself. Go find one of the demos and actually install Buzz and try some of the ideas you're seeing. But you'll actually see me using this live in just a sec. Okay.
As Jack mentioned, we think of people as the edge, and agents aren't just standalone automations. They're extensions of how people contribute in our systems and in our company. The agents are inheriting their capabilities from the humans that manage them, and we've invented an identity system for Buzz that lets agents have their own unique identities. They can join the conversation. You can see that they're AI, and you can also see who's responsible for them. Any actions that they're taking in the system, any decisions that they're helping to make, you can see who's accountable for the work that they're doing. Let me start just by showing you how to create an agent in Buzz. This is very much inspired by those prototypes in Berd. I'll go set one up. We can grab an avatar here.
I'm going to go ahead and give it a quick name, and you'll see not only is it fun to do the avatars and everything, but it actually serves a role in the interface for how we keep track of everything that's going on. We have a bunch of different options for how you're going to run those agents. We started with local agents. We thought that was really important so that you could work on the files on your computer, and we wanted to be really compatible. Buzz is an open-source tool. We have made sure that it works with all of the different harnesses that you might already be using and happy with.
Of course, if you don't already have one that you like locally, you can use Goose, or you can use one of the harnesses from the labs, and you can use that with any model. But today, we're actually launching our remote Builderl ab agents that take that same idea, multi-model compatibility, but run it on remote workstations so that you can do this from your phone when you get the mobile app, or even on your laptop if you're just running out of local storage space. All right. Our model catalog here. We have many options that we're providing in Builder Lab remote inference. We have some fast mode models that are open-source models like GLM-5.3 and Kimi K3.1. Those are great when they're going to join the conversation. I'll demo that today.
But we also have a comprehensive catalog of the frontier models, different things you can use. I'll just set a setting here. That's pretty much all you need to do. It's going to explain that it's a remote agent, and we can get started. I'm going to head over to the conversational interface. I'm going to start solo. I'm just going to go tag that agent that I created, and I'm going to ask it what it can do. I'm not going to make you wait and watch me like vibe code. That's way too slow. I just want to show that it's that easy to create an agent. It just takes 10 seconds. You don't have to go make a service principal.
The goal here is that everyone's just going to build themselves a team whenever they need a new thing, even if that's a throwaway agent that you might use for an hour or a day. Those agents get their capabilities from you, like I mentioned. So, it's got a lot of different capabilities that are powered by a connection system. This is part of Builderlab. This is also launching today, where you can go in and link your different accounts, and that provides a set of tools to the agents that they can use on your behalf, but with some limited scopes and some safety controls. Okay. So that's what these agents can do. Now, back to the next point of the things that really matter in Buzz. I think this is the most important architectural decision behind Buzz.
The intent is that we're bringing the whole context of the company into one place. That's the world model that Jack Dorsey was talking about. It's really recognizing the value of the data contained in the discussions that we're having among each other and in the discussions that we're having with our agents. So far, in the past, we found those to be very disconnected. So you would use an existing messaging tool, you would go make a decision, and people would go off and work solo. When they're doing that work, all of that decision-making, they're just leaving it behind in a separate system, and the other people on the team don't get any access to that. This combined interface lets everyone see what the agents are building and all the agents see what the humans are discussing and deciding.
Okay, let me show you the collaborative version. I'm going to head over into a demo channel, and you can see at the top level here, the conversations are mostly among people. So these are people posting in a pretty familiar chat interface. The agents can join that same conversation. If I scroll up and find, say, a thread with a few different participants, some of these end up being primarily a conversation among a person and their agents. Some of them are mostly conversations among people. An agent can just enrich that conversation. So here, two people are talking, an agent goes and gets some extra information that you can see in the thread.
This is where I think that idea of the avatars and the names come in, because if all of these are just one version of an agent, they all have the same name, the same identity, it is impossible to keep track of this conversation. As more and more participants join, this gives us a pretty familiar way to figure out what is going on. I think another thing to think of that is, I think, really critical for Buzz is that I have got all of this information in my sidebar here, all of these conversations that are organized. That becomes a dataset accessible to all the agents. I can just ask them to participate without me having to prepare a context window for them to use. Increasingly, they are proactive about that information.
The agents that I am working with, you can just ask them to pay attention in channels and give you updates. I have an agent that is constantly on that is sending me updates proactively without me reaching out to it. That agent, we just iterate together on what I need to know. I just tell it what I am looking for, and under the hood, that is using a classification model to decide when it needs to act and give me more information as all of this is flowing through the system. Okay, so back to the next point. This is something we are really excited about. This is launching today for the first time. Builderlab is including website hosting. We are calling these apps, and the idea is that you can create and share websites internal to your company.
These are not on the public internet, so they are meant for kind of internal sharing, and they can reuse those same capabilities that your agent can use to build more complex sites. People use these for all kinds of things. Since we introduced this to the company, we have had more than 30,000 of these built by our employees. People use them for everything. An obvious one, for example, if you have a dataset connected, you can build dashboards here and then share something that is a little bit more dynamic than a traditional dashboarding tool. Or just instead of making a presentation, you can build a website that gives that information a little bit more visually. I think the version of this that I want to spend some time on is how it becomes an opportunity to communicate in prototypes.
Let me show you what that looks like in Buzz as well. If I scroll up here, I was working on a PR with some of the design team, and I was able to make this idea that I have been working on, and I wanted to get feedback. I could ask one of my remote agents to turn this into an app, and it comes back with a link that the whole team can see. If I click on this, I will get a mock of our existing code base. It is real interface, but fake data. The agent has gone out of its way to build a tour that my whole team can follow along. The idea of this example is I am trying to come up with a better design for organizing information as agents talk amongst themselves and share details with the humans.
The agent has built this little walkthrough, but that is real code. I can click around in this interface. I can actually see what the prototype is supposed to do, and all of that works because it is actually borrowing from our existing systems. I think this is a much better way for us to solve problems together, because everyone can go see this, react to it, riff on it, make a new version, and their agents can just go access that same code. This is a much better way of figuring out how you are going to build something than just sharing that same information in English. It is kind of our way to extend the things you can share inside Buzz outside of just text. Now, onto my last point.
This is one of the things I am most excited about in Buzz, which are plug-ins. The idea with plug-ins, it sounds a little incremental when you say plug-in. You are used to some software that can have minor extensions. Buzz is actually written in a way where it is plug-ins all the way down. The entire application that you are working on the desktop, is editable by you. I think this system makes a lot more sense when you are working with an AI tool, because you can just ask for whatever you need, and it can edit the interface you are working in until it looks exactly like you want it to. With Buzz, the backend for plug-ins is online, so it is shared among everyone in the community.
That means not only can you build a tool for yourself, you can share it with your team, and the data that you have in those plug-ins can be shared with the team. If you want to build a task tracker plug-in, if I update a task on my side, you are going to see those updates too. Let me show you what that looks like in the app. Our plug-in system is here. As you can see, like I mentioned, literally everything in the interface is a plug-in. I can turn off entire surfaces of the application, and it will just update in real time. These plug-ins can be built by AI, and they can install it for you live. You do not have to reload. You can see, we do all kinds of things with this. We can plug in different model harnesses.
We can build extensions, like attention that I was talking about earlier, where the agents can watch channels. We can do external integrations. The one I am going to show you right now is a GitHub integration. We have a GitHub integration in Buzz, so we can spend more time staying inside the conversation and not having to go to an external tool. I will head over to the chat, and you can see here, if I click on this GitHub link that I shared, we get this inline preview. You can extend the interface in any way like this. Not only can this be like a rich view, I can actually take actions in here. We can see the changes. I could approve or merge this PR from this interface, or I can choose an agent to resolve issues happening in the build system.
This is not just like sidebars or wherever. The whole app is editable. You are seeing that this preview link is giving me the status of the PR in real time, and that will update if it was merged. We introduced a plug-in marketplace inside Block. That plug-in marketplace is itself a plug-in, which is fun. This has gone crazy since we introduced it a week ago. We have had, I think, 50-something plug-ins contributed, and people are using them all the time now. You can do all kinds of stuff in here. I think there is really all sorts of opportunities for reworking the interface to fit the way you and your team need to work together. Here is an example where someone is reworking the conversation interface into a Kanban board and make it more task and tracking oriented.
This is an opportunity, we think, for other companies to extend the way they work and make the software custom to them. Buzz is the shared infrastructure, the shared communication system that is kind of core to building that dataset that we talked about of how your company works and what people are building together. Plug-ins can tap into that dataset and extend the workflows that you want to do and the way you want to work. I think that kind of brings it together to Alex's and Hans' point. This is a collaborative interface. Everyone can build on it, and it makes it something that anyone can contribute to. It is just part of working at Block and the way we work together. Okay.
With that, I am going to hand it back over to Lucas, who is going to explain how you can go try some of this out. Thank you.
Awesome. Those are some really, really great sessions. Like I said earlier, we have about an hour and a half for folks to walk around the venue. In the exhibit hall over there, we have stations from our partners, Cerebras and Databricks, as well as the stuff that John had mentioned. We have Goose, and we have our Brand Hub, and then we also have a security station over there. Across the hall, you can find the Agent Studio, so you can create your own agent cards, your own Gloopies. Finally, over in the back, we have the breakout rooms and demo sessions where we are going to be. We have a bunch of the team here to show you all how we use Buzz, how to build apps, how to build plug-ins.
There is going to be demos going on and a bunch of breakout sessions for you to explore. Then the last thing is, we will come back here around 3:30 for the Q&A session with Brad Axen, John, Alex, and Jack. A bunch of the team that worked on all of these tools is here today. If you all have any questions, please do not hesitate to ask. Most of us have a little Buzz sticker on our tag. Ask us, and we will be happy to help. Thank you all.