← All speakers

Bio, Work & Ideas

Tisha Chawla

Conference affiliation: Software Engineer · Microsoft · 2026

Tisha Chawla is a Microsoft software engineer and co-creator of AgentPlane, an open-source initiative building infrastructure for reliable AI agents. Her work addresses two critical production failures: agents making consequential decisions that engineers cannot reproduce, and autonomous workflows accumulating costs beyond their operators’ control.

Chawla studied at Vellore Institute of Technology from 2020 to 2024 and interned at Microsoft before joining as a software engineer. Her early projects included a Microsoft Engage 2022 application and a tool for analyzing SEC EDGAR filings. At Microsoft, she has worked on enterprise software-engineering agents, site-reliability workflows, and specification-driven development associated with the Commerce and Ecosystem Data Platform.

Production systems that remain accountable

  • Replayability over model determinism. Chawla distinguishes forcing a model to repeat itself from reconstructing an execution that already happened. Request batching, mixture-of-experts routing, floating-point computation, retrieval changes, and tool behavior can produce different outcomes from the same prompt, even at zero temperature. Her work on production-agent failures emphasizes preserving execution state instead of assuming reproducible generation.
  • Chronicle and boundary-level recording. With Susheem Koul, she created Chronicle, which records inputs, outputs, and metadata around model calls, retrieval steps, and tools. Their stock-trading example follows an agent that mistakes a requested dollar amount for a share quantity: the API succeeds, but the transaction is wrong. Replaying the captured trace lets engineers stub model responses, exercise repaired safeguards, and turn the incident into a repeatable regression test.
  • Run-scoped token governance. Their TokenOps project tracks costs across an entire agent execution and enforces shared budgets while work remains in progress. Interventions include switching models, restricting subsequent calls, and stopping runaway loops. A Microsoft-published analysis reported approximately 79% lower average spending and improved within-budget completion across 27 scored trials; those results apply to the published benchmark, not every production deployment.

Chawla’s engineering priorities place deterministic safeguards around probabilistic models: execution traces, tool-level assertions, spending policies, and circuit breakers govern consequential actions, while subjective response quality requires separate behavioral evaluation.

Read the topics behind these talks

2 conference talks

Key ideas

Scroll to read ↓

A successful API call can still execute the wrong trade. Recording agent boundaries turns an otherwise elusive failure into a repeatable test of the code that must stop it.

  • The production failure that disappears locally
    0:00 ↗
  • Temperature zero does not freeze the serving system
    2:26 ↗
  • Recover the run instead of regenerating it
    4:51 ↗
  • Record semantic boundaries
    6:14 ↗
  • Find where dollars became shares
    8:05 ↗
  • Replay the bad decision against the repaired tool
    9:56 ↗
  • Test enforcement and behavior separately
    12:08 ↗
  • Keep the execution envelope as a test case
    13:14 ↗

Key ideas

Scroll to read ↓

Tisha Chawla and Susheem Koul explain how TokenOps attributes spending to agent runs, applies shared budgets, and changes execution before a hard cap has to stop the work.

  • Attribute model consumption to agent runs and usage dimensions so policies can act on the workflow responsible for spending.
    4:17 ↗
  • TokenOps uses a boundary annotation for observations and action delivery, while a governor applies only developer-allowed changes.
    11:55 ↗
  • Preview mode evaluates policies without enforcing them, allowing thresholds and guardrails to be adjusted before they change live execution.
    16:24 ↗
  • A hard cap stops work; the cost guard uses consumed budget and consumption velocity to request shorter future outputs before predicted exhaustion.
    17:24 ↗
  • The companion article reports 78.9% lower mean cost per completed run and within-cap success rising from 18/27 to 26/27 versus no governance. The recording instead names throttling as the completion baseline, so the comparison remains unresolved.
    18:24 ↗
  • The proposed learning module would use ledger records to discover missed failure modes, generate policies, and refine existing parameters.
    19:55 ↗

References