Sushil Chhetri
I build durable systems
for agentic software.
Most agent frameworks treat a workflow as a request that returns once. I am interested in the harder case — the process that runs for hours or months, pauses for a human, survives a redeploy, and has to be explainable afterwards. That means durability, deterministic replay and honest failure semantics, not prompt plumbing.
Current work
Loom — an execution kernel for agentic applications
Loom treats an agentic workflow as a process that unfolds over time.
Every step and decision is recorded as an immutable fact in an append-only log, so state
is fold(events) rather than a mutable blob you hope stayed in sync. From
that one property everything else follows: an execution can be paused for a human,
resumed on another machine, replayed bit-for-bit to debug it, forked to explore
alternatives, and evaluated against its own history.
Flows are ordinary async TypeScript — no DSL, no YAML, no state machines.
The kernel stays small and deliberately boring; capability lives in packages and plugins
behind versioned SPIs with conformance kits, so a third-party backend wires up exactly
like a first-party one.
- Durability as the default, not a feature. The log is the source of truth. Replay re-folds it to identical state, and completed steps are served from the log so effects never run twice.
-
Human-in-the-loop as one line.
ctx.suspend()writes a durable checkpoint and hands control back. The process can restart or move machines; when the approval arrives it resumes from exactly that point. - Decisions written down. Every trade-off is an ADR — including the ones that record a decision not to build something, with the evidence that was missing.
- Guarantees that check themselves. Fitness functions in CI assert the ABI can't drift, stored logs stay foldable, and a capability's maturity badge can't claim evidence it lacks.
Read the Loom docs Loom on GitHub
Loom and loom-ui are open source under Apache-2.0. The packages aren't on npm yet, so for now you build them from source.
Also public
Selected repositories
loom
The execution kernel itself — an event-sourced, replayable runtime for agentic workflows, with its packages, plugins, ADRs and specification.
TypeScriptloom-ui
A semantic UI framework on Loom: describe an experience as nodes bound to data by handle, and it compiles per surface to a Loom Blueprint.
TypeScript · Litloom-site
The Loom documentation site — Astro, static, generated from the framework's own docs so it tracks the code rather than describing it from memory.
Astro · TypeScriptloom-demo
Schema Migration Guard — a cloud-DB agentic demo on Loom. Inspect a table, rate the migration risk with an LLM, pause for a human DBA, then apply. One flow, two surfaces.
TypeScript · Reactdotfiles
Editor and shell configuration, kept in the open and in use daily.
Vim · ShellEverything else
Thirty-odd public repositories going back to 2012 — Rust and Python experiments, Svelte and JavaScript projects, and a lot of learning in the open.
github.com/chhetrisushilAbout
Nineteen years, mostly on the parts that have to keep working
I am an engineering manager at Google, based in Bengaluru. I studied information technology at the University of Mumbai, and I have spent about nineteen years building software — long enough to have watched several confident architectures meet production and lose.
The through-line in what I enjoy is systems whose correctness you can actually argue about: explicit contracts, recorded decisions, failure modes that are loud instead of silent. Loom is the current expression of that. Managing a team has not changed the interest so much as sharpened it — most of what makes software survivable is decided before anyone writes the clever part.
I speak English, Hindi and Nepali.
Contact
Say hello
I am always glad to talk about durable execution, agentic systems that have to survive production, or the unglamorous parts of engineering leadership. If you are building something in that space — or think Loom might fit a problem you have — get in touch.
Based in Bengaluru (IST, UTC+5:30) — replies are usually within a day or two.