← All AI Engineer talks

AI Engineer World's Fair 2025

UX Design Principles for (Semi) Autonomous Multi-Agent Systems

About this talk

Microsoft Research engineer Victor Dibia presents human-centered UX principles for semi-autonomous multi-agent systems, drawing on GitHub Copilot, LIDA, AutoGen, and AutoGen Studio. He demonstrates BlenderLM, a from-scratch agentic application that converts natural-language requests into Blender 3D operations, and emphasizes capability discovery, observable agent behavior, cost-aware delegation, and interruptibility through checkpointing, rollback, pause, and resume.

Chapters

  1. 0:00Speaker introduction and human-AI engineering background
  2. 1:23LIDA, early language models, AutoGen, and AutoGen Studio
  3. 4:29Introducing BlenderLM and natural-language 3D workflows
  4. 8:02Live BlenderLM demonstration
  5. 14:55Interruptibility, rollback, resource control, and closing resources

Talk transcript

  1. 0:00

    [upbeat music] Hi, everyone.

  2. 0:15

    Um, my name is Victor Dibia. I'm a principal research software engineer at Microsoft Research, and, um, my background is mostly around, uh, human-AI experiences, so that's sort of what I'm interested in right now.

  3. 0:27

    And over the last few years, I've been sort of looking at scenarios where a human works in tandem with an AI agent to solve problems. And so one of the things I've worked on at Microsoft Research is GitHub Copilot.

  4. 0:37

    So how many of you have used GitHub Copilot? Excellent. And so I think, in my opinion, it's the first example of an AI model working at scale, um, in an IDE helping the developer solve a problem.

  5. 0:48

    Okay, go ahead. You can switch that. And, um, beyond that, um, more recently, I spent my time working on an open source, um, multi-agent framework, something called AutoGen. Uh, how many of you have heard of AutoGen?

  6. 1:00

    Okay, great. About half of the room. And as part of that, I've, I've also helped build out AutoGen Studio, which is, um, um, um, a local developer tool to help build out, um, multi-agent workflows.

  7. 1:12

    Um, previously, I worked at Cloudera as a machine learning engineer, and more-- and before that, I worked at IBM Research as a research staff member focusing on, uh, human-computer interaction.

  8. 1:23

    Okay, so how did I get into agents? So I'm just gonna give a really brief history. And so sometime in, um, I think August twenty twenty-two, so this was about four months before ChatGPT sort of took off, um, I had worked on a project called, um, LIDA.

  9. 1:38

    And essentially what that tool did was that it let you, in a web user interface, drag in some data, a CSV or a JSON file, and it did a few things.

  10. 1:46

    So first, it came up with a summarization of the data. Um, next, it did things like ask a bunch of questions regarding the data. And for each of those questions, we sort of generated code, executed it, did some post-processing, uh, error recovery, and then we showed the user a bunch of visualizations.

  11. 2:03

    And so if you sort of look at it, it actually is an agentic workflow, um, and this just quite, quite early in this time. So it had these four main categories, summarization, goal exploration, visualization generation, which is essentially a code interpreter sort of built into the entire system.

  12. 2:20

    And then once we got these data visualizations, we did things like use a decision model to sort of come up with more representations, more, uh, sort of diverse representations of that data set.

  13. 2:32

    And so an interesting thing about the system was that, uh, the first version used the DaVinci Codex models. Uh, does anybody remember the OpenAI DaVinci models? That was a really long time ago.

  14. 2:42

    And one of the interesting things was that once I showed it, and the error rate was about twenty percent, and then about three months later, uh, there was the GPT-3.5 Tu- Turbo models, and we sort of tuned that, and the error rate sort of went down to about one point five percent.

  15. 2:57

    The key fun fact there was that, like, um, this sort of showed that these sort of applications were possible, and today I think you see a lot of these sort of, uh, capabilities across many Microsoft products and products b- uh, even beyond Microsoft.

  16. 3:10

    And so fast-forward after that, um, a few colleagues started to think about, um, how can we, as opposed to building these handheld workflows, how can we instead build multi-agent applications where you define agents and they sort of exchange messages and self-organize to sort of explore a problem, a problem space?

  17. 3:25

    And that's sort of where AutoGen sort of came about. Um, I'd encourage you guys to sort of look through it. It's a framework for building multi-agent applications. It's pretty well used for the 5K stars.

  18. 3:35

    And I think the more interesting thing I did there was AutoGen Studio, which is, uh, kind of a nifty tool. It's a low-code tool again. But in this case, essentially what happens is that you sort of sign into a web interface.

  19. 3:48

    You can then compose multiple agents. So for example, you create a team. You drag in a set of agents into that team. And then for each of those teams, you have primitives like models, tools, and you can sort of compose them together to sort of build multi-agent applications.

  20. 4:03

    And so when I started to prepare this talk, I think one of the things I wanted to do was sort of walk you through all of the capabilities of AutoGen Studio, how we built it, the design philosophy behind all of that.

  21. 4:13

    But I thought, you know, there's just a bunch of resources out there, and in general, this is AI dot Engineer. How about we go ahead and we build something from scratch, and we sort of show that today?

  22. 4:25

    And so maybe you shouldn't do that, but we're gonna do that today.

  23. 4:29

    And the tool I'm gonna show today is something called Blender LM. Um, it's a multi-agent system built from scratch, no frameworks, nothing. And the idea is that it's supposed to help you build, uh, uh, enable 3D sort of tasks.

  24. 4:41

    So you could go to this tool, say things like, "Build like, I don't know, a scene with a ball on a table," and essentially it'll do all of the plumbing underneath and get you a Blender interface, uh, that sort of accomplishes that.

  25. 4:54

    Anyone here familiar with Blender? Okay, great. Awesome. So here's the plan today. I have about thirteen minutes left. I'll show you a demo. I'll walk you through how I built it.

  26. 5:05

    And then at the end, we'll sort of discuss or synthesize a bunch of design principles that underne- underpin, um, a good user experience for a tool like this. And then finally, we'll sort of, uh, settle on a bunch of takeaways.

  27. 5:16

    Okay, let's go. In terms of background, how did I settle on Blender LM? So about two years ago, I sort of wanted to learn how to use Blender. And of course, um, if you've tried to use Blender, there's a really popular tutorial called Donut Tutorial.

  28. 5:31

    So that's what you're sort of looking at. And it's, it's kinda deceptive because the tutorial takes about four hours, but at the end of the day, you need about forty or fifty hours just to get through the whole thing.

  29. 5:41

    And so you're trying to learn, you know, where things, where do things live, how do you use the tool, and then you need to learn all of the concepts underneath.

  30. 5:48

    And so one of the things I asked myself was, "Can I build with all that I know about agents, with all my experience building AutoGen, can I create an agentic workflow that will help me take-- go from natural language to, let's say, something that looks like this?"

  31. 6:02

    The prototype is not at this level of quality, but I think it can get there. And so the next question is: how do you express this as a multi-agent workflow?

  32. 6:10

    And you have a couple of options as a multi-agent system. So do you build a workflow? And I'm sure if you've been at this conference, you've seen people debate, um, all of the pros and cons between a fixed deterministic workflow, so essentially know exactly what are all the steps.

  33. 6:25

    And this is great. We sort of use a lot of that in production today. You can build reliable systems, take advantage of things like function calling, structured output, and build really, really valuable systems.

  34. 6:35

    However, it requires that you know the exact solution to the problem, and so what you're doing is that you're expressing that solution as a workflow. But there are class of problems, like the kind of thing we wanna address here, that you don't know the exact s- solution to the problem because every time you take an action, let's

  35. 6:49

    say click something in Blender, the entire space changes, and you have to react to that in some way.

  36. 6:55

    And so on the o- other hand, on the other end of the spectrum, what I'm gonna focus on today is more autonomous exploratory systems. And so what that means is that we are sort of looking at a system where an LLM sort of drives the flow of control.

  37. 7:07

    We have tools, we take actions, we expect the results, we observe, and then we make progress.

  38. 7:13

    Okay, so three characteristics here that we should be, sort of have at the back of our minds. The system should have a bit of autonomy, so it might not address just a single task, maybe many different tasks.

  39. 7:25

    It should be able to take actions, and an action here can have side effects. And so for example, you could try something, call a tool, and it could sort of return with a result that you don't expect, and your system should be able to handle, handle that.

  40. 7:39

    And then finally, uh, you need to have systems that, uh, are expected to sort of explore complex tasks, break them down into steps, and then run for extended periods of time.

  41. 7:50

    Okay, so let's switch to a quick demo. This is the Blender LM interface. It's the web application. And essentially what's going on here is that it's connected over a WebSocket connection to an actual Blender instance.

  42. 8:02

    So this is, uh, Blender. This is a software tool for building 3D applications. And what we have here, the first thing you'll notice is that we have a set of fixed tools that the developer can use directly, and I'll tell you why we, we kinda need that in a second.

  43. 8:15

    So for example, I could click a button to clear the scene. And because we have a socket connection, we can stream exactly what's going on in the Blender interface.

  44. 8:24

    The sc- the, the scene is now clear, and we can show that to the UI in the UI.

  45. 8:30

    Next, we can, um, let's say, go onto a list of pre-selected or predetermined examples here. And so maybe I might ask this system to create two balls with a shiny, glossy silver finish.

  46. 8:43

    And essentially what we see here is that a bunch of activities start to occur. They're streamed to the UI in real time. So first it says we're analyzing the task.

  47. 8:52

    If we scroll up just a bit, we've come up with a plan. There's some planning done. There's a planning agent underneath. Says w- the first step, we're gonna set up the scene environment by adding a ground plane.

  48. 9:03

    Um, we're gonna create the spheres with correct spatial separation, assign a glossy silver finish and all of that. And we can see in real time the first thing it's done is, is put on, putting that plane.

  49. 9:13

    If we look at Blender, we see the, uh, horizontal plane here, and all of this is running live. You probably shouldn't do live demos in a talk, but hey, you know, we're trying to be brave here.

  50. 9:23

    And then it sort of explores, um, each time-- Essentially what's happening is that each time it takes a step, calls a bunch of tools, executes those tools, um, we stream the update to the user interface, and then we have a sort of verification loop.

  51. 9:35

    There's a verify agent that sort of takes a snapshot of the scene, um, uh, an actual log of what's in the scene, a visual representation. We use an LLM.

  52. 9:45

    We sort of judge are we making progress? Are we stalled? And then we sort of use that information to decide what we do next.

  53. 9:52

    And we can see that we have a ball here, which is actually what we really, really wanna do, and we can look at that in Blender. We can tweak it around.

  54. 10:00

    Hey, look, look at that, guys. It works. I think we deserve a little applause here. [clapping] Come on. There we go.

  55. 10:07

    I wouldn't explore more. I have about eight minutes left. Let's move on. Um, so how is all of this built? Let's walk through the process really, really fast. Um, most of the time when people sort of think of a system like this, the first thing they probably will say is like, "Let's define the agent."

  56. 10:23

    Um, that's really not what you should do first. First, let's define the goal. Pretty simple. Next, we need to come up with a baseline, probably has nothing to do with agents, nothing to do with, do with AI.

  57. 10:32

    Create, just ensure everything works correctly. Third, we build out our tools. What tools does this a- agent need? If a human was gonna do this, what tools would they need to accomplish this?

  58. 10:42

    And then n- not the agent yet. Next, we define a test bed. How do we evaluate how this thing works? And so--

  59. 10:50

    And then finally, when you have all of that, that's when you then go ahead and build the agent. The step one is really simple. What we want here is we wanna translate natural language tasks to 3D artifacts.

  60. 11:01

    Next, we create a baseline. We want a script that can say, "Let's build the 'Hello, World!' of Blender." Create a script. We run it. It adds a single cube to the scene.

  61. 11:10

    What we need here is a Blender add-on. We need a client library that can enable socket connections, all of that. And then this is really, really valuable for rapid prototyping and testing.

  62. 11:19

    Next, we need to define a set of tools, and there are two types of tools. There could be task-specific tools. For example, something directly just create a Blender object and do nothing else.

  63. 11:28

    And then you might have, um, let's say general purpose kinda tool, which is something to execute arbitrary code. And so in this case, you get your LLM to generate code, and you execute that, and that's what drives all the capabilities on Blender.

  64. 11:42

    And one thing to note is your agent is always only as good as the tools you give it. So spend a lot of time, about 50% of your time, on tools.

  65. 11:50

    And you can test all of this in code. This is what that looks like. Next, you wanna build an eval test bed. In this case, it's three steps. V1 is just a Jupyter Notebook.

  66. 11:59

    We're gonna w- write all that code, test it in Jupyter Notebook. Next, we create a full interactive web UI, which is the kind of thing I just showed here.

  67. 12:08

    Um, And then third, we probably want to create an eval- automated test suite, so things with metrics and u- and a full evaluation on this. And then finally, um, to create your agent, the first thing you wanna do is to create a base agent loop.

  68. 12:25

    If you've been at this conference, you know that an agent is mostly an LLM in a tight loop with a bunch of function calls. So you create that, you get its final result, and then you're fine.

  69. 12:35

    But typically, for s- a problem like this, this is typically not enough, and you need to it- iterate just a little bit more. [clears throat]

  70. 12:45

    Okay. You need to iterate just a little bit more, and in this case, we have two other agents. There's one called the verifier agent. What it does is that every time this agent takes a step, it'll sort of take this, the content of the scene, it'll take a list of all the objects there, and we'll sort of

  71. 12:59

    use an LLM to predict, are we making progress, is user task completed, and then we decide how to move forward. The second agent you want here is a planner, and so you saw earlier, um, when the task came in, the planner sort of broke it down into atomic steps, and then each of the steps sort of addressed

  72. 13:14

    in this sort of tight loop. So what can we learn from all of these? And so the, the design principles I'm gonna give you here, um, they're not exhaustive, they're not perfect.

  73. 13:24

    And in fact, if you met someone that told you that they knew the exact design principles for multi-agent system design, you probably shouldn't trust them because the space is just too early for that.

  74. 13:33

    So what I'm gonna try to give you today is a set of four high-level ideas that you can sort of take, and once you build this sort of system, sort of apply them to see how, um, you can use that to improve your own systems.

  75. 13:45

    So the first is, the first, um, principle is capability discovery. So what you wanna do is that because you have an agent, it can do a whole bunch of things, but there are a few things that it can do with high reliability.

  76. 14:00

    And so you saw earlier, I had this little sort of POs that showed that here are the things the agent can do. So you wanna itemize the kind of things that your agent can do with high reliability.

  77. 14:09

    The second thing you can do is to have proactive suggestions based on user context. Let's say we have a scene open. You can sort of pause the scene and sort of suggest to the user some high-level things they can accomplish.

  78. 14:21

    And so this is an example of that. The second thing is observability and provenance. And so stream all of the activity logs, help the user sort of make sense of what the agent is doing.

  79. 14:31

    And then you wanna provide tools for debugging and all of that. So, so all the little things around, um, number of tokens used, the amount of time taken for each of that, very, very valuable for the user to make sense of what the agent is doing.

  80. 14:44

    The third is interruptibility. So at this point, your agent is sort of taking all kinds of actions, and so at any time, you want to sort of design your system such that you can pause it.

  81. 14:55

    It might be going down the wrong route, about to make a mistake, or sort of consume a bunch of resources that you don't intend. And so you want a system that enables things like checkpointing, rollback, pauses, and resumes.

  82. 15:09

    And then finally, cost-aware delegation. So every time an agent takes, um, an action, um, from the LLM's perspective, all actions are equal, all tool calls are equal, unless you do something about it.

  83. 15:22

    And so you might h- in m- in the case of Blender, you might have it write some Python code that, let's say, I don't know, adds something to the scene.

  84. 15:30

    But for any reason, let's say it tries to delete the entire operating system, you really don't want things like that to happen. And so you want a module that actively inspects, inspects the, and tries to estimate the cost of the action, and then knows when to delegate to the user.

  85. 15:46

    And so I'm kinda getting to the end. Um, what are some of the key takeaways? The first one is know when to use a multi-agent approach. And so a multi-agent approach is not always the best thing to use.

  86. 15:58

    And essentially, when you have multiple agents collaborating and you give them a bunch of autonomy, um, as part of that process, you also increase the surface for error. And so like any other tool, you should sort of inspect the problem space and sort of verify if a multi-agent system is actually the right tool for the job.

  87. 16:19

    I always show this little graph, and so you have a big circle here, and if the big circle is the task that you're engineering or most engineering teams need to do, then this small circle here at the bottom is the task that truly benefits from a multi-agent system approach.

  88. 16:35

    Um, it's really, it's really that small, and, uh, before you try to build an autonomous multi-agent system, uh, just think very, very carefully and ensure that you have good ROI on, on, on, on, on, on this specific approach.

  89. 16:49

    The next, the next question I get is, "How do I know if my task might benefit from a multi-agent approach?" I typically offer a five-step framework. Um, the first is planning.

  90. 17:00

    Does the task benefit from planning? Can you take a high-level input from a user and meaningfully break it down to the bunch of steps that lead you from an unsolved state to a solved state?

  91. 17:10

    Next, can you take the task and sort of break it into multiple perspectives or personas? In this case, um, let's say you might have some, some, some persona that explores things like just planning of the task, um, maybe some personas that handle, let's say, code execution, all of that.

  92. 17:26

    And so with the multi-agent approach, you can explore this sort of domain-driven kind of design. The third is, um, does the task require consuming or processing extensive context? And so here we are constantly snapshotting the state of the app, screenshots, all of that.

  93. 17:43

    And it's kinda useful to sort of give individual agents each of these, uh, large pieces of context to process and then return to some other final coordination agent. And then finally, adaptive solutions.

  94. 17:56

    As you take actions in the world or in the environment that your agent exists, the environment might change, and you might constantly need to sort of react to that.

  95. 18:04

    And so you might need, like, an autonomous multi-agent approach here.

  96. 18:08

    The second takeaway is eval-driven design. Uh, most people wanna start out with just building their agent. Um, it's typically a mistake. Instead, you wanna define your task, um, define your evaluation metrics, build the baseline that has nothing to do with agents, improve your agents iteratively.

  97. 18:25

    In, in the case of this app, we had like a simple tight loop, then we improved it, we added a verification agent, and then we added, um, a planning agent.

  98. 18:34

    And based on the interactive evaluation tool I built, I could see that all of these things actually had like ROI and improvement, and that's, that's why it makes sense to explore a multi-agent approach in this space.

  99. 18:47

    And then the final thing is that academic benchmarks are great, but they're not your task, and so, um, you really should build evals that's sort of, uh, tuned to your task.

  100. 18:58

    And then the second slide, um, s- the, the last set of, um, key takeaways are the design principles that we'll walk through today. I think this is the money slide here today, um, for hi- high-level things.

  101. 19:12

    First, always ensure that your users can discover the ideal tasks that your multi-agent system is designed for. Um, provide user-facing observability traces. Um, ensure that your agents are interruptible, um, you can checkpoint and restart them.

  102. 19:28

    And then ensure that, um, your agents can quantify the risk or cost of all actions and delegate to users as needed. And then finally, don't build the whole multi-agent system from scratch just to give a talk.

  103. 19:40

    You probably know that. It's fun, it's a lot of work, um, and if you ever want to do something like this, consider using a framework to save you a couple of keystrokes here and there.

  104. 19:50

    So at, at the last slide, I have a bunch of further reading, a couple of papers we've written on AutoGen Studio, Magenta 1, Magenta UI, challenges in human-AI communication.

  105. 20:00

    Um, these are all good references I recommend you take a look. And then I'm at the end of my slides. Thank you so much for listening. Um, I have a book I'm wr- I'm writing.

  106. 20:10

    There's a lot more about this. Chapter three is really just about like design. Um, take a look, um, if it's helpful for you. And all the code for Blender LLM is also available.

  107. 20:21

    Thank you. [outro music]