Putting AI on a device changes the conversation

There are two different AI conversations in my work. One concerns using agents to change how we develop software. The other concerns the intelligence that runs in the product itself.

At Samsara, the second conversation includes edge AI, sensor fusion, and software running on constrained devices. I find that work compelling because the model has to participate in a physical system with a real budget.

Accuracy matters. So do response time, memory, compute, power, hardware cost, updateability, and the ability to understand behavior in the field. The architecture has to account for the combination.

Ask where the decision belongs

When considering a capability, I want to understand which parts should happen on the device and which belong in backend services.

Some decisions are sensitive to response time or connectivity. Some benefit from information available beyond one device. Some can be split into local processing and later analysis. The useful question is what arrangement satisfies the product requirement at an acceptable total cost.

I am wary of making the location an identity: that we are an edge team, or a cloud team, so the answer must live on our side. That substitutes organizational convenience for a system decision.

The alternative is to make the tradeoff concrete. What information is needed? When is the result needed? What can the device support? How does the behavior degrade? What must be transmitted, retained, or reprocessed? How will the implementation change as the product evolves?

Put the budgets together

A change that looks inexpensive to one team can move cost elsewhere. More local work can affect the device budget. More backend work can affect communication and service requirements. More complexity can affect testing and long-term support.

I want those effects visible when the choice is made, rather than discovered by the next team in the chain.

This is one reason I spend time connecting hardware and ML decisions. A shared target gives the teams a basis for discussing tradeoffs. Without it, each discipline can optimize the part it sees while the complete system becomes harder to deliver.

I do not publish internal savings or performance claims here. The point is the decision process: measure the candidate arrangement against the behavior the product needs, including its operational cost.

Sensor fusion is also an ownership problem

Combining signals raises questions beyond the algorithm. Which assumptions do the inputs make? How do we recognize a missing or unreliable signal? What does the consuming system believe about the result?

Those questions need owners and test scenarios. A strong isolated model is insufficient if the surrounding pipeline supplies inconsistent inputs or hides uncertainty from the part of the product that must act on it.

That is where architecture, test design, and team structure meet. Someone needs to keep the complete behavior in view while specialists work on the pieces.

The connection to coding agents

Working with development agents has reinforced the same habit. I want to know what the complete system is being asked to do, what evidence will establish success, and which local improvements create costs elsewhere.

The domains are different. The discipline of making constraints explicit is useful in both.

That is the AI work I want to lead: faster development supported by clear evidence, and product intelligence designed around the environment in which it has to operate.