VentureBeat's October Summit Tackles the Four Layers of the Agentic Stack

If you've tried to run more than a handful of agents in production, you already know the dirty secret: the hard part isn't the model, it's everything around it. Memory, context, cost accounting, GPU allocation, orchestration logic that doesn't fall over when three agents want the same resource at once. That's the actual engineering surface of agentic AI right now, and it's the subject of VentureBeat's Agentic Infrastructure Stack Summit on October 28 in San Francisco.

The format is worth noting before the content. Instead of the usual conference pattern of a vendor pitch followed by a panel, VentureBeat opens each session with proprietary research from its VB Pulse program, survey data from enterprise technology leaders who are actually deploying this stuff. A VentureBeat journalist then pushes speakers from companies like Microsoft, Uber, T-Mobile, Box, and Cisco to react to the numbers in real time: do they match what they're seeing in production, or not. Applications close October 26.

Track 1: fewer agents, better coordinated. This is the orchestration track, and the framing is blunt: enterprises aren't scaling by adding more agents, they're consolidating and coordinating the ones they have. T-Mobile CIO Jeff Simon is talking about orchestrating customer experience across AI-driven care, voice models, and agent handoffs at carrier scale. WEKA's Chief AI Officer Val Bercovici is making a sharper technical claim worth flagging for anyone doing capacity planning: orchestrating agents is fundamentally a memory problem, and the teams that treat it that way get more throughput out of every GPU they own. Box CTO Ben Kus is presenting what he's calling the "six-month AI stack," essentially a rethink of orchestration, memory, context, and data infrastructure on a timeline that keeps shrinking. PayPal's Deepika Khera also speaks in this block.

Track 2: less context, better answers. Here's a useful heuristic for anyone context-engineering their agent pipelines: more retrieved context isn't the goal, better-targeted context is. Adobe SVP of Engineering Anjul Bhambhri, who's spent thirty years in enterprise data and analytics, covers how Adobe's Customer Experience Orchestration org handles multi-agent state at scale. Databricks' Bryan Clark, who leads the Lakebase and Neon product teams, talks state management infrastructure for agents. And Cisco Outshift's Vijoy Pandey, who holds 80+ patents and leads Cisco's AGNTCY and Internet of Cognition work, is presenting a session title that's basically a thesis statement: "Context Is Not Coordination." Worth sitting with that distinction if you're building multi-agent systems, because conflating the two is a common design mistake.

Where the money actually goes

Track 3 is inference economics, and it's probably the most immediately useful track for anyone with a GPU bill. The framing session title says it plainly: "nobody can tell you what an AI agent costs, and your cheapest one may be your most expensive." That's not a throwaway line, it's a real measurement problem. Per-token cost doesn't capture retries, tool calls, failed completions, or the context window bloat that comes from poor memory design.

Artificial Analysis co-founder Micah Hill-Smith, whose benchmarking data shows up in model launches from OpenAI, Anthropic, Google, and Nvidia, opens the track with metrics for decision-making across the stack. Uber Distinguished Engineer Uday Kiran Medisetty follows with a session on building cost-efficient AI that delivers ROI at Uber's scale, drawing on his work leading agentic coding, AI debugging, and large-scale refactoring initiatives internally. The track closes with a WEKA-sponsored panel featuring Upwork VP of Platform Infrastructure Sudhanshu Bist and Bercovici again, digging into model routing, caching, and GPU allocation decisions. Bist's angle is particularly relevant if you're mid-migration: he's spent the last decade rebuilding Upwork's infrastructure as the company moved from web-scale traffic patterns to production AI workloads, including the shift off on-prem data centers.

Track 4 zooms out to physical infrastructure: AI factories, the term the industry's settled on for purpose-built compute facilities for agent workloads. Microsoft's Reynold D'Sa, Corporate VP for Silicon, Cloud Hardware, and Infrastructure Engineering, presents what Microsoft is calling its blueprint for the agentic era. Omni's Anna Nicanorova and Acxiom's Anand Lakshmanan close the day with a session on open, interoperable infrastructure design, governance built in from the start rather than bolted on afterward.

There's also a hands-on workshop slotted into the lunch break: "Governing Agentic Systems at Production Speed," run by OneTrust's Shishir Agrawal and Kian Kamyab. If you're trying to figure out how to put guardrails around autonomous agents without freezing your deployment velocity, this is the session that addresses it directly rather than theoretically.

Key Takeaways

The underlying thread across all four tracks is that agentic AI has quietly become an infrastructure discipline, not a model-selection exercise. Memory architecture, context engineering, cost attribution, and physical compute design are now the levers that determine whether agent systems actually work at scale.

• Orchestration is increasingly framed as a memory and coordination problem, not an agent-count problem; WEKA and Box both make this case explicitly.
• Cost-per-agent is poorly understood industry-wide; Artificial Analysis, Uber, and the WEKA/Upwork panel are all converging on better unit economics for inference.
• Context and coordination are getting pulled apart as distinct engineering problems, per Cisco Outshift's framing.
• AI factory design (power, networking, memory) is now a first-class concern alongside software orchestration, with Microsoft and Omni/Acxiom presenting competing architectural philosophies.

For engineers building or scaling agent systems, the sessions worth prioritizing are the inference economics track and the memory-as-coordination argument from WEKA and Box. Both get at the question most teams are currently answering badly: not "can this agent do the task," but "what does it actually cost to let it try."