242: Designing for 100 Years… in 100 Seconds?

TRXL

This episode explores the evolving distinction between autocomplete, copilot, and agentic AI within the AEC industry. Industry leaders from ma

Key takeaways

• Oliver Goldman (Autodesk) notes that the distinction between co-pilots and agents is often more about marketing than technical reality.
• Greg Demchak (Bentley) describes agentic workflows using a 'headless' MicroStation to run simulations via Model Context Protocol (MCP).
• Prezanta Bowes (Twinmaster) views AI as 'semantic autocomplete' for digital twins, filling in partial design information.
• Mike Saldan (Ignite) highlights how Anthropic's Claude and the REACT framework are blurring the lines between assistants and agents.
• Matt Walsh (BIMBeats) demonstrates an agent identifying a QAQC risk where one engineer spent 50 hours on a model without a second reviewer.

Main topics

• AI in AEC
• Autocomplete vs Copilot vs Agentic workflows
• Model Context Protocol (MCP)

Notable quotes

I don't think you should design anything that should last for 100 years in 100 seconds.

Conclusion

While agentic AI offers incredible leverage for automating complex tas

Transcript preview

Speaker 8 (0:00) Something you said in our last conversation, you said, I don't necessarily think the architectural design process should be too fast. Speaker 3 (0:07) No, I don't think so. Going back to it, I don't think you should design anything that should last for 100 years in 100 seconds. Speaker 8 (0:15) This is the next AEC Tech Stack. 14 conversations with companies building what comes after the tools we use now and with the people who have to live with what they ship. I'm Evan Troxell. This episode is brought to you in partnership with Graytech, our foundation partner for this series. Graytech is a global AECO technology leader delivering software, consulting, and expertise. Also a trusted Autodesk and Bluebeam partner, Graytech helps businesses work smarter and build what's next. With support from Avail, Avail's content management system helps architecture and engineering teams find, manage, and reuse their Revit, AutoCAD, Civil 3D, and other technical content in one place. In this episode, you'll hear from representatives at Finch, Schema, Chaos, Upcodes, Graphisoft, Bentley, Autodesk, Twinmaster, Ignite, and BIMBeats. This is episode five of the next AEC Tech Stack series. Welcome to the Troxel podcast. I'm Evan Troxel. And in this latest episode, I asked everyone the same question. What's actually shipping today versus what's still a demo? This episode is narrowing the lens. Two questions back to back. First, when a vendor says AI, do they mean autocomplete, a co-pilot, or something that actually acts on its own? And does that distinction even matter to you? Second, further out. Can you describe a building in plain English and get something real back? I asked the same group of partners that you heard in the last episode both questions. Some of the answers agreed with each other. A few didn't. So here's where I started. A year ago, most of what Autodesk shipped under the AI banner was help mode. The thing that answers a question about the software itself. Of course, that was just step number one, and it's not where they're stopping. And as you probably are now aware, they just announced a standalone Autodesk Assistant last week at Autodesk University 2026. So that's where I started. Let's jump into it with Oliver Goldman, VP of Software Architecture, AEC Solutions at Autodesk. Now that Autodesk Assistant is becoming a standalone experience that works across Autodesk products. I'm interested in that transition. So when did it stop being a help feature and started to become something that moves work forward on its own? Speaker 6 (2:30) Yeah, I mean, I think Autodesk Assistant stopped being a help feature probably right at the same moment that it was originally conceived, right? If you remember back to that time, you know, assistants were new on the scene and we were just learning what we could do with these chat agents. And of course, there's like a million things. You're like, we could use it here. We could use it there. We could use it everywhere. Speaker 6 (2:50) The help mode that rolled out, I think on Autodesk.com first, if I recall correctly, was first more than anything because that was the most straightforward thing to do. It was a very easy application of the technology. We could build it quickly and get it out the door and get some initial experience. But even as we were doing that, even as we launched the first versions of that, some of the work that eventually led to it being in-app assistant had already started and gotten underway. That is a harder problem to solve, right, to make the system work there. And the notion of breaking it out into a separate application that could support users across multiple workflows and multiple products also occurred to us very early on, but an even harder problem to solve, right? You need new user experience. You need a much smarter agent and harness to figure out how to. identify the right workflow and integrate the different product capabilities under the covers. I could go on and on. But, you know, so what you're seeing in the rollout is less about the order in which the ideas occurred to us and more about the depth and the complexity of the work that needs to be done to bring those different experiences actually to the Speaker 8 (3:59) market and put them in users' hands. That answer sets up the question I ended up asking almost everyone in this episode. What's the real difference between autocomplete, copilot, and agentic? Here's Oliver again. Speaker 6 (4:10) Yeah. So to be honest, I'm really not sure what the difference is between co-pilots and agents and assistants and all these different terms other than the marketing and branding. I do like the assistant term that we've used here at Autodesk. I think it sort of gives you the same, again, the right frame of mind in terms of what it can help with and what it can't do, as we've been talking about. But, you know, I think... So underlying your question is, or the deeper question there is, what are the different modes in which AI can be applied in different parts of the portfolio and what kind of work can it do? And there the approach we're taking is, I would describe as all of the above. And we can put whatever labels we want to on the different places the tech shows up. But the real question is, or the real observation is, there's not a lot of limits on places where we can enhance workflows or help you to get work done. Speaker 8 (4:59) Greg Demchak at Bentley draws the same line. with examples where each one shows up on their platform. Speaker 1 (5:04) In the architecture space, if you think about autocomplete in a Word document is like filling in the next sentence. In this case, it would be, can you add dimensions to this floor plan? Can you create a section? Can you fully annotate this drawing? And also make sure that all the annotations aren't overlapping one another. So this is kind of like... a very good example where the copilot has a good understanding of what is a dimension, what's readable, how should things be laid out in a drawing. So that's stuff that we've added to our tools like last year. So this is about making the production of drawings much more easy. So that's a bit of that piece. When we get into agentic workflows, Speaker 1 (5:55) This is where you almost start to imagine that the software itself is not something that you're directly maybe interfacing with kind of in a direct way, like pushing buttons and icons and operating it like that, or even talking to it with chat. It's more like you've got this engine that can be called and running, you know, a headless version of MicroStation or STAT, which is the Structural Engineering Package, and then an agentic system. through a model context protocol can communicate with that system and it can start generating results, many, many results and try and optimize those results and then feed the results back to whatever interface makes sense. It could be a web app. It could send that geometry to a structural package to run simulations. It could send it into Unreal Engine, for example, for an immersive experience. So that agentic system is really designed to be working at the code level where you're kind of describing an output and then the agent then goes in and it sort of like, you know, calls these functions within these, you know, CAD and analytic systems, runs the simulation, gets the results and returns them back. So I think that's a pretty exciting kind of nuance for how we think about using software. Speaker 8 (7:17) I asked Prezanta Bowes at Twinmaster to define all three back-to-back. Speaker 5 (7:22) I'll take the position like this. Some of them are synergistic, these three constructs that you've said. So obviously Twin Master is first and foremost that agentic category, right? Because it is bringing that ability to engage multiple agents working either in autonomous mode or on an intent or task-driven mode to deliver. what he or she wants, right? I would say continuous reasoning, right? So that's agenda. It's giving agency to the digital twin, okay? That it did interact, right? Then the other part, when you say co-pilot, that's where you can say, you know, there is a sense of co-pilot here because not the agents that you're talking about, these different disciplines, doing design, doing analytics, but there is a guy. who is orchestrating and talking to you called Archie, which is kind of, you can say, overall task delegator. you can say in a one way right it's helping you to bring together in a natural language interface and collapsing those agents as if you don't know what you know whether there is multiple the agentic thing going on there right working you would do in a seamless way in your natural language terms so it's in a sense for pilot because you know it is assisting you right in getting things done right and so it is harnessing the power of the agentic thing right Speaker 5 (8:59) underlying agents that are going there, right, and solving the problem for you. And there was the third thing that you mentioned was, what was the other one? Autocomplete. Autocomplete. It's interesting. It's in a way autocomplete because if you unpeel the word autocomplete or autocorrect, right so you threw in an agent and i mean you threw that you know if you think about you know autocomplete you you're you're typing a sentence right and it fills up right kind of thing right so the underlying premise of a twin master is that it should be able to work with partial information and this is the holy grail of partial design they if you look at go back to ai days you know back in the day or y'all i can give out wrap off thesis after thesis coming out of phd thesis they called it partial programming you know what i mean so they wanted to get partial specifications give it to it and let it generate so if you look at it if you tell you know today claude hey generate me on this thing uh if you were clear enough right give me a ui that you're giving a partial specification it completes for you by generating the code around it right given by the the kernel you gave right the same thing but in a much more complex way it is happening in twin master because when you brought in a design right it's it's a bare bone it doesn't have it doesn't know what this kpi is about this thermal comfort it doesn't know what it's you know it's it's you know energy which is carbon footprinted you gave it you know you ought to you ought to you did this kind of a quote unquote semantic autocomplete the reason i'm being semantic because these are grounded in reality this is not like syntax here You know what I mean? Right. You're giving it like, hey, what about it's in a comfortable comfort. Right. And you are completing it, creating a more, you can say, complex digital twin. But furthermore, the reason I brought in that agent is that you're not giving agency to that guy because now these agents are tracking as the decisions are, as more of the completions take place. Right. I'm just staying on that same term, right? Because you will go down and say, hey, okay, look, I'm going to be trading off. That's a kind of an autocomplete in a broad sense. And so what it's going to do is it's Speaker 8 (11:28) going Speaker 5 (11:28) to explore. And now the autocomplete is a little, I mean, much more complex because you want to interface. You want to let the user be in control before it completes the first word it adds. Hey, wait a minute, wait a Speaker 8 (11:40) minute, Speaker 5 (11:40) wait a minute. I want to basically add this. What did you do? You are introducing a different notion of Speaker 8 (11:47) autocomplete. Same question put to Mike Saldan at Ignite. Speaker 4 (11:51) Yeah, it's interesting. The structures of those are getting looser, as I'm sure you've probably seen, right? I think there was... I do a lot of briefings with like the analyst groups, the Gartners and the Foresters of the world. You know, a lot of these folks that are CIOs used to make decisions on technology. And I would say a year ago, people were hyper fixated on the definition of an agent and how to be automated and how to do this and how to do X, Y, Z. That's kind of disappeared. So the structure of those things are getting more and more blurry. And I think that the big driver of that blurriness actually came from Anthropic with Claude at the beginning of the year. Because you can go write a skill file, which effectively is a wrapper that you put around a prompt to say, I'm giving Claude context. I want it to understand the task of what I want it to do. And you can write it in natural language, and then it will produce a 10, 11, 12-page task based on that. And it puts a lot of refinement to your query. So when you have a piece of technology like that, the structure of what an agent is and is not becomes much less relevant, right? Because you're starting to wrap the LLMs with these things. So, you know, I used to argue 18 months ago, an agent needs to be able to reason with itself. An agent needs to be able to do X, Y, Z. The models are getting there anyway. Like a good AI assistant like we have inside of Ignite used to rely on what was called a RAG as an acronym, Architecture Retrieval Augmented Generation. And that was a painful way to look at things. It made it so you had zero-shot prompting, meaning that you can only interrogate once. You can't re-interrogate. But technologies have come along to use frameworks like it's called REACT, R-E capital A-C-T, which is a planning mechanism. So when you put in a prompt, even if it's not an agent, it can plan, it can react, it can reason with itself, and then it can come back around. So the advent of these technologies and the growth of things like skills, the React framework, all these things are making the context of those matter less and less and less. Like a good example in the Ignite platform is we used to have multiple entry points to do different kinds of tasks because there was different frameworks on how the prompting would work. Really, right now, we have an agent framework and we have an AI assistant to look at your entire tenant. And that will start to blend, too, probably just to the AI assistant over time. Because the AI assistant, for all purposes, could just go call an agent. You don't even have to worry about the agent framework itself. So the evolution is interesting. I think a lot of the early constructs were just so that humans could understand what we were trying to do and what's about your outcome. Speaker 8 (14:23) Back to Oliver at Autodesk, this time on Revit's new MCP server specifically. I wanted to know what it took to build it and what risk conversations came up around exposing your data to it. So Revit 2027 has MCP on board now. So that means that other AI can come in and reach into the model. So that seems like a genuinely open move from the Autodesk standpoint. And so I'm curious, like, how did that develop? How did you go about it? And what did you worry about in that process that people could do once they could get into the data in this new way? Speaker 6 (15:00) So for us, adding MCP server support to Revit was kind of a no-brainer, honestly. I mean, Revit does already have a very, very extensive API, right? And people can write plugins for it and access really every part of the application. But that's a very hard barrier, right? Because you have to know how to write one of those plugins. You have to be familiar with coding and APIs and so on. And MCP server is one way to think about them. And the way I think about them from a software perspective is they're just like a... a new kind of AI that's accessible to agents instead of to programmers, right? And so to take that same API that we've got and the openness that's in there and expose it through an MCP server, like, yeah, why wouldn't we do that? But it was also advantageous for us, right? So as we're building the new Autodesk experience that you saw at AU with the... separate application experience, well, how is that going to reach into Revit and work with the models inside Revit? Well, it's going to go through that same MCP server, right? So from a very practical point of view, just in our own technology stack, it made sense to build this piece and then to open it up. Now, you asked about what I'm worried about there. I think the thing that I'm most worried about goes back to this question of, like, how do you trust? these agents? How do you understand what they're doing? How do you work together when both of you have the pen, right, or a pen? I really like that. I really like that analogy. And so there with the MCP server, we started off a little bit conservatively with, hey, you can inspect the data that's in the model, kind of a read-only mode where we felt it was very safe. And what we're exploring is how to add editing and modification capabilities for the model in there in some way that's not going to screw up your whole model. Honestly, right? And again, puts you back into that, hey, I'm working with this agent that's accessing Revit through the MCP server. It's got a pen. I've got a pen. How are we working together on that? And that is a thing you can do with MCP servers, but it's not a thing they do out of the box, if you will. So that's, again, taking some exploration and some development of the technology to understand how to bring those two views together. Speaker 8 (17:03) There's a shift happening in how agents reach into the database underneath a BIM model. not just the geometry, but everything else attached to it. I put that shift to Greg Demchak at Bentley and asked about their own MCP integration. These agents can use software, and they don't need to use it the same way people need to use it. So for your example, using these model context protocols to go... Through what what we might consider like the back door like just a hidden door that doesn't matter to us to go run those optimizations or to move geometry from one platform to another or Do some analysis or whatever? It doesn't need to even look at something. It just needs to understand what those things fundamentally are and then do those Procedures to it and then give you the results back It's a very interesting place that we find ourselves in. Speaker 1 (17:59) This is also quite, quite interesting. Like, you know, the way we are approaching strategically is like, we don't expect that if you're building your own kind of agentic tooling within a firm, like an engineering firm or architecture firm owner operator, you know, you're going to want to be able to call different software from different vendors at any point. Right. So the point here is to expose an open access, you know, across, across that full domain. Because I think that's the truth. That's how this environment is evolving. You know, you'll be able to call an agent that runs into this structural package that maybe runs like an energy simulation over here and then produces a rendering with like a diffusion model over here and then brings it all back together and stores it in the cloud for some clash detection, right? So it's like the agent can kind of start to call all these different functions and then give the results back and whatever. medium and format makes the most sense, right? Is it a dashboard? Is it a high-fidelity rendering? Is it, you know, a website that gets generated on the fly and just disappears in like one hour? I mean, it could be, you know. You Speaker 8 (19:06) told me about Speaker 1 (19:07) an Speaker 8 (19:07) embodied carbon color coding demo. Can you tell me about it? Speaker 1 (19:11) Yeah. I mean, that's just another, that's just sort of an example of one we built in the labs where you know you could basically have a complete bim model And with just a chat interface, you could ask it. So this is basically an AI doing a query on the model. You know, show me this complete building model and render and isolate all the concrete and then color code the concrete based on the quantity of embodied carbon. So here's like a system that can basically call APIs, application interfaces. Speaker 1 (19:51) do things like isolate geometry, color the geometry, and ask, where's all the concrete? Run an EC3 calculation to see how much embodied carbon is in that type of concrete, and then basically make a color-coded 3D view of that model. And that is something you can do today. And I was like... you know the effort to do that before might have been like you're again picking and clicking and you know you like you have a bim or cad expert operator or someone who has to build a plug-in now it's like you can describe that it can call those functions as long as they exist in the software and then give you the the results i think that's that's a really practical example a Speaker 8 (20:37) lot of the industry you've mentioned the bentley lab a few times and and and perhaps they don't know that it even exists. I'll put it out there. So if you can say, what does the lab actually do? And then if you have any recent examples of projects that you've done. Speaker 1 (20:52) So it's a small group of creative technologists, and we're software engineers, UX designers, program managers. But what we look at is emerging technology and emerging trends, and then try and find these gaps. working with customers to sort of develop new solutions. And increasing now we're using obviously AI, software engineering as a fundamental part of that process. And what I mean by a gap is I guess, are there applications, ideas? You'll find this in almost any firm or any account, right? There's some idea someone's got that just hasn't been implemented. So you could do that. You could build a plugin maybe for some software. Or you can build like an automation tool, but sometimes you just have this totally cool idea and you want to, you want to make it. And so, like, a recent example, we did, we wanted to see, like, okay, this idea, like, well, we want to, we basically run a simulation of how the city will respond if we add some new architecture, or if we cut off a bunch of streets and bring this idea of like a super block into the city. So super block is this. idea that came from barcelona where you block off certain roads that are for cars and turn into pedestrian ways and so the question is if you do that what's going to be impact on mobility for cars for traffic for bikes is this going to like cause like a huge action in the city and so how do you create like an app a web app experience where like the city planners and even the public could sort of maybe experiment with the city and kind of get the results of you know simulation in in near real time so trying to like you know show that like when you make a change in the city there you can actually run these simulations and under understand the impact and it's not just all you know what what's like an opinion right so data driven decision making and so we we built that as this web app you know get brought everyone together for a week in Zurich, ran a hackathon with the customer, had the use cases from the city of Basel. And we got these prototypes up and running, custom web apps in a matter of a few days. And then we also built an app for this for the Apple Vision Pro. So you can kind of get fully immersed in the street view of these city interventions. So that's one example, but we do many things like that. We'll just find some idea. It looks strategic. It's something that doesn't yet exist in our portfolio. And we'll always work with like a real scenario, a real use case, a real customer, and then try and bring all these different pieces of software together to see if we can solve that problem. So it's like this ability to kind of like, you know, talk about like what is the main problem we're trying to solve, which is like understanding urban mobility, impact of new architecture and infrastructure. and make it visible and tangible to people. And so using these AI tools, we can surface these interactions very quickly now. And we're less concerned about which software or is it hard or is it complicated? We're just trying to solve the problem. And I think this is what I'm finding with it. Speaker 1 (24:19) AI-based software engineering, what we call spec-driven development, is we get there very fast now. Speaker 8 (24:24) Now here's Speaker 1 (24:25) a Speaker 8 (24:25) way to see that shift from the other side, inside the software that tracks how a whole firm actually uses its tools. Matt Walsh at BIMBeats has built agents into that tracking, and is already showing him things that weren't possible 60 days ago. What's notable is that none of this was a sudden pivot. He says the groundwork was laid by decisions BIMBeats made five years ago. That's playing the long game. And I think it's something that firms should think about doing themselves as well. Let me do a quick definition here since Matt's about to mention Elastic by name. It's the search and analytics engine a lot of enterprise software uses under the hood to make huge data sets searchable in real time. Think of it as the index that makes find this instant instead of slow. I Speaker 4 (25:06) can only answer that based on where we've come in the last 60 days. But going back five years ago. when BIMBeats was created, it was about creating a data structure that at some point an LLM would be able to talk to. And we waited until we felt that the MCP, the elastic MCP, which is how we use our agents to talk to that data, was mature enough to be able to go in and rely on that LLM or on that MCP. So what we've noticed is, and I'll give an example of something that happened within a business. where they said we want to we want to analyze how this project is performing from a qaqc perspective is there anything that you can do in bim beats to help us do that now because we capture the active process every minute that's running we can see how much time is spent in a structural analysis tool versus word versus excel etc etc and i if i was to approach that problem by looking at dashboards and looking at the data inside of elastic to say how am i going to filter this down to understand how we can look at that project and how we would be able to look at lessons learned of how we would do things differently. And I just, I don't think I would have been able to do it. Whereas when I asked the agent, I'm looking for this project number and this project name across all the applications that we use. I'm looking for opportunities of how we can improve what we're doing from a QAQC perspective. And it came back and it said, the structural analysis tool that you use predominantly is this tool. And I have identified the primary engineer who spends most time in that tool. Then I've identified a secondary engineer who appears to be checking. I've gone through and looked at the 10 most active models that have been created in the last year. And there's clearly a QAQC process for nine of those models where you have a primary engineer and a second engineer, because I can see how much time each of them have spent in that particular model. But you've got one model here that's had 50 hours of active time spent in it by one user. I suggest you have a chat to that user to see whether or not that model needs a review, because if that engineer is the only person that's been in that model and then they've gone and used that for the design that's gone into documentation that gets built, there isn't a clear QAQC process that that model had been reviewed. And I was like, wow, I didn't even ask it explicitly to do that. I just said, I'm trying to understand from a QAQC perspective, how could we do this job better? and it just went off knowing that we got that structured data in there identified the application identified the amount of time spent in it and then created me a full html report that was just beautifully presented that i could hand over to anyone on that project team and they'd be able to understand exactly what the problem was and exactly what the solution was whereas before if i'd said oh it's all in the dashboards i'll give you a login to cabana you can go in and work it would never have happened and even if i was to do that exercise i would never have got to that position and The LLM and agent did it in about five minutes. And it just blew my mind that, going back to your question, 60 days ago, if somebody asked me to review a project and look at that opportunity, I would be like, I don't know if I can actually do that looking at the data as a human and going into different dashboards to work it out. But using the agent to just go in and analyze that data and prompt it with that, I was just blown away with what it could do. Speaker 8 (28:32) So agentic is very different than autocomplete. and co-pilot, but you had to do work to get to the point where an agent could even do what you just said it did. And you intentionally waited some period of time to flip that switch and do the work that it took to get you to do that point. And so I just think it's important to point that out. It's like the leverage potential is incredible, but you have to be in a place where that can actually happen. Speaker 4 (29:03) Yeah, absolutely. And look, we were lucky in that Elastic have done all of the work to create the MCP, so it wasn't an investment on our part. And what we're doing now is saying, well, we don't really know what the token spend is on this agent using the Elastic MCP because it's broad, it's not built for BIMBeats. So we're now creating a BIMBeats MCP that talks to the Elastic MCP so that we can start putting guardrails on the amount of tokens that are being spent. And the interesting component of that was... We said, right, well, we think the Elastic MCP is mature enough. We'll use that. We'll allow our clients to use that for free because they can just spin this up in an hour. It's pretty simple. You provide it the instructions, you provide it a knowledge base, and away you go. But what we really want to do is we want to narrow that down so we are a little bit more in control of the token spend. So we said we should probably generate our own BIMBeats MCP. And Curtis, our software developer, said, after dinner, I was waiting before I jumped on a call with Conrad. And between dinner and the call with Conrad, I've built a proof of concept for the MCP via vibe coding it with Claude. And I was like, Curtis, if you were not to use AI to do that and you were to do that traditionally, how long do you think it would take? And he was like, probably a week. So it was just incredible, the pace of... what you can do now versus what you could do like literally six months ago or 12 months ago and like the evolution of that is just incredible and I guess I'll flip this one back to Ariel because I know a lot of the work that he does now is via vibe coding and I think the interesting thing with vibe coding within an organization is where are you allowing people to be as flexible to test these things versus where do you have guardrails and where are you rigid so I'll flip it back to Aurel to give some examples of what he's been doing in that space. Yeah, Speaker 6 (30:55) thanks, Matt. And how I've been using it has been a little bit of autocomplete, a little bit of co-pilot, and maybe just starting to touch on agent. I think that's a next level that at least we internally haven't got to, and probably most architecture firms haven't got to, to the point of... creating agents that just run on their own and complete tasks while you're asleep. Other industries have gotten to that point. I think we're still defining what are the tasks that could be performed entirely autonomously by an agent. But the way I've been using Claude and LLMs in my process is what I've been working on is this automatic reporting utility that's gonna generate these insightful reports based on the data. Because what AI is fantastic at, even the early models, is just analyzing troves of data. And what do we have? We have troves of data. And so what we've been looking to do is how do we point that data with the right question to an LLM to generate a report. being mindful of token spend and then being mindful of the variations that happened. If I prompt one question a hundred times, maybe one answer is not going to be satisfactory to me because it's generating it from scratch every time. So I'm taking it from a point where I'm using the LLM to identify the patterns and identify the scripts that we're going to run to get the insights we want from the data. And then I'm using the agent itself to take it a step back and just turn it into a good old algorithmic process. So the agent is helping me write. scripts. But now we've got this chain of actions that are taken from the point of the data being extracted to the report being generated, that at some point in the process, I do need LLM input, but it's no longer that I go, here's all the data. give me a report. Now it says, here's all the data, run these scripts to summarize it in this way, and then generate a very tight payload with this exact prompt, which you then send to an LLM with instructions to return it with a very specific format so that the response from the LLM can then plug into a report. And so it's about chaining these things together, it being like just a Python script and a query into Elastic to then process the data to then go to a Gemini API key to generate an analysis. on the data that we sent to then put that into a report, which is just done via Python, HTML, and CSS. And so I come from a computational design background. It's easy for me to draw a parallel between these processes and how I was using visual scripting in Grasshopper, where I imagined each of these steps as a node in this scripting environment. But now I have the flexibility that some of these nodes are essentially magic. I can input something, some magic happens in there and out. comes the output. Speaker 8 (33:34) Okay, I'm going to introduce a new thread now. So as more of this work gets encoded into the computer and the computer gets better at doing it, where does the architect actually fit in? I put that to Marty Rosmaneth over at Schema. You've encoded a lot of logic into what you're doing with Schema, right? I mean, you're talking about these packing kind of algorithms and... Speaker 8 (33:56) You're able to manipulate that as well, right? So it's not just one for one taking those pieces that have been designed in air quotes, right? Wherever they sat in the last project, there's still, you call them like a, Speaker 1 (34:11) you Speaker 8 (34:12) can modulate these jelly cubes, right? These jello cubes. So, you know, as more and more things become... Speaker 8 (34:21) I guess, you know, encoded, the logic gets encoded. And you talked earlier about kind of shifting the focus of the person in the loop to a different place. So, I mean, let's talk about where you see how all that, I guess, where are we going with that? Where do you see the ability of the architect to actually not have to do all that busy work of stretching and packing those cubes and getting them to lay out just perfectly? If the computer is doing that, like where does... where does design go? Because at some level, the computer is doing a little bit of the designing all by itself, because you basically made a definition of the things, the outer boundary that all these things have to fit into. And then what do I get to focus on? And where do you see that moving to? Speaker 3 (35:05) That is a 10 miles deep, excellent question. So let me see if I can try and unpack the various aspects of it. First off, You know, there's the discussion around procedural things which are deterministic. So in a way, there's a CTO answer and then there's just the life as an architect answer. Procedural things that are deterministic. So things that are scripts, Grasshopper, Revit journal files, Dynamo, all of those things, you put inputs and you get outputs. And if you put the same inputs every time, you get the same outputs every time. So those things are deterministic. They're based on math or... as simulation people would say they're discrete discrete inputs yield discrete outputs versus ai which is probabilistic right you put in some inputs and you might get similar outputs right but it's it's it's it's different than than a deterministic thing which is why it's so hard to get your handle on sort of what it might impact