← Just Now Possible
Just Now Possible
Building Banani: How a Canvas-First AI Designer Is Raising the Floor on Product Design
01:10:10
Loading summary
Transcript92 lines
- [00:04]
A
Welcome to Just Now Possible with Teresa Torres.
- [00:09]
B
Hi, my name is Vlad, I'm CEO and co founder of Banani. In my previous life I was designer for more than a decade since I was teenager, won few competitions from Telegram. When I was 18, joined one of the fastest growing Ukrainian startups preply where I essentially became a lead designer. Tried product management and yeah for the last few years with the Kazari with Vova we're building our own products and are building our products.
- [00:35]
C
Hello, my name is Vova, I'm co founder and CTO at Banani. I'm building product here and I'm responsible for every technical decision. Before that I was building almost everything that is possible like starting with trading bots for stock markets and creating applications for augmented reality. And eventually I've met Vlad and we decided to be a co founders and this is how Banani started.
- [01:04]
D
Hi, my name is Vlad, I'm founding growth at Banani where I am responsible for acquiring, working with our customers to solve their problems and retaining them. And in my past life I've been with Google where I was doing marketing and investing in startups.
- [01:21]
A
Excellent. Okay, so tell me a little bit about Banani. What does Banani do?
- [01:26]
B
Yeah, of course. So essentially we try to build AI product designer because audience know how hard it is to design user flows, come up with best UX solution for certain feature, new hypothesis and so on. And in simple words, we try to automate big part of the design process and help you get to the great and beautiful design much faster. This is where we are but essentially our goal is to build a fully autonomous agent that covers everything related to design inside your company. Something that can be your creative companion. If you're a designer yourself and you still want to design things manually. Yeah, and we're roughly one year old but already at the scale where hundreds of thousands of designs generated per week and yeah, have a lot of cool stuff that we already built and that we're building right now.
- [02:21]
A
Yeah, I'm excited to get into your story because it's a very unique product compared to what we've had on the podcast previously. Vlad, I'm curious personally from a founder story, you were a designer. I'm curious what motivated you to create an AI designer? Do you have any fears about putting yourself out of a job?
- [02:40]
B
Frankly speaking, I think I dreamt about something like Bananji when I was designer myself. So I had experience working as a freelancer later on in startups that went from seed to, I don't know, cdsp, cdsc and there are a lot of parts of the design process that are mundane, that can be automated. We together with Huawei, before Banani, we actually were building a consumer mobile app, an ecosystem of consumer mobile applications. And together we saw how design can be also a differentiator for your product. So this one of the things that kind of was constantly brought up by our previous users in that startup. And yeah, we just want for the world to have more access to get to the great and quality user experience, user interfaces.
- [03:34]
C
And yeah, I want to add that it turned out that with current product people also share with us that kind of the way our product looks is a differentiator because it is so easy to use compared to our competitors.
- [03:49]
A
Yeah, this is something I'm really bullish on design being a differentiator in the long run. Like I actually don't. Even if we have AI designers, I'm not convinced we won't have human designers. I like this idea of can we raise the floor? Can we improve the quality of design overall? And then maybe that allows designers to focus on the harder, more interesting problems rather than just the next workflow that we've done a hundred times.
- [04:18]
B
Yeah, exactly. I think there's kind of irreplaceable parts on the human side, which is empathy, being able to and that dive deeper into the problem. But as I mentioned also like me having experience in preplay where at some point it was only me and a couple other designers for 60 people, product and engineering team. Sometimes you just need things that can help you go through creating thousands of screens in a day. And yeah, this is one part of the problem. And as you said, raising the floor is also a big part of that. So nobody likes to use pet products. And there is a lot of conversation about AI slope and like how AI essentially turning everything into something similar, something that is not looking good. And there is definitely big aspect of that in current execution and that's what we're trying to solve with Bananas to make actually something tasteful. But also if you look on the market, kind of on the median on the market, like there is also human slope and there is not a lot of conversation about kind of what is average experience where you with the average system. Obviously there are cool examples like linear like other products that you know, beautifully designed. But if you take on average oftentimes also like what we see from our customers, like solo founders, early entrepreneurs, smaller startups, they simply don't have access to the talent, to the skills. And yeah, I think there is a lot of exciting things coming from different directions, kind of raising the taste bar and the mark, but also kind of helping people who previously could not be able do things that they can do now.
- [06:11]
A
Yeah, that's great. Okay, so I am hearing a very clear need and like really driven by personal experience of how do we just have more beautiful products, more really well designed products for those designers that are stretched thin at so many companies. How do we help them with just producing more designs? How did you identify this was a problem that AI could help with?
- [06:37]
C
We clearly saw that AI definitely can help here. I think we were just aware of the fact that we were at the right time because GPT just recently dropped and we understood that AI is going to evolve, it's going to evolve into something huge. And this was one point and I think second point was the fact that before GPT and LLMs you had to be a real math scientist to kind of work with AI. And this was a really important thing because like you needed to understand like statistics, probability and stuff like that. You needed to know how to build all of these models with like on your own, using Python and stuff. But suddenly everyone could start building their own stuff. And what we saw is that even though as Vlad mentioned, we don't really know till now is AI has their own style and understanding of emotions and empathy. But what we clearly saw is that in design you still have a lot of automations. So we understood that we can try at least solve those problems and then we could try to see like how we can utilize it better. Because eventually at that point of time when we just had an idea, we, I think we wanted to have like a big community of real designers who would design a lot of cool, unique and experimental stuff for us and, and we would try like to do some machine learning stuff and train our own models and build like really unique designs. But turned out that the way how LLMs evolve, how big companies like develop them and I think right now it's more the question like how properly you can utilize everything and if you can
- [08:50]
B
keep up with the market basically in for a lot of companies and products there is kind of a right time when technology is available and enables do certain stuff. For us it was definitely LLMs and we kind of saw in different areas what they can already do. So I think the first proof of concepts we were doing like two years ago, year and a half ago when we were just like playing and looking what, what can be done and just seen from the, we already knew the problem space quite well at that point. What are the problems of product, teams of designers. Once again we were building 10 people team that we built in our previous startup, like both me and Vova and like I had experience in the product team so like we kind of knew the problem space and main bottlenecks I would say. But back then tech was not ready and we saw a lot of demos on the coding side that something is finally possible. And it wasn't the question if it's AI product or not AI product, but more is it already at the. Is AI already at the point where it can be actually applied for this type of stuff that we wanted to experiment with. And yeah, we had multiple iterations to make it work because two years ago base foundational models where they were completely different beasts and things compared to what they are right now out of the box. And yeah you back then you would need to do a lot of kind of workarounds to get to some at least like basic good results.
- [10:28]
A
This has been a theme on the podcast of for a lot of teams that started early in the GPT days of like how much they had to do that. The model kind of ate up over time as the model got better and better and more became. That's the name of the podcast, more became just now possible. So I really like this mindset of you knew your problem space, you saw this new technology, you could see how there was an intersection. Building an AI designer sounds really big. I'm curious about what was your first step? What was the first piece you decided to focus on?
- [11:06]
B
Yeah, as I already mentioned, we made proof of concepts to just see if it's feasible to do design generation. Yeah, it was, we built, we built on top of existing platforms. Like our first kind of working product was plugin for Figma because we just wanted to purely test how generation works without kind of app layer infrastructures that is required to render all of this give you more advanced features like that we basically have inside our products already right now. Yeah, so the first step was building proof of concept of if design generation can work at all and if it can be good because like even in the days of GPT 3.5, I think three, you can already generate some basic HTML pages and layouts. But like once again we did like some shenanigans and orchestration to get it to some base level where it's possible by real designers, by real product managers and where it actually brings value and can be used. And from there on, after validating that the tech is feasible, validating that we just for this simple Figma plugin, we Receive organic users. It was the first signal that okay, we can try build a full on product that takes more and more pieces of the work and kind of reimagines the whole workflow of how you design stuff.
- [12:34]
C
I wanted to share like my personal feeling about that because yeah even though we were building this Figma plugin for me like real aha moment was I think when we came up with an idea of like we can write a text prompt to generate on the first screen and then if you can click on this design and this would call like some function and next screen generation would start. So basically you can generate the whole flows but you need to write on the a first description. That was kind of my own aha moment of our own product. Yeah.
- [13:13]
A
So just to make sure I understand that your customer would start with here's a prompt of kind of the screen that I want. Your product would generate some HTML, some CSS that would produce the design and then from there they could click on the design and that would generate the next step in the flow. Oh, that's very cool.
- [13:36]
B
Yeah that was like Boba prototyped this feature and this was once again we were just poking around ideas how things can be reimagined for kind of this new workflows that we have. And yeah after also getting feedback from our users that okay like this is something cool, it was also like a nice signal for us that you can bit by bit start introducing new interactions that currently not available from the UX perspective. And yeah that there is quite big space to just once again reimagine reimagine the workflow outside of putting the chat box into familiar product interface.
- [14:18]
A
So yeah, it also sounds like that very first prototype you stumbled into a really nice distribution channel as well of the Figma plugin, helped you find your earliest customers. Is that true?
- [14:32]
B
Yes, yes. It was essentially our first growth channel before we full on switched to our own platform. We're quite fortunate because most of our growth is fully organic. So it's 95% just by word of mouth integrating into existing workflows starting from the integration with established product that is being used to solve the problem that is used by users who have the problem that we're trying to solve. And yeah, it could backfire. You for example, Figma is playing very dirty lately because they're scared to lose market share. So they started very heavily rate limiting their API and essentially putting a lot of sticks into the wheel for like competitive like sub products to start. But yeah, definitely like I would recommend in the beginning Trying to find like some distribution platform place where your users are and like find a way to kind of start from there.
- [15:34]
A
Yeah, I think one thing that's in the back of my head is that you're playing in what's now a crowded space. It may not have been that crowded when you started, but we have a. We have probably half a dozen pretty big like prototyping tools. We I like Magic Patterns comes to mind of just focusing on the design piece. One thing I've heard as you've talked about your product is it seems like you have a very this in a positive way, like a very opinionated view. Right. Even this piece of you can click to generate the next frame to me is it seems like you're taking a design mindset to this. And I'm wondering if you've talked about. As this space gets more crowded, as Figma moves into this space which is the behemoth here, how do you think about what's your differentiator, what makes your product unique?
- [16:24]
B
I think what we internally see is that the problem hasn't been solved to the level that we see potential to be solved. I don't know how to frame it either way. A lot of tries from different sites. There is a whole new market of pipe coding tools is also used for prototyping. On the other side you have cloth code that more and more designers start using, which is extremely cool thing in my personal opinion. And on the other hand we have Figma which tries to kind of integrate pieces of AI inside their product, but none of them and their direct competitors like Magic patterns. But essentially nobody solved the problem of generating actually good, tasteful, beautiful design. So where the model is understanding the main concepts of how things should look like it could replicate your brand. And second piece of that is kind of app layer. Nobody solved the new way to interaction to creating design. Once again, cloth quote and bytecoding tools, they're very unnatural place for designer and product people to hang out. That's what we hear from our users that like you want have the freedom, you want to have the freedom of chatting with an agent, exploring different variations and so on. But you also want to keep the UX of the canvas and you want to have some new ways to generate designs and screens and so on. And yeah, nobody solved it correctly yet. And the good thing here is that the market is extremely big. The just purely product development, product design market is growing dearly, very hugely. Dramatic shifts can happen in couple of years. If you look at the example of Figma, for example, like it it took them like kind of three years to fully move all design teams from sketch because they had quite big unlock on the collaboration side. And yeah, another problem that we see is that a lot of the products, they essentially come in from the coding side. Once again, this is not like we really respect all of the competitors, but for example, magic patterns and other stuff, they pretty much in a lot of ways developer focused. Today, to give you an example, we had a big internal discussion, okay, how we should implement reusability and components. And there is kind of natural pull to adopt the, the development and coding paradigms. Like when everything that you create is already component, you essentially move in the easy way of what agents are capable and trained on foundational level. But it breaks the established behavior of designers of product managers who still need a lot of specialized tools and interactions for themselves. So once again, kind of long story short, we see that the market is huge, the potential to change the workflow is huge. Nobody yet solved the beauty taste plus a player combination where it kind of disrupts the space.
- [19:46]
A
Yeah, I like this. I do think the market is huge and probably continuing to grow at a pretty fast pace. So I think there's plenty of room for many players. And then I really like your focus of a lot of these tools really are developer focused. And I think design in particular. Like I know there are lots of designers who code, but they probably aren't thinking of their design in HTML and css. They're starting with design and then maybe implementing them. And so what does that design first interface look like? I really like that. Okay, let's get a little bit into what does your product look like today.
- [20:27]
B
So you can imagine it as you have a preform canvas where you can spin up an agent that can generate a design for you. If you use Sigma Miro, any canvas based interface, you would be very familiar to this type of interaction. But on top of that, we have an agent that you can forward to create design, to edit design. You can do multiple variations like in parallel. You can edit multiple designs in parallel. This is like something that differentiate us from pipe coding tools. Like instead of waiting for kind of design is very chaotic because you spread out and then go to the point and we support all of those use cases. So you can in parallel send prompts to edit multiple screens. We have split specialized features that we already mentioned. Like you can click clickable things from the user perspective and we'll try to predict the user flow. So essentially you can quickly prototype on canvas and generate new screens by simply clicking and Right now we're kind of exploring a lot of agentic interactions so you can spin off banana to work longer. Think about your design. Like we for adding a lot of new integrations like mcp. You. You essentially are not locked in inside the tool and you can allow your other agents to interact and feed you info and for us to fit your design. And yeah, you can imagine it is very friendly to designers and product people. Tool that is specifically made to quickly prototype fidelity, low fidelity, high fidelity designs. Yeah. And like everything that you can expect from 2026 product like sharing team features and so on. But that's not fun. Let's talk about them.
- [22:17]
A
So I think I just realized as you described to this is being a canvas first tool is already a very big differentiator. Right. Like a lot of these tools, you start with a chat window, it's producing code, you see the design almost as a static thing. It sounds like from what you described, your users can add elements to the canvas, edit things directly and there's this AI component on top of it, is that correct?
- [22:47]
B
Yeah, we try to every day is a risk and question, okay, what things we want to hand off to AI, what part of the work we still want to give user the ability to do manually. I think that's kind of what a lot of AI first products have in mind right now is kind of how far you go one or the other side. So yeah, like your summary is pretty correct. But just to add to our long term vision and goal because there are multiple layers of the product, there is kind of a part that is doing generation like orchestration of the actual AI. How it makes a decision to generate something, to use some component, to use some color. There's big part of the work happening on that side because from the same model you can get completely different results with different once again agent architecture and like tools that it can use. And second big component is like app layer and like actual interaction.
- [23:49]
D
So yeah, I think there is one core question that we come back in the team to frequently which is what if the AI is not here to replace. Right. The product designer in general, but rather to be be autopilot where the designer is still in the driver's seat, but when he needs or she needs to to switch to autopilot, they can do it.
- [24:09]
B
Right.
- [24:10]
D
And this is the way we are trying to design Banana and a lot of features, they are coming from this perspective. Right. So the variance and the ability to spin off a few variations and then take it from there. This comes directly from designers who really want to have this perfect balance of control versus AI.
- [24:30]
A
Yeah, this is a pain point. I hear a lot with the prototyping tools, even just getting it to use the design system or their component library. I remember when lovable finally let you like click on something in the design to just change a label on a button because it was such a nightmare to try to get the agent to do it correctly. So I can definitely see the power of letting the designer drive with the canvas and then using the AI to augment and let the designer decide, okay, generate this next frame.
- [25:00]
B
And I can even add to that that depending on. That's the thing about design process is that on different stages you need different job for AI from AI. So for example, when you kind of in early exploration stages, you need AI to be more creative, help you spin up multiple different like even visual variations. If you're just like starting the products from this era and kind of you maybe need some help in brainstorming stuff and like moving on to the later stages. When you have something established, you want the agents to be very flexible in reusing what you have. And on those like different stages of even like when you prototype and come up with some new feature, like you might need a different kind of degree of autonomy in your involvement. So for example, when you already have PRD of the feature, we don't want you to spend the time and you already have like component system and like example screens. We don't want you to just waste time and kind of manual labor of assembling the screens. Like we want to have like full on autopilot where you can write. This is not something that we have. But I'm just planning to ship relatively soon like integration into your workflow so you can when you trust the thing to do and like prototype some flow where there is less uncertainty, you just tell it to do. And like you in the end have a link or like images in Slack that you can see. But when you in this early stages of exploring, you want to have more degree of control and kind of involvement and like actually use the product to do things yourself. That's like another thing that we basically see not solved yet. And all parts of the design process kind of tried to be treated the same when in reality they are not.
- [26:52]
A
And yeah, yeah, I could see a ton of time savings in that sort of production step of like the thinking part of the design work is done and now it's just we have to skin and use comp shared components and shared churn through all the screens which I know is not most designers favorite part of design.
- [27:15]
B
Yeah.
- [27:17]
A
Okay, let's get a little bit into the technology here. I can see how in some ways I can imagine how you could start small with you have AI that's generating code and there's already a model for this in terms of like other products have done this before. Generating code is one of the easiest. Was one of the earliest like use cases for models. But I also feel like this has been one of the hardest areas for models to do in a way that just doesn't look average. And something that I've heard in everything that you've shared so far today is that you are aiming for high quality design. And so I'm really curious, like how do you think about this just architecturally, how are you getting what do you have in place that makes this makes sure that you get that higher quality design?
- [28:05]
B
I think in a lot of ways, yes, like it's relatively easy get something average out of the box. But it takes some trial and error just playing with a base model with a context to get to some level where it starts to follow some of the initial design principles and guidelines. So there's a quite big room just from the context engineering that you can get from the base model. But this is if we are talking about 2026 state of the AI models and agents because once again, a year ago, like nobody, like I don't remember a year ago agents existed on like toolkit. Right now it's more about once again what kind of specialized tool you can give to the agent so it produces something better quality. So for example, if you have a plain coding AI assistant, you just can't afford to give it tools to, I don't know, go look up for image references for the designs and given a lot of more specialized, not skills, but actually tools to AI that help the job to the end design to look better. And there is, we don't, there is no like easy way outside of just trial and error. We experimented pretty heavily on all stages of the company. Like even right now when like when each new model comes out, you need to get a taste of okay, like what it can do, where it's good, what things should be kind of fixed with additional context engineering with additional post processing. And yeah, to give you an example, like early models they were quite bad at some alignment problems and like other stuff. And like you try to find workarounds. Okay, how in current state you can fix this with post processing with some additional things built on top. And yeah, what other thing is that we see that design is very once again like just coming back from the human process. It has its own special needs. You have parts where you kinda just on the research side like you decompose and stuff, you think about the user Persona, all of the stuff. And you can teach similar thing to an agent, giving it specialized things so it can produce the job better. And yeah, another big aspect is just experimenting with different output formats if it's plain HTML, CSS or with some specialized schema. So for example we tried multiple approaches moving on from very predefined component based generation when it was highly curated by ourselves because we trust in our own taste and kind of experience of how things should look. So this was one of the first approaches where we were just reassembling components that we made on our end. And like we were asking LLM essentially it wasn't even a code or it was a markup that we came up ourselves and that we later on rearranged. But with each model deep you have new unlocks and you need to rethink. Okay, what should we remove, what should we rework? And yeah, current approach is like that we use is completely different from the one that we had even like in July. Yeah and I think one of the like recently we integrated image generation directly into like main design generation process which is another big component of visual style, of how things look aesthetically. And there are like so many smaller things where you can make tweaks and tune the system as a whole for it to feel a little bit more tasteful, a little bit more beautiful. And yeah, what we see already at this stage is that at some point it would be really nice to have our own specialized models that focus on specific parts of the output. And yeah, but this future.
- [32:18]
A
One thing I love in your answer is what comes out a lot is this element of craft. So I think there's. It's really easy for LLM to get to 60% good. If I'm going to be optimistic, I might say 80% good. But there's a lot of craft in getting to that. What would like the best people consider good. And I think what's hard about AI products is it's hard to communicate the work and the difference in that last 20 to 40%.
- [32:51]
B
Yes. I would say the problem here is that on a human and user side you have professional designers that oftentimes have an understanding of how things should look like and they can tell if something is good or bad. And very experienced people, they can quite quickly point out what is wrong with the thing. That I'm looking at and what we just discovered over time, that the less experience you have, the harder it is to pinpoint exactly what is wrong and what needs to be changed. And it's like natural for a human where you, the more experience making something you have, the better you can pinpoint those things and make this overall feeling of crafts visible.
- [33:42]
A
Yeah,
- [33:44]
B
but yeah,
- [33:48]
A
you wanted to jump in.
- [33:49]
C
Yeah. You mentioned one thing and it reflected with me. So we see clearly one huge problem inside of AI human interaction. Even though LLMs are becoming smarter and smarter and right now they're doing crazy things I couldn't expect them to do like nowadays, to be honest. But what we clearly see is that we have this huge gap between how people communicate with LLMs and agents and that how agents can comprehend all of that stuff. And you know, it's like it's okay ish when you write in code, but it's not okay when you're building design because simply like our users and agents, they just speak different languages. And I think it's not even a technical bottleneck, to be honest. And this is what makes like Panani extremely interesting for me. And I think this is the part why we decided to build this feature. Like to you click on design, you generate next steps. Like we, we are sitting on like just on the first level of how LLMs and agents can evolve. And I think the real gap would become smaller at the moment when we understand like what is actually the best way to interact, what is the best interface to communicate with the agents? Because when you see something on the screen and in its visual element and you try to describe it with words, with text, it doesn't work like that. What we are trying currently to experiment with is to kind of make our agent more proactive and like it's not you who set up the task and then you try to change something, you give the initial thing and then the agent asks you questions and this is the main point where you can like I think keep up with it and understand what like user actually means and how agent understands you. Because like you just need to align on things.
- [36:11]
A
Yeah, yeah, this is, there's a term for this. Have you heard the term the gulf of specification?
- [36:18]
C
No, no, I forget the model.
- [36:20]
A
I'm going to find it and I'll email it to you. We'll also put it in the show notes. But it's a model where it highlights three different areas where things can go wrong when we interact with agents. And the first interface is the humans specifying to the agent and that for a lot of problems, that's like when you do evals, that's where like a lot of the error classification, the failure modes end up is that we're not speaking the same language, especially when a human has to describe visuals. And this is. I can see so many areas where there's technical challenges in what you're doing, but this seems like a great one to dive into. First, do you want to share a little bit vova about what you're doing? You mentioned the agent will interview the user a little bit. Do you want to share a little bit about just what you've had to put in place to make that work?
- [37:04]
C
Well, yeah, yeah, of course. So like we always try to start small and then just to iterate things. And so basically how we see it right now, like currently Banani is just like you type a prompt, you press enter, it does something for you and that's it. It's super easy and I think this is why people love it. But what we want to introduce is that special kind of looping mechanism where if the agent clearly understands that it doesn't understand you, it can ask you a question. And it also a bit like complicated to kind of describe from the agent perspective what it meant too. So I think what we want to do is to kind of maybe highlight something inside of your canvas, highlight like specific element on your screen, on your design. Like, do you mean that and do you want to change it like in that way or something like that. So I think this is as a step one can work pretty well.
- [38:15]
A
Yeah, yeah, I can see that being both ways. Like the user can highlight something on the canvas and be like, this is what I'm referring to. And the agent can highlight something on the canvas to confirm.
- [38:26]
C
We already have something like that because even though you're working with the whole screens, but we have a special function that is called select and you can basically select the elements and describe what you want. And basically like the agent would know that. Okay. User mentions like specifically that part of the screen.
- [38:49]
A
Yeah.
- [38:49]
D
There is also another aspect to it from the behavioral. Right. Standpoint. The users frequently, they don't even want to go that way where they select the element. They want to have a very quick ability to choose from predefined actions that they have in mind. And basically the way we worked with that, we've found I think seven or eight actions that are most used by our LLMs. And we now give the users the ability to really quickly, in two clicks fix what they don't like.
- [39:20]
A
On Canvas it's like what I have in mind is that you have your Canvas tools but you also have your agent like toolbar.
- [39:29]
B
I don't think like the Canvas AI interaction has been once again even if we didn't even scratch the surface of what can be done specifically with this interface. There is cool demo from off topic but there is a cool demo by founder of tldraw. It's an SDK plus whiteboarding platform and they have, they do interesting side quests for TLDraw and he recently had a demo where you essentially have a ferris that you can send to do a specific task on Canvas. And it's almost as if you play like a computer game where the strategy computer game where you select something, you send something and that's once again the cool thing. What excites us is that there's so many ways to implement this stuff outside of regular chat box on left side of the screen where you kind of just lighten it, tell it what to do.
- [40:26]
A
And yeah, I feel like the UX of like you get to interact with a Canvas. I'm assuming you can also talk to the agent. Is it both? They can mix between the two Right
- [40:37]
B
now no, but soon it will be. We initially started like that we had essentially a chat where you could have a back and forth conversation but we quickly found out that. So also for the context like we have users who have hundred screen like on the canvas and it's one thing it's hard to maintain and allow parallel threads of editing to be happening at the same time when you also need to maintain mental model of okay, I have chat with this thing like where this chat is stored. So there's compromises you need to make on the UX side. So for now at some point we decided to just kill off just conversational states to allow parallel for our agent to essentially do a lot of stuff in parallel. But right now like we like we right now exploring the ways how we can make it back to the platform. Because I think from the user interviews we constantly see people just having ChatGPT on the side and like talking to it and then like copy pasting like some of the like specifications that ChatGPT created back to Banani. And yeah, it's a recurring pattern. So like it gives us once again another indicator and like signal that we should play around that area. But yeah, but underneath it essentially you can imagine it doing all of the thinking you have like in clothes or in ChatGPT where you use thinking models. It does all of that but without over blowing you with text information because once again you really focused on a lot of the visuals that are happening on the canvas.
- [42:16]
A
So the user is primarily interacting with the canvas.
- [42:20]
B
And then you have a prompt box where you can type the prompt. Or we have a quick actions that you can very two ways. One way is to use the prompt inside. But also we fully support your design without any prompts. So as Vlad previously said, we have variation shortcuts you can click on the screens, we get your feedback if you dislike something like launch regeneration from pre selected options. Like you didn't like the typography, you had some alignment issues. So we try to keep both ways of interaction, like trying to intertwine them a little bit.
- [43:03]
A
But yeah, okay, let's get under the hood a little bit. Like I think you, you have this really great UX experience of everything is being driven through the canvas. But you have a prompt box. I've heard you several times refer to the agent, but and I've also heard a lot about tools. So let's talk a little bit about what's happening behind the scenes of this canvas. Tell me a little bit about your architecture.
- [43:27]
C
Okay, so like I think people sometimes miss, to be honest, what is real agent and what is not. And they expect to see like something as a message history or like agent communicating to you or asking you questions or stuff like that. Like event. The agent is just a type of architecture and what it does is like if you ask it something to do, it might take multiple steps to accomplish this task. It can also loop inside of like this agent itself and then come back to you with a response. And so the way our agent works is that we have like couple of steps before we start generating and after we finish generation. So first of all we need to understand what exactly we are generating. Is it like a full blank screen and we generate an from scratch or do we need to make some edits? Then we are trying to understand like okay, is there anything we can get from the project or maybe from the user, like some themes or some references or stuff like that. And we are making our agent like to start this reasoning process of okay, what should I eventually generate? And we start streaming. At the moment when we start streaming we are trying to our users because I think this is kind of tricky part. And when we are talking about our competitors and what differentiates us from them is that they all are building applications under the hood. So everything that you see rendered is just real application. But what we are trying to generate is just like a Mock up, even though it's just an HTML and css. And that is why we can make your experience a bit like interactive because you're not just waiting and seeing like loading spinner or something like that. You actually see how your screen is being generated. And I think this is really cool. So another thing that we have inside of our agent is an ability to split your prompt into multiple steps if you are asking to make some changes inside of an existing design. So basically imagine that you have a mobile application like Instagram, like and you have there your profile page stream and you ask like, okay, can you change the avatar from rectangular type to circular type? Can you change the font size of my name? And can you change how like the row of images look like, like not three images in a row but four? And so instead of regenerating the whole screen, our agent would split it into different steps and it would kind of inject these changes directly into your screen. And you can see it also like being streamed and in parallel we also generate your images. And what else? I think that's it.
- [47:05]
A
Yeah, I hear a lot of parallels with Claude code, right? Like I'm generating my to do list, I'm working through it, you can see. But for you it's not I'm editing files, it's I'm editing things on the canvas.
- [47:20]
C
It might evolve into something like editing files. Yeah, but yeah, I think the main difference between like our agent and Claude cod, for example, is that for us it is extremely important to save all of your session history. So like in clot code you can just open new tab and you work in the same code base and you're typing and you asking for different things and you can experiment and if you accidentally closed your tab, you lost all of your results for us because each step in design it was your own decision. And if you created something and it didn't work and then you kind of disliked it and then you duplicated screen and asked to make some changes. We want to see every of this step inside of the history and we want to share it with agent because this is how your decision chain look like. And this is really important because even though if the agent generated you something and you didn't like it, you can ask to to revert because we have all of the history. So it's kind of similar, but only because we are not generating applications, we don't really need all of the stuff that Cloud Hot has under the hood. And so we are trying to utilize all of the capabilities of the agent. Like in A bit different way.
- [48:58]
A
It sounds like though, you must be doing a lot to maintain state and history. So just in terms of, I'm curious about if the canvas is being generated with code, you must still have some separate system for just that history of actions taken and decisions made. And I know talking to a lot of teams, a lot of work goes into how do you maintain that state, how do you maintain that history?
- [49:27]
C
I think like when you're building an AI application, this is the most important thing to think about. The way you handle your context, the way you manage your context. This is kind of 99% of the success of the result. And I think one trick that I can share is that not everything that happens under the hood and not everything that we share with our agent as a history of the session is actually like a tool call or something like that. But sometimes we mention it to our agent as a tool call because if you're not confused your agent and all of the data is consistent, it is easier to understand. And so yep, you don't need to create like different multiple data structures and share them all with your agent. You can just tell them like, like this was tool call, like to get some context about how your project should look. Like this is a tool call that is called when you need to understand like what is the main goal that we are trying to solve with this design and so on and so on.
- [50:52]
B
I can quickly add to that because you mentioned a lot of similarities with cloud. Cloud, but kind of if you look at the whole agent, AI agent market or like set of tools, underlying architecture is most of the time the same. You have some information stored. Your agent needs to be able to read the information, make some manipulation, create something. But kind of the devil is always in the details. Like what specifically? For example, for legal agent, you need some specialized tools and like some additional context to focus on like some specific parts. Like in, in our case it's also there are a lot of differences from like actual quad generation.
- [51:36]
A
Yeah.
- [51:37]
B
Because for our case, like for example, we don't care if code generation runs or not. So we don't need, we don't compile actual running code. So we can not focus on that part. But in our case, in the set of tools that we are creating for the agent, we specifically focus on important pieces of the design process. And another big part is post processing. We need for all of the icons to actually exist that are in the design. So you need ensure to have those extra validation steps where the agent hallucinates, because it will hallucinate and produce something not good. And I would say that 50, 50 work between once again, how you orchestrate stuff and what things you provide on the app layer. And yeah, like combination of both of those can make or break it for your products, for your company.
- [52:41]
A
Yeah. One of the things that's been fun about doing this podcast is seeing how many similarities there are across products that are in wildly different domains. So there's these patterns emerging. But then I think you're exactly right, Vlad, where the interesting parts are very domain specific, very use case specific. And where I was going to go next was asking Vova about, I imagine to make your agent really effective, tool design is a big part of your product design. What tools do you give it? What tools do you give it when how do those tools work? And as part of that, just managing that, like you said, the context of. I heard Vlad, you say earlier they could have hundreds of screens on one canvas. What are you giving the. How are you steering the agent towards? We're working over here. This is the part that's relevant. What can you share there?
- [53:31]
C
Like, to be honest, I don't really think that tools are the most interesting part of the agent because like every agent, it has 90% of basic tools that just keep it alive. So like where should I look for data, how should I look for data and stuff like that. And so yeah, I think the most important tool I've already mentioned it is something that helps us to make this tiny surgeries inside of our screens. Like when you want to edit something and you don't need to regenerate the full screen and you make like smaller edits inside of it. But other than that it's just like regular stuff, you know, like connecting to the database, looking to other screens, looking into the context, looking into their themes and styles, et cetera. So to be honest, nothing special here.
- [54:33]
A
Okay.
- [54:34]
B
Like it's. The general rule of thumb is that you should have as minimum tools to not float the context.
- [54:43]
A
Yeah.
- [54:43]
B
And I would say on our end like a lot of work is still done on the context engineering side. So once again just having we have essentially a sub tool to generate a blank screen and a lot of the team work is on iterating it into looking how it works with the models, finding some patterns of what new models can do or can't do, rewriting the generation context to properly utilize it. And yeah, here it's once again like you just need to do a lot of. We don't have evals like in traditional sense where we have a set of that we can compare to, but we have kind of small set of like internal evals and like we can spin up 10 screens from one prompt, like when the new model comes out and kind of compare wipe wise where it fits and like what should be fixed. Yeah, the hardest part is. The hardest part is, as I mentioned, also like keeping the history relevant to the agent and deciding, like, when to summarize something, like how to store all of those summaries. Because once again, even though we don't have chat, like it's common for you to kind of ask, okay, you previously did something X, can you do something like X, but do Y? So like keeping this history and kind of natural flow that you usually have this feels.
- [56:15]
A
One thing you've talked a lot about is the designer in the driver's seat and then the agent also acting on the board. And this idea of Vlad, I think you even dismissed collaboration as just something that's required in 2026. But I think what's interesting is your agent is almost a collaborator, just like another teammate might be a collaborator. And I'm curious about this exactly. This context problem you're describing of your canvas could have a lot of things on it. I feel like humans can open a busy canvas and orient themselves and figure out where to work. But I'm curious what you have to do behind the scenes to make that possible for your agent.
- [56:53]
C
This is basically why Vlad mentioned that creating a full chat history is a bit tricky because the way it works right now for us, and I think it's easier to imagine in a way how our canvas looks like. So inside of our canvas, we have just like multiple instances of screens, so just screens. And we have a sidebar with a screen list and each screen has their own version. So basically, if you work inside of one screen and you make some edits, you can revert anything from that. And when you click between screens, this is the moment when we actually collect all of the needed data and form this context into the history. And so for each screen we have kind of different history, but all of those screens, they share similar context, similar stylistic references, similar goal of the app, of this project, what exactly should be done. And so that is why we can't just present all of this history, because it would feel a bit broken to the user, because at this screen we have this interactions, in this, we have this interactions, and it doesn't feel fulfilled.
- [58:23]
A
You know what I like about that is that it's almost like you're creating lots of context windows, which is really great. But it feels like it also poses a problem of when your agent has to work across screens.
- [58:37]
B
Yes, once again, good things. That context window is increasing the amount of time like the loop what I mentioned before, like when agent can come circle back and make a decision. Okay, here I'm stuck. The duration is increasing. Cursor had the swarm of agents that was working for three days. So kind of it's. There is less problem of, okay, like how you make everything like compact, clear, but kind of how you direct the agent to pull up the information that it needs at the moment and like how you compress it to kind of fit in the context window and not the full context window. And that's kind of a separate problem on its own like when you build in this type of stuff and. But once again, the cool thing is that the context in last year context windows increased. The time that you can spin off an agent increased. And just overall trend line. Right now in our work, we make a lot of bets on where the models would be in half of the year. And sometimes you need to wait out for certain things to happen. Sometimes certain things can kill you. But you can't work without making it some sort of hypothesis. Okay, where things would go in the next half a year. And I think with a lot of stuff we're trying to sometimes put something back because we 80% sure that it's going to be solved and focus on those fundamentals that we don't see being solved.
- [60:23]
A
This is a piece of advice. I hear a lot of people talk about this idea of you want to be building on the edge of what's possible today, not in the realm of what's possible today. But I'm curious about what nobody really talks about is how they make those decisions. Decisions. How are you judging what might become just possible in a few months or with that next model.
- [60:45]
B
Right now we already have quite a lot of. We already have historical data, okay, like where things kind of trending towards to. And it's much easier to make those judgments like right now than like it was two years ago. But you just overall look at the trend line of where things are going. So for our case, we saw that kind of with a trend line a year ago, models have no spatial understanding at all. They could put one thing here, one thing here, don't align things. But with each kind of incremental model it improved and you kind of see the trend line. Okay, probably sort of like smaller things like alignment issues, like they will be solved in a year and you need to focus kind of on the bigger problem of okay, like how we orchestrate this thing as a whole where like alignment is not a problem and like where you actually need to combine images for the design and you need to focus on like other stuff that you know, on the orchestration level that the models themselves won't do because they aim for like much bigger general intelligence that we as a player already kind of tuned to do the task force. So I don't know if it's like
- [62:10]
C
I just wanted to share my own experience of it and I think it's kind of bit of an advice to everyone who is building something. It's really important to, to dream of the things that are not even possible. And I think this is how you should create your vision of the company. It's not always about what should and can we build today. It's always about I would love it to be in two, five, 10 years. And so when you dream and you have the solution, then you try to align your dreams with the reality and at some point they are intersecting. And so this is a great approach, I think.
- [63:00]
A
Yeah, it's almost like you're pulling the future forward, right?
- [63:05]
C
Yep, something like that. And also answering to this question, like currently what I'm seeing and I'm expecting to see in the next couple of months something related to like post Open Claw app. So I think we would see some apps that can work locally because it unlocks a lot of things for the apps. For example, the way how we can store the context history and memories. You are not constraint of the servers and databases. You can store everything you need on your local machine and you can fetch it and grab it like instantly and yeah, it already feels like a future.
- [63:55]
A
Yeah, for sure. Vlad, I want to go back to the example you gave because I can see this example of we see the model make alignment mistakes, but we also see it getting better over time. So we're not going to focus on that problem. We're going to focus on this higher order problem. But pragmatically like your user, especially if they're designers, they're going to see that alignment problem and be like, this is no good. So how do you balance those two things?
- [64:22]
B
There are two ways. You can fully ignore it and you can add some temporary workarounds. In our case, I think we did both. We saw areas where there is improvement, but we consciously decided we, we know this is not good. This is not. If we were living in the ideal world, like we would not generate design where the button is misaligned with an Icon near it. But also you need to think about unlocks that you already give to users in current state. So even with some alignment issues are the days for our product, it already unlocked quite a lot of users and teams to once again spin up some mid fidelity design. So it was used for quite a long time as like low fidelity mid fidelity prototyping. And on the other side like we immediately gave some features for you to actually fix those issues. So like we know that our users, they use figma. So one of the first things we did is to kind of keep in the workflow that you already have is like Figma expert. And we know that if you see the problem with icon and like you see a speed unlock and kind of workflow unlock for you like on that side, you will copy design to Figma and you're gonna fix this like one small issue. And we are making a bet that we won't have such things in the next half a year and we're not thinking that okay, we should stop our work and yeah, because when the inevitably like certain things are solved, like you're happy that you are not over investing in this specific area and you focused on the fundamentals that don't change over time.
- [66:10]
A
I really like that because what it shows me is that you have a very clear vision of the value you create. So this decision you're making about what to focus on in the short run versus what will the model get better at is what is this core value. It's not about a perfectly aligned button. It's about being able to very quickly spin up mid fidelity design.
- [66:33]
B
Yeah, like I will add on our end that once again it doesn't mean that we don't aspire and don't see ourselves like generating something that the real senior professional designer would do. It means that we're essentially taking a real human being. When I started designing, it looked horrible. But eventually I learned some skills, learned taste and so on. And already at this point we see so many unlocks that can be done. And with new workflows we're putting more effort into experimenting like with existing models, with tuning like open source models and like trying to steer them in the direction that we don't see changed on the foundational models level. Yeah.
- [67:29]
A
Yeah, great. All right, we are coming up on time. For people listening, how do they learn more about Banani?
- [67:34]
B
Yeah, you can go straight up to Banani Co and yeah, you can start for free. Unlike a lot of tools in the market, like they give you enough space to kind of try things out, see if it fits your workflow experts without limits. And yeah, perfect.
- [67:54]
A
And we'll definitely put a link in the show notes. Anybody else, anything? Last thoughts you want to share?
- [68:02]
C
The real thrill for me is the moment when I understand that I can use the product I built. And so currently I'm building a Banana MCP server. So this thing would help product teams to hand off their designs easily to engineers, but maybe just like solo builders to build stuff. And so I had this design that Vlad design for me in Figma and I think I literally forgot how to work in this connection with Figma and writing code on my own because I'm doing so much cloth coding recently. And so eventually I decided, okay, maybe I should connect to Figma mcp. And then when I connected to Figma mcp, I tried three or four times and it gave me awful results. So like it was far, far away from the thing that Vlad eventually designed. And what I've tried, I've imported design from Figma into Banani. And then I was using Banani MCP server that I was building to create a final user interface for this Banani MCP server. And this was amazing experience for me.
- [69:27]
A
I like that a lot. Yeah, it's really clear to me that you're very passionate about what you're building and that you have a very high standard of craft, which is fun to see. And it's really fun to see how much attention you're giving this problem. And so I think you're. I can very easily see how you're going to achieve your goal of elevating design. Nice work. It's been really fun to hear your story.
- [69:52]
B
Thank you.
- [69:53]
C
Thank you. Likewise.
- [69:56]
A
If you enjoyed this conversation, please subscribe in your favorite podcast app and give us a rating as it helps others find the show. Thanks. I appreciate it.