As we enter the second half of the year, we wanted to shed some light on one of the key brains behind the Tagup operation. Will Vega-Brown co-founded Tagup alongside his former MIT classmate, Jon Garrity. Will is responsible for all technical efforts and teams at Tagup. His role includes researching novel methods to enable automated systems, broadening the applicability of machine learning to industrial applications.

I recently sat down with Will for a 45-minute Q&A. First, I asked about topics ranging from the evolution of artificial intelligence (AI) to the challenges of industrial AI deployment, and technologies enabling progress in industry. Then, we discussed Tagup technology, the skills he looks for when hiring technical talent, and how Will thinks about machine learning outside of his day-to-day responsibilities. 

I hope you’ll learn as much as I did.

Artificial intelligence is referenced across multiple domains, from robotics to image generation. How does Tagup’s technology fit into the bigger AI picture?

To answer that, I need to first dig into what you mean by AI. AI has meant a lot of different things over the years. In the 80’s it meant expert systems. In the 2000’s it generally meant probabilistic graphical models. The 2010’s mostly meant convolutional neural networks and image processing. Now, of course, it's most famously known for language transformation like ChatGPT. What the average person thinks AI means is going to be driven by the latest big success. 

It’s an old truism that when any robotic system becomes sufficiently advanced and useful, we stop thinking of it as robotics. Take a printer, for example. A printer has pretty advanced controls. It does something highly non-trivial that saves humans a lot of time through automation. Is that a robot? 

If you asked someone 60 years ago, absolutely, it would be a robot. Now it's not, and we're kind of seeing something similar with AI. When things become useful and well understood we no longer think of them as artificial intelligence.

So that's all a precursor to how Tagup fits into the AI space. 

We work where there's not a lot of data and where there are strong physical models of how the world works. Something like GPT works in the opposite kind of domain, where there’s an almost unlimited amount of natural language training data. Compare that to industrial time series data, whose volume is really hard to access and standardize. 

Tagup differentiates itself by using other sources of information that aren't as readily applicable. This could mean using physics to build principled models of how an HVAC system works. By starting with that baseline, we can use a much smaller amount of data to fine-tune our model of what actually happens in the real world. And that means that we can get much stronger results with much less data than we otherwise would need.

Why is it so challenging to deploy AI in industrial settings?

I think you can break it up into two categories — the practicalities of deployment and the organizational challenges in using these systems. 

When I say practicalities, I mean how there isn't a single standard way of representing data. For example, let's say you have two different temperature sensors that are installed on two different pieces of equipment. When can we say they are measuring the same thing? What is the best way to define the schema of data? That is not a problem that has a universally understood answer — the HVAC community has a few conventions, power producers have another — and that's a thing we have to deal with for each new deployment. 

There's also connectivity issues to overcome. We work with wind turbines, which are large machines that are generally far away from major cities and physically far apart from one another. It's not a trivial exercise to get the data from the turbines into our cloud services. For cooling optimization in commercial HVAC systems, we’re looking to deploy on thousands of different buildings. Collecting data from each one of those buildings requires some amount of hardware.

Once you get past the physical challenges of connectivity, you get to the software challenges. Often, these are systems that were developed anywhere from 5 years ago to 50 years ago. There's digitized systems from the 70’s and 80’s that are still in use that we have to interface with. So, we have multiple generations of protocols we're trying to work with.

Then you get into the more organizational limitations. Often, the people who get value from our software are going to be the operators, the engineers. Those are not the people who control access to data. That's typically an IT or cybersecurity group. So, in large organizations, having to get buy-in from two different groups creates some real challenges. 

Furthermore, it's hard to take a big, mature organization, and convince them to apply novel technology to hundreds of millions of dollars worth of equipment. They are naturally quite risk averse, where they don't want to change very quickly and wind up putting that equipment at risk. The challenge here is how to align their priorities to our Foresight capabilities, shifting from reactive to proactive processes and protocols that empower operators in the field. 

What new technologies are enabling improvements in this arena?

One of the technologies that is becoming more common is open-source projects like Haystack. Haystack is an open initiative to unify the way that building automation systems (BAS) represent data. I had the example earlier, if I have two different temperature sensors on two different pieces of equipment, how do I know if they're measuring the same thing? Haystack is an answer to that question. If you find a building that's already been annotated with Haystack information, you can immediately know all of the sensors and what they're actually measuring. This avoids having to parse through how some integration engineer decided to name things 30 years ago.

Another example, again in the building automation space, is the Niagara stack. I talked about connectivity challenges and old formats earlier. Historically, the one piece of equipment that was able to understand all the data that was blowing through a building was the building automation system. Those are traditionally closed off in the sense that the manufacturers made sure no one could interface with the system without their explicit knowledge and consent. Niagara is an open BAS. It’s designed to make it easy for people to plug in and modify the system, which is great for a company like ours where we want to be able to actually adjust how things are controlled based on factors impacting equipment performance. 

The third external technology I’d point to relates to the physical limitations of being able to access data. For maybe the last 30-40 years, the main way that you would get large volumes of data around is by running wires. Wireless communication has always been a bit of a struggle, but that's starting to change as well. Off-the-shelf hardware now makes it possible to collect sensor data from the field at relatively low cost.

What part of Tagup's tech stack are you most excited about?

I talked a bunch about external technologies. Those things were all about communication — how we get information into our platform. Our comparative advantage is what happens next. 

Tagup has designed low-cost gateways that let us connect to existing building automation protocols like BACnet or Modbus, and transmit data directly to our cloud without having to install an expensive, licensed piece of hardware. These allow us to handle configuration and reconfiguration remotely, with a very low network profile. The upshot is that rather than having to pay a system integrator to go on site and sit there for a day or two, we can simply ship a box, plug it into an ethernet port, turn it on, and immediately be able to go live with our deployments. This will reduce deployment timelines from weeks to hours. 

Another thing worth highlighting is our physical modeling toolkit, which lets us combine the power of modern AI—deep neural networks, distributed training on GPU clusters—with traditional model-based engineering approaches. The physics-based models let us perform well in novel situations, while the deep learning models let us fine-tune to notice subtle patterns and interactions between machines. Our algorithmic advantage lies in combining the two and rapidly iterating over models for each new deployment, with relatively few hours of data scientist time.

All of this to say we can focus more of our time and more of our capital on model training and delivery — the stuff that actually generates value for our customers. 

Can you share one long-term goal for enhancing Tagup's technology?

Looking beyond the next twelve months, we’re thinking about ways to take advantage of the excitement and progress around language models. I've mostly drawn a contrast between those models and what we do, but there are still a lot of applications of language models to what we're doing. 

Operators need to be trained to use our software. It might be possible to cut that training process entirely if they can interact using natural language with their systems. For example, one of the things we're doing with a wind turbine customer is working towards generating work orders that their engineers, operators, and technicians can use. We're doing that very manually right now, but a language model would be the perfect way to turn a summary into a work order suggesting actions. A language model augmented with a more focused model could possibly make that a reality, and that could be incredibly valuable for our customers.

What skills do you look for when hiring technical talent?

For technical hires, which are most of the hires that I've made, we normally look first and foremost for intellectual flexibility. People who can learn new skills very quickly. People who can think about the underlying, physical constraints on a problem, rather than just the most obvious solutions. People who can identify what is possible for us to do, rather than the standard way of solving a problem. 

That comes from the set of problems we solve as a company. They're not necessarily aligned with things there are standard solutions for, and if they were, they’re too far afield from any one, conventional profile.

A very common set of roles for a SaaS company might be front-end engineers building a web application, backend engineers managing your databases and APIs, and maybe a DevOps engineer keeping everything deployed. We haven't really been able to make there be enough, consistent work in any one of those areas to justify separate hires for each of those things. That's because we're deliberately focusing as much of our effort on the thing that really generates value, which is machine learning and optimization. Our software team has to be very flexible, able to work on a little bit of everything, and capable of switching gears very quickly. That's a pretty rare skill set and one that we've been lucky enough to find in a bunch of very bright engineers. 

Beyond that, especially for data scientists, we prize people who can really understand the algorithms we are working with. We do a lot of bespoke algorithmic work, coming up with algorithms that are designed specifically for the kinds of problems that we are solving. That has a lot of advantages over taking an off-the-shelf piece of software and applying it to an existing problem. But, it is a harder set of tasks to work on. It requires, for example, a balance of mathematical maturity with software engineering expertise. I think that's reflected in the fact that many of our data scientists have an academic background.

I think the one other thing I would highlight is we really search for people who can embrace a culture of open communication. We don't want people who are going to be parochial or territorial. We want people who will take ownership over whatever problems they can, people who are excited about collaboration. We’ve passed on some otherwise qualified engineers because they were too focused on owning one narrow part of the stack, and weren’t willing to look beyond that.

How do you think about AI outside of your day-to-day responsibilities?

I love artificial intelligence and machine learning. It's been my passion for at least a decade. I'll focus on one answer, which is thinking about the problem to solve within AI.

So, what is the biggest problem in AI right now? I think it is what’s currently called AI safety — what has in the past been called interpretability or verifiability. If I design a very complicated, artificially intelligent system, how do I know what it's going to do when I put it in control of some process? 

With GPT-4 that's a nice, hypothetical question. With the kind of industrial automation that we do, it becomes very concrete. If I have a system that is so complicated I don't fully understand it, and I put it in charge of opening and closing switches on the electric grid or controlling all of the equipment in a factory, the consequences of malfunction are much higher. There's a piece of this when you talk about adversarial settings — the “what's the worst that could happen?” 

I think AI becoming malevolent and trying to outsmart us is still a science fiction question for probably the next decade. Certainly, it's worth pondering and being aware of the risk. In my thesis work at MIT I spent some time thinking about these questions, and I think I have a unique perspective on them. I would love to invest more time in working on those problems — on coming up with systems that are guaranteed to maintain certain safety constraints. 

I expect AI to drive nearly every industrial process in the not-too-distant future, and it’s exciting to be part of a company on the leading edge of what’s possible.