Agents Are Where Microservices Were in 2015 — Roberto Milev & Uday Kanagala, Navan

The talk opens with an architectural warning borrowed from the rise of microservices. That shift eventually produced useful machinery—Kubernetes, service meshes, circuit breakers, and container orchestration—but teams needed time to learn how to use it well. Splitting a poorly structured application into services did not fix its underlying design. Milev applies the same test to agents: establish a working single agentic loop before taking on the added complexity of multi-agent orchestration.

Navan’s production experience suggests that a reference architecture is nevertheless taking shape. The speakers organize it around runtime, memory, context management, cross-cutting operational controls, and orchestration. The rest of the talk walks up this stack, distinguishing components that have become usable from those that still need engineering work.

Traditional API services often scale by keeping instances stateless. Agents invert that assumption: they carry an ongoing session, need isolation, and may live much longer than a request-response handler. A production runtime therefore has to preserve session state and restore it when execution moves or restarts. AWS, GCP, and Azure all offer agent-oriented runtimes, but adopting one does not necessarily finish the job.

Navan runs on AWS and uses its agent runtime while supplying its own session persistence and rehydration. Rehydration is the operationally important step: the runtime must reconstruct enough of an earlier session for work to continue rather than treating a recovered process as a fresh agent. The talk does not describe the stored representation, consistency model, or recovery procedure, so this is an architectural requirement rather than a complete implementation recipe. Navan also uses multiple agent SDKs; the speakers characterize managed runtimes as broadly framework-agnostic even when each provider favors its own framework.

Memory starts from the same constraint as retrieval-augmented generation: an agent cannot carry unlimited information in its active context. The memory pipeline described here ingests material, extracts useful information, consolidates it, and later retrieves selected pieces. Retrieval is only the last stage; the system must first decide what deserves to become memory and how separate observations should be combined.

The speakers distinguish three useful timescales: short-term conversational memory preserves the current interaction, managed long-term memory carries information across interactions, and episodic memory records examples of attempts that worked or failed. Navan uses its cloud provider’s memory service but adapts it to its own use case. No retention policy, consolidation algorithm, or measured quality gain is given, leaving memory selection and lifecycle management as implementation-specific work.

Larger context windows do not remove context management. Too little context leaves an agent uninformed; too much can dilute the instructions and evidence that matter for the current task. Navan’s answer is to make a skill the unit of context rather than loading every domain’s material into every run.

A skill has two sides. It contains instructions and setup for a domain or task, and it contains the tool-execution capability used to perform that work. Navan composes an agent’s context dynamically from these packages, treating them as pluggable units that can be reused and tested independently. This moves context selection closer to software composition: a task receives the capability and instructions it needs without inheriting the whole system’s knowledge.

Progressive disclosure keeps the initial context small. The agent begins with limited information about available skills, then follows included metadata to load more detail as the task develops. The tradeoff is explicit: selective loading protects focus, but the system must reliably recognize which skill to load and when. The talk says skills are independently testable, though it does not show the triggering tests or an evaluation of skill-selection accuracy.

Kanagala makes the operational problem concrete with an agent that fails halfway through a 20-step or 30-step process. Conventional logs may contain the evidence, but an agent can emit too much reasoning and intermediate activity for an engineer to consume efficiently. The useful question changes from “What did the process print?” to “At which action did its progress diverge?”

Hooks at tool-call boundaries create structured interception points. Before or after a tool call, the surrounding system can block an operation, record an audit event, or emit a metric. Navan sends these events to Braintrust and examines traces and spans to locate where an agent became stuck. This is described as a day-two concern: frameworks make an initial agent relatively easy to build, while operating and diagnosing it later remains the harder job.

Navan’s traces include the current goal, reasons associated with operations, belief status, and tool calls. Decisions also carry a confidence score and signals indicating whether an answer was inferred or supported through multiple paths. An inferred result can be routed to a human for guidance. The speakers do not explain how confidence is calculated, calibrated, or converted into an escalation threshold, so these fields should be understood as review signals rather than proven probabilities.

Testing exposes the same nondeterminism from another direction. A conventional program has an expected sequence of operations that an engineer can explain. An agent may choose different intermediate steps on separate runs, and a change that fixes one failure can introduce another. An assertion over one final string therefore says little about whether the agent reached a goal efficiently or by an acceptable route.

Navan relies heavily on trajectory evaluations for multistep work. Instead of demanding one deterministic 30-step graph, an evaluation observes movement from the initial intent toward the destination. It can then assess how far the run progressed and use that progress to reason about completeness and efficiency while allowing the chosen path to vary.

Trace signals connect diagnosis to evaluation. If a result depends on an inferred answer, that fact can help classify a behavioral change as a regression and guide the next fix. The talk does not provide a trajectory-distance formula, reference path, weighting scheme, or passing threshold. The mechanism is therefore a testing direction—score the path and its progress—not a fully specified evaluation standard.

Guardrails begin with information governance: enterprise agents can send sensitive material to models, sometimes without sufficient awareness. They also expose a deeper identity problem. Traditional authorization usually recognizes a person or a service account. An agent may act for the former while using the latter, which makes the familiar identity model incomplete.

The travel example makes the ambiguity visible: a user asks an agent to book a flight whenever the fare falls below $200. The user sets the condition now; the agent may decide to execute much later. Who made the eventual purchase—the user, the agent acting for the user, or a service identity used by the agent? The price threshold does not answer which credentials, permissions, or delegation policy should govern the transaction.

Navan responds with fine-grained policy checks before and after every tool call. These guardrails can inspect and block actions where they cross into external systems, rather than relying on a single check at the beginning of a session. The talk identifies the enforcement points but does not specify the delegation token, purchase policy, revocation behavior, or treatment of a session whose authority changes before the delayed condition becomes true.

The opening microservices analogy returns when the speakers compare single-agent and multi-agent orchestration. Navan chose a single master agent that progressively loads sub-skills and decides what belongs in context for the current use case. The speakers also mention sub-agents within this arrangement, but do not define precisely where a skill ends and a sub-agent begins. The supported design principle is centralized navigation with modular capabilities, not an absolute ban on internal delegation.

Agent-to-agent communication becomes more compelling when it reflects an organizational boundary. Two teams may own separate agents and need an explicit way to communicate without collapsing their systems into one implementation. The speakers present A2A as an emerging protocol for expressing contracts in terms of skills across that boundary. This is a narrower justification for multiple agents than orchestration for its own sake: separate ownership creates the interface.

Milev closes by grading the stack unevenly. In his assessment, runtime and scaling are largely solved, while memory is maturing through better models, operating practices, and cloud services. He also sees tool calling and MCP as points of industry convergence. These are the speaker’s production judgments, not guarantees that managed runtimes or memory services cover every reliability requirement.

Observability remains less settled. OpenTelemetry can be adapted to agentic calls, but the speakers question how naturally it represents them. Testing patterns are becoming more usable despite agent unreliability, and orchestration now offers recognizable large-agent and small-agent patterns. Their recommendation stays conservative: use the simplest arrangement that works and avoid overengineering while these patterns continue to change.

Cost is the clearest unresolved production problem. Navan finds agent spending difficult to predict and control. Reliable fallbacks and routing selected tasks to cheaper models are possible directions, but the talk does not present either as a finished strategy. Milev also points out an incentive mismatch: major AI vendors benefit when customers consume more tokens, while application teams must make that consumption economically predictable.

Replay and debugging remain difficult because engineers must reconstruct long, variable runs from large volumes of agent activity. The speakers suggest using agents to help analyze other agents’ traces and reduce that cognitive load, but no replay mechanism or measured debugging improvement is demonstrated. Standards such as OpenTelemetry and Agent2Agent are still evolving, with the latter described as young and influenced by particular vendors. The ending is pragmatic rather than triumphant: the industry increasingly knows which capabilities it needs, but engineers still have to build the dependable operating layer around them.