Welcome, everyone. My name is Sam Kmezverk. I am an engineer, and thank you for your time. When I first got invited to do this talk, I wanted to chat about the different initiatives and the interfaces that were coming out to deal with agents, what the new processes look like, what that meant for us as developers. At the time, Access and Duet UI were the main things that everyone was talking about, so I built my talk around those. Shortly thereafter, everyone on the internet seemed to be talking about how dynamically generated LLM interfaces for the future. So that made half my slides obsolete. I rewrote it only for Antigravity to ship two weeks later and make the other half obsolete. So after this, I realized that trying to give a talk about specific agent tech is probably not going to be the best use of our time together. Whatever I say up here is probably going to be outdated by the time this conference is over. So instead, I want to leave you with a few principles that as a FDE and as someone who's worked in the field for a little bit now, I'm confident that these principles will remain true, no matter what the next big thing in UI agent interfaces is.
The first one comes from human orgs, and that is that only one person, only one agent should be responsible for the implementation of a task at most. In 1999, the NASA Mars Climate Orbiter was lost, which would cost a breezy 325 mil due to two teams simultaneously assuming that they owned the same requirement. Likewise, I'm sure all of us in this room have dealt with merged conflict hell when two people are confident that they're editing the same file with different contexts. And even in systems design, if you have two nodes that both think that they're the primary, you'll get what's called the split brain problem. And this is something that I've also seen in deployment when people are trying to apply agents to organizations.
One deployment I was on was with a company that was trying to automate their invoicing. So you create two agents, and critically, both of the agents were told your goal is to ensure that no invoice is left unsent. The learning here is that each task needs to be delegated once and only once to a single agent. That agent has complete control. The next principle also comes from human orgs, and that is that decisions and requirements need to have a specific name attached to them. At Tesla and SpaceX, they have a rule where if there's a requirement built into some product, some name needs to be attached to it, ideally someone within the org that they can reference if something goes wrong. Similarly, at Amazon, they have this single-threaded leadership model where one person is responsible for an entire project, and then their name is attached to all the decisions they're in. This is also something that I've seen in the field as well. I was working for an advertising agency that was looking to automate their end-of-campaign insights. They created an orchestrator agent, a whole bunch of separate agents to gather data from CRMs and surveys and whatnot, and then a whole bunch of agents on top of that that would synthesize the findings into something concrete. It worked very well until certain metrics just disappeared out of the blue.
Comments