0:00 I think thanks man. Well, thanks everyone for having me here. I’m Steve Macci, CEO and co-founder of Syskit. I’m here to talk about systems engineering for humans, agents, and automations. This is a topic near and dear to my heart because we’re focusing on what the benefits of what Git gave software applying it to hardware. So, one thing I like to think about here is this this concept of the autonomy ladder.

0:46 I’m going to zoom out for a second. The software engineering world with all of the synthetic design work, it’s really interesting thinking about the different layers here that we’ve experienced as a society and as a as software developers. Started out with auto complete where you had stuff like Microsoft IntelliSense 20 30 years ago saying, “Hey, you’re looks like you’re typing a function. Let me auto complete that for you and help you there.” So, the machine is really owning the thing and the human is reviewing everything on the token level.

1:12 Then we get to co-piloting, right? Last six five or six years or so where humans are reviewing blocks of code changing inside of their inside of their software and the machine is owning the blocks of syntax. And like that was the first real exposure a lot of a lot of us had to that type of advanced autonomy. We then we get into the agent world where we’re pretty much most of the the people who are working in the space are at right now and that that’s bleeding into this multi-agent layer.

1:37 And that’s where you end up having the human reviewing the end artifact that the engineer or that the the robot creates, but the machine owns the edit loop to get to a solution. And then when you get to multi-agent, they’re starting to own that decomposition integration stage. The end goal of course being this dark factory concept where you can just put in the aggregate output metrics you care about and then getting to the verification itself at the other end.

2:02 And this is really really exciting to get to because a lot of the presentations we’re seeing here you know today and yesterday are having us barrel towards this much sooner than we thought, which is really cool. But I want to talk like little one fundamental thing that I think is an enablement here, which is in the software world we don’t automate things you can’t diff. So you can’t automate things you don’t know what has changed in a deterministically correct way even from the software side.

2:25 And so then what does this end up looking like for hardware? So software climbed the ladder of version control infrastructure, right? We got really used to using Git everywhere. Linus Torvalds invented it to manage his development stack throughout the world to manage the Linux kernel, probably one of the most important pieces of software only to be followed by Git as well. And we got really used to being able to make overlapping changes on the same piece of code and gracefully resolve the differences.

2:56 That’s fundamentally why the Git thing is so important, right? Before when you were doing file locking, checking in and checking out, you know, we that was not easy to do and a lot of teams were spending time throwing back changes and arguing over things before Git. Systems engineering we’re still working on getting that infrastructure still. There’s a lot of really excellent efforts to to get to that, but I think that one of the things we often fall back to is just this process of requirements one, 2.1, final final.

3:25 And so it’s it’s by start scaling that across different parts of the the engineering design stack is itself quite difficult. And so zooming back up to where we’re sitting is this messy human layer, right? So if you’re building a car, a rocket, or plane, it takes constant alignment between pretty much everyone you need to be involved with. But at the very top you have that interpretation of the requirements that you need to work with, which often sit in documents or siloed databases.

3:57 You have models that live in walled gardens, and then you have reviews still happening in meetings. So, how can we elevate that to something that is more collaborative across a variety of personas? And so, I’m talking about what our approach to this is Syskit. We’re focusing on these systems engineering layers specifically. I realize it’s a little bit higher up compared to a lot of the work we we see presenting at CDFAM, but we think this is really important because this is more about what few parameters do you care about as an engineer?

4:27 Right, we’re not going to build a a a a geometry solver. We’re not going to build a finite element analysis tool. I don’t think like that’s not our expertise. You There’s a lot of really excellent people in this room working on that, which is excellent. What we care about is this light touch parametric backplane that is versioned like code, handed off to the tools that you already know and trust.

4:50 And so, that’s what that’s literally what we’re building with Syskit. And two decisions that we made do the heavy lifting for this. All of the information is in this industry-developed domain-specific language, system modeling language version two, that is a way to describe physical reality as code. It’s really really cool to put it that way because we haven’t really had that in quite this level before. And part of this is that there is industry consensus from the the developing committees that this is actually how we want to exchange this data moving forward.

5:27 And second is we’re storing this in native Git. Since we’re storing this text, we get all the Git stuff for free, and we can live on top of all of the platforms that our customers have already adopted to support these activities. And and we’ve built these three different personas into this platform. So, we have three different people that we care about or things or ways of interacting with the data itself.

5:50 We have humans. This is the traditional way of doing systems engineering, drawing lines and boxes that represent other activities that are then handed off and communicated with in order to communicate intent. We also have automations. So, this is just a friendly Python interface that talks to our graph back end, maps the system L schema with an interpreter that does the math to help constrain decisions being made either on the human side or on the agent side.

6:19 And lastly, we have the agents, which is our MCP server. It talks to you know, whatever you need to want to plug into it, plus the harnessing and additional trained models that can help refine that accordingly. And because of that back end, every parameter change is a commit traceable across this whole life cycle. So, you make a design change of your target altitude, for example, and we can verify against that using the code, and this itself is tracked, committed, and communicated to anyone else as we’ve connected to different repositories and share this data over time.

6:54 And so, one thing I wanted to talk through today is expanding on that excellent demo that we we did last night with the team that had that 1.5 kg change. In that case, we had the Estuary back end on that, and then it increased it to 3 kg. And what we saw yesterday was more of this co-pilot approach of a human editing it, and then the pipeline checking it and pushing it off.

7:19 Two things that I would like to explore are the agent proposing the work and the human accepting it. And then we have the multi-agent approach as well, where you have agents working on conflicting changes that then, you know, you’re able to then go resolve. And so, let’s take a look at this part again. So, we change the value from 1.5 to 3. We can take a look at the diff, take a look at the change.

7:45 This ends up being a readable change that we can accept. And this is this is incredibly lightweight way of accepting that, right? This is I barely call this I would wouldn’t even call this an AI approach because we are just making the change ourselves and then validating in the pipeline in the back end. So, let’s go ahead and update the commit message because we are good developer citizens and always put descriptive commit messages in.

8:10 And then let’s go ahead and see what that change ends up looking like. So, we go back to the diff, we can visualize it. Let’s go and pull that up. And then we’ll go ahead and zoom back in and see that we changed one of the initial parameters and then we also that had some downstream impacts on the higher-level system model that we care about as well.

8:37 But what we didn’t see is that the pipeline itself did not pass. And so, that’s how you can assist before you get to the agentic layer failing these builds. And this is kind of the more traditional way we’ve been seeing this approach work. But let’s get into a prompt. So, let’s start to go down that pathway of starting with some text and then talking to the agents to drive engineering changes.

9:01 In this case, we’ll start with this change. We’ll ask it to do some we’ll pull down the change or the branch. We’ll say hey, the mission needs to change. Can you update it? And we ask it to do that. It gives feedback some concepts and ideas. And then we push it back up. So, I’m interacting with a robot in this case to to get that out. I’ve accepted some of the changes.

9:23 And then I skip over to the just get side of the things to see what has actually changed. So, I’m in the merge request that we made and I can look at it on the code side or I can look at the graph side. And so this is just having that guidance in place to work both human and agent together to make sure you’re moving towards what you need to be building in a mission-critical system.

9:52 And so the next one, let’s take a look at what happens if you have two different agents working on competing concepts. On the left we have a desire to double the payload mass again, so from three to six, while maintaining the range parameters. On the right, we’re just going to double the range while keeping the new payload the same. And so what we’re able to do, and I I’m using Claude for this specifically to show us connecting to the MCP server headlessly without the the SysML user interface, so we can plug into existing infrastructure that is already working with SysML files and and get.

10:27 And we are developing these these competing changes. And so on the left, it’s really exploring, it’s actually going down, it’s adding some more calculation blocks to additionally constrain the design. And on the right, we’re just making a simple change. And so with two to one of the initial parameters, expecting it to get picked up downstream. And so where we end up with that Let’s go ahead and take a look at the diff here.

11:01 So we are able to to build something and and propose something that is syntactically correct and makes sense, but we want to catch that we want to catch that merge conflict. Not It’s not even like an actual merge conflict because the code is fine. It’s a It’s a conflict of intent that just does not make a compatible design change. And so with that we can see that the actual code itself is fine.

11:31 Let’s wait for a second to scroll forward. And then when we go to make our merge request, in this case we’re making it ourselves to show off the ability to do it inside the application. But you can always have the agent do it for you. And we can see that the changes look interesting enough. And then we can look under the hood and actually see that this is starting to fail.

12:16 And then we can see that we’re not expecting this pipeline to advance. And if we take another check a little closer, we’ll see that the build itself actually failed as well. So, in this case we’re seeing that the changes are in conflict and we are not progressing. And so for this, we see the human’s job moving up the ladder, right? So, we see them adjudicating this this change.

12:40 We can have someone come in and say which direction they want to go. But the dream is to then continue to have the humans move up the abstraction, right? They We We can offload this to an agent at the next stage, the next stage, then then progressively building towards that that dark factory concept. And so, what we’re we’re demonstrating is that the agents are proposing the work, pipelines are validating it, and the humans are the ones doing the final acceptance at increasingly higher abstractions in the stack.

13:11 So, kind of to to wrap up two more slides here. Where are we in the stack? We’re focusing on requirements, architecture, MBSE, initial calculations. There was a small set of parameters you actually really, really care about when building something complex that needs to be shared between organizations. We care about those those key parameters and we care about storing them in this computationally tractable way that we described here.

13:37 We then want to make sure it can be handed off gracefully using whatever infrastructure you’ve invested in to get that information into CAD, into FEA, and you know, further optimize that a lot like demonstrated last night. And so for us, we’re really excited about this this next layer where as you push the human for higher and higher up the stack at an actual large scale, how can we go from you know, putting in your high-level needs of whatever your UAS needs to do to actually just cranking out the the full design.

14:13 And you know, it sounds like the talks we were were having might be able to do that pretty, pretty soon. So, thank you for your time. I have a QR code if you’d like to sign on the application. We’ll also want to talk to you back at the booth. But yeah, thank you.