What building Navi taught us about agents

Navi is our personal agentic operating system, long-horizon memory, device and OS control, calendar and comms orchestration, a single agent that plans, executes, and learns across a digital life. We build it for ourselves, which means we feel every bad decision directly. Here's what it's taught us that we now bring to client work.

The model is the least interesting part

Everyone benchmarks models. Almost nobody benchmarks their tools. In practice the quality of an agentic system is dominated by the tool layer, how the actions are named, what they return, how errors surface, whether the agent can tell what happened. A great model with vague tools flails. A modest model with sharp, well-described tools feels smart.

So we spend our time where the leverage is: tool schemas, return shapes, and the traces that let us see why the agent did what it did.

Memory is an architecture problem, not a prompt problem

"Just put it in the context window" stops working the moment the horizon gets long. Navi taught us to treat memory as a real system: what gets written, when, how it's retrieved, and, the part everyone forgets, how it's forgotten or revised when it turns out to be wrong. A memory that can't be corrected is a liability that compounds.

Guardrails before capability

The scary version of Navi is the one that can act on your machine. We built the enforcement and permission layer before the exciting autonomy, not after. Every action the agent can take is scoped, logged, and reversible where it matters. This is the single most transferable lesson to client builds: capability without guardrails isn't a feature, it's an incident waiting for a date.

The interface is the product

The thing that makes Navi feel like a chief of staff rather than a chatbot isn't the intelligence, it's the interface around it. Where it interrupts, where it stays quiet, how it shows its work, how you correct it. Two systems with identical models and tools can feel completely different depending on this, and it's almost entirely a design problem.

Which is exactly why we're a full-service studio and not a bag of models. The agent is engineering. The thing that makes it usable is design. Getting people to try it is marketing. Building our own products is how we keep all three sharp at once.

If you're building something agentic and want a team that's already made these mistakes on their own dime, let's talk.