Ashish Shubham
Runs the show bussiness at ThoughtSpot
San Jose, California, United States
Actions
Ashish Shubham is a Fellow/VP of Engineering at ThoughtSpot, where he has spent nearly a decade architecting industry-defining AI and analytics products. He is an IEEE Senior Member and author of the book “Architecting AI Data systems”.
He is the creator of ThoughtSpot Embedded, a leading embedded analytics platform powering multiple Fortune 500 apps worldwide. He also co-architected ThoughtSpot’s AI Analyst, Spotter, and led the company’s first Agentic MCP Server integration, redefining how AI agents securely work with enterprise data.
Ashish holds multiple patents, has published widely read technical articles, serves on the committee of top AI conferences and frequently speaks at industry forums.
Links
Area of Expertise
Topics
Keynote: ThoughtSpot -- Prompt + Tools = Value. Everything Else Is Infra.
An agent is fundamentally simple: Prompt + Tools + Model + Boilerplate. The first three are where product teams create differentiated value—domain-specific instructions, purpose-built tools, model selection. The last one is everything else: state management, conversation history, context compression, streaming, cancellation, tracing, memory, persistence.
The problem is that "boilerplate" isn't trivial. It's 80% of the code but 0% of the differentiation. Every team rebuilds the same orchestration loops, the same streaming infrastructure, the same history truncation logic. At ThoughtSpot, we built an Agent Platform that draws a hard line between agent logic and agent infrastructure, letting product teams ship customer-facing agents faster by owning only what matters: their prompts and their tools.
This talk covers the infrastructure patterns behind that separation, diving deep into five hard problems:
State management across tool calls. Agents need to track state that evolves through multi-step tool interactions. We evaluated two approaches: stateless tools (state lives on the agent, passed as arguments to each tool) versus stateful tools (state lives in the tool service). Stateless gives you better testability and lets the LLM reason about available state variables; stateful avoids serialization overhead for large objects. I'll walk through concrete flow diagrams, show how we propagate state updates via tool response metadata, and discuss when each pattern makes sense.
Configuration-driven agent definitions. Our agents are defined entirely through config—templated system prompts with conditionals, tool server endpoints, sub-agent delegation rules, tool output compression strategies. This lets teams spin up new agents without writing orchestration code. I'll show the schema design and discuss how we expose runtime variables (tool call count, accumulated context from tool responses) to prompt templates.
Inter-agent communication. Complex workflows often require specialized agents collaborating. We support two patterns: agents-as-tools (parent agent calls a sub-agent like any other tool, receives structured output) and agent handoff (full conversation transfer with history). The platform handles the routing, context passing, and conversation threading—product teams just declare which agents can delegate to which, and under what conditions.
Shared memory across agents. When memory lives in the platform rather than individual agents, something interesting happens: knowledge accumulates across agent boundaries. A user's interaction with one agent informs another. We implemented tiered memory with opt-in scoping—tenant-wide knowledge, org-level rules, user-specific context—with a retrieval pipeline that surfaces relevant memory regardless of which agent captured it. I'll cover explicit memory updates (via user feedback), implicit extraction, and the tradeoffs between memory tiers.
Tool protocol design. We standardized on MCP for tool interfaces, but the protocol alone doesn't solve everything. I'll discuss patterns we developed on top: call cancellation semantics, progress message streaming, context variable propagation in tool responses, and an adapter layer for integrating existing services like protobufs to MCP.
Building for customer-facing scale adds constraints: high concurrency, conversation encryption, strict tenant isolation, auditability. I'll touch on how these requirements shaped our API design and infrastructure choices.
Takeaways:
- A mental model for separating agent value (prompt + tools) from agent infrastructure
- State management patterns: when to put state on the agent vs. in tool services
- Inter-agent communication: agents-as-tools vs. handoff patterns
- Shared memory architecture that works across agent boundaries
- MCP extension patterns for production agent systems
From Microservices to MicroAgents: MCP as the New Service Boundary
Abstract
The microservices revolution gave us a hard-won set of principles: small services with well-defined contracts, owned by independent teams, composable into larger systems, replaceable without rewriting the world. The agentic AI era is rediscovering these lessons the hard way. Most enterprises today are building agents the way we built monoliths fifteen years ago: each agent a self-contained stack with its own conversation store, its own auth, its own observability, unable to talk to the agent built down the hall.
There is a better pattern. We call it a MicroAgent, and it is to the agentic world what a microservice is to the API world. A MicroAgent is a lightweight, independently-deployable package consisting of two things: an MCP server that exposes domain-specific tools, and a prompt template that encodes domain expertise. That is the entire contract. No session management. No streaming code. No auth boilerplate.
Talk Outline (detailed)
Part 1: From Microservices to MicroAgents
- The principles we earned the hard way: bounded contexts, contract-first design, independent deployability
- Team ownership boundaries and Conway's Law in service architecture
- Why API gateways, service meshes, and shared platforms emerged
-The agentic monolith problem: three agents, three stacks, zero composability
- Why the first agent hides the cost and the third one exposes it
Part 2: The MicroAgent and Its API Contract
- The unit of value: MCP server + prompt template
- What a MicroAgent does NOT contain: sessions, streaming, auth, memory, tracing
- Ownership boundaries: one team, one MicroAgent, independent deployment
- MCP as the API contract: tool routing, prompt discovery via HTTP, If-Modified-Since caching
- State propagation: the _meta field as a state-update channel between MicroAgent and platform
- Backward compatibility rules for prompt templates and tool schemas
Part 3: The Shared Substrate
- Session events vs. message lists: designing for resumability and branching
- Context compression and tool output sampling as platform concerns
- Memory as a shared organizational asset across all MicroAgents
- Scopes, knowledge types, and on-demand generation via generate_memories
- File and artifact storage with reference passing
- Tracing and observability as platform defaults
Part 4: Composition and Engineering Economics
- Super-agents as orchestrators of MicroAgents
- Sub-agent delegation via as_sub_agent: true
- Conversation handoff and session transfer
- Framework landscape: Google ADK, OpenAI Agent SDK, AWS Bedrock AgentCore, LangGraph
- Runtime tradeoffs: self-managed Kubernetes vs. Lambda vs. Vertex Agent Engine
- The marginal cost of the next MicroAgent, and principles to take back to your own org
API World + CloudX + AI TechWorld 2026 Sessionize Event Upcoming
AI DevSummit + DeveloperWeek Management 2026 Sessionize Event
Ashish Shubham
Runs the show bussiness at ThoughtSpot
San Jose, California, United States
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top