Previewing Interrupt 2026: Agents at Enterprise Scale

The most interesting technical signal from Interrupt 2026 isn't the speaker list—it's what the talks reveal about where production agent systems are actually breaking. Three themes stand out as genuinely hard problems that teams are solving right now, not aspirational research.

First, the eval problem has moved from "do we have evals" to "are our evals actually tied to what breaks in production." Lyft's approach is telling: they're building evaluation systems around specific product policies and user flows, not generic benchmarks. This matters because most teams are still using pass/fail evals on synthetic test cases that don't capture the actual failure modes they see in traces. The gap between a 95 percent eval score and a production incident is usually about edge cases your eval set doesn't cover. Lyft's closing the loop between failed traces, ops teams, and engineering—which means they're treating evals as a continuous feedback system, not a pre-deployment gate. That's the right pattern, but it requires tooling that can surface patterns across thousands of traces and route them back to eval authors. Most teams don't have that infrastructure yet.

Second, Apple's work on dynamic graph construction at runtime is addressing a real constraint in LangGraph's architecture. The standard model assumes you define your graph structure upfront, which works fine for deterministic workflows but breaks down when you need to support low-code agent building at scale. Serving 15,000 employees with a low-code platform means non-engineers are defining agent behavior, and the graph needs to adapt without requiring a redeploy. Apple rearchitected assumptions about graph construction, caching, and context management to make this work. The technical details aren't public yet, but the implication is clear: if you're building internal agent platforms, you'll hit this wall. The question is whether you build your own solution or wait for LangGraph to absorb these patterns upstream.

Third, LinkedIn's claim about hiring 10x faster with an AI recruiting agent is worth unpacking. Recruiting is a high-stakes, high-latency workflow with lots of unstructured data and subjective decision-making. If they're actually running this in production, they've solved several hard problems: structured extraction from resumes and job descriptions, multi-turn reasoning about candidate fit, and some kind of human-in-the-loop workflow that doesn't bottleneck on manual review. The 10x claim probably means they've automated the initial screening and outreach steps, not the entire hiring pipeline. But even that requires reliable hallucination detection and a way to measure false positives (bad candidates advanced) versus false negatives (good candidates rejected). Those metrics are hard to instrument and harder to tune.

What's missing from the preview is any mention of cost management or latency optimization at scale. If you're running agents for 15,000 employees or processing thousands of recruiting workflows, token costs and TTFT become real constraints. Apple's probably caching aggressively and using smaller models for routine tasks. LinkedIn's likely batching candidate evaluations and using async workflows to hide latency. But without specifics on token throughput, average trace costs, or p95 latency, it's hard to know what "production scale" actually means here.

The broader pattern is that 2026 is about operationalizing agents, not proving they work. That means evals tied to production failures, infrastructure that supports dynamic behavior, and feedback loops that route problems back to engineering. If your team is still debating whether agents are viable, you're behind. The real work is figuring out how to measure, debug, and improve them once they're live.