← All speakers

Bio, Work & Ideas

Sandipan Bhaumik

Conference affiliation: Databricks · 2026

Sandipan Bhaumik is a data and AI technical lead at Databricks and the creator of AgentBuild, a newsletter and community devoted to making enterprise AI agents reliable. He applies distributed-systems architecture to a problem enterprises routinely underestimate: keeping autonomous software observable, governed, and recoverable after deployment.

Before joining Databricks, Bhaumik worked at Amazon Web Services, helping organizations build cloud data and analytics platforms. His AWS writing on analytics-as-a-service examined multitenancy, data isolation, security, and governance across managed, customer-controlled, and hybrid architectures. Experience with financial services, healthcare, and software companies shaped his emphasis on operational accountability in regulated environments. He launched AgentBuild in 2025 to share practical approaches to production agentic systems.

  • Evaluation before model selection. Bhaumik starts with measurable business outcomes, representative examples from domain specialists, and automated testing. In a retail-banking deployment, model selection followed the construction of an evaluation pipeline. Production failures feed a living evaluation dataset, while targeted test runs control evaluation costs.
  • Behavioral agent evaluation. Correct answers can conceal duplicated database calls, unsafe tool choices, unnecessary retries, or expensive loops. His enterprise production framework combines deterministic checks, model-based semantic assessment, execution tracing, governed data, and clear incident ownership.
  • Multi-agent systems are distributed systems. Bhaumik traced inconsistent credit decisions to a stale cache that left agents working from different customer records. His orchestration architecture distinguishes autonomous event choreography from centrally managed workflows and uses immutable versioned state, circuit breakers, and compensating transactions to prevent cascading failures and support recovery.
  • Agent handoff contracts. In his analysis of failed agent handoffs, Bhaumik argues that interfaces must preserve meaning, provenance, authority, and user intent—not merely transmit correctly formatted data. A risk assessment, for example, should never become authorization to freeze an account through a downstream model’s unsupported inference.

For Bhaumik, production readiness extends to privacy safeguards, auditable execution, prompt change management, model upgrades, human escalation, and explicitly assigned operational responsibility.

Read the topics behind these talks

2 conference talks

Key ideas

Scroll to read ↓

A stale credit score shows why multi-agent workflows need explicit coordination, immutable handoffs, circuit breakers, and compensation—not just more capable agents.

  • When the next agent changes the problem
    1:31 ↗
  • A successful database write, an incorrect decision
    2:34 ↗
  • Choose who owns coordination
    4:34 ↗
  • Pass versions instead of overwriting shared records
    11:28 ↗
  • Reject unacceptable inputs at the handoff
    15:23 ↗
  • Stop calling a dependency that keeps failing
    16:24 ↗
  • Undo completed work when a later step fails
    18:58 ↗
  • Assemble the workflow, state store, and telemetry
    20:56 ↗
  • Map the architecture onto Databricks
    22:03 ↗
  • Production value comes from the system
    25:07 ↗

Key ideas

Scroll to read ↓

A retail-banking chatbot shows how evaluation, tracing, governed data and incident response turn a convincing AI demo into a system an enterprise can operate.

  • When the demo stops answering correctly
    0:15 ↗
  • Five responsibilities before implementation
    4:52 ↗
  • Evaluation is the system specification
    7:34 ↗
  • Trace an overdraft-fee dispute
    12:25 ↗
  • Manage the data agents read and the data they produce
    15:05 ↗
  • Choose coordination around dependencies
    20:05 ↗
  • Govern actions, prompt changes and model changes
    22:25 ↗
  • Rebuild the banking project around an outcome
    24:36 ↗
  • A policy update exposes stale retrieval
    29:18 ↗
  • Connect evaluation to incident response
    30:53 ↗
  • Start with one automated evaluation
    32:46 ↗
  • Keep change history useful and evaluation affordable
    34:12 ↗

References