Shaurya Singh

Engineer — agent systems, guardrails, corrections published in place.



Work

Four things worth showing. Each one carries an honest status, because a status that isn’t measured is just decoration.

Case notes

The correspondent layer Demo

An AI voice and email agent that runs first-contact recruiting conversations end-to-end — it calls, it listens, it replies, it hands off. I’m an intern; this lane is mine end-to-end, from the transport up through the guardrails.

The best thing I built here was the thing that broke it. The static eval bank was green and stayed green — but it only ever asks one question: did this string route to the right tool, once? So I built a persistent, adversarial, multi-turn battery to ask the questions a fixed bank structurally can’t. It found real defects the eval could not see.

The worst of them sat in the safety path — the layer that is supposed to be the least surprising thing in the system, and therefore the layer nobody re-reads. Then the fix I wrote for it introduced a regression of its own, which the state-machine tests caught, which is precisely why they exist.

The second lesson was harsher. A green eval bank can coexist with a completely broken production path, because the harness feeds inputs the live wire never delivers. Harness truth is not wire truth. I now gate on regression against real captured traffic, not synthetic cases.

Compliance is not a footnote here, and the dates matter as much as the statutes. In force today: NYC Local Law 144 (bias audit and notice, since 2023), Illinois HB 3773 (amending the Human Rights Act from January 2026 — the one with real teeth, not the older video-interview act), the EU AI Act’s prohibition on workplace emotion recognition (applicable since February 2025, and the most on-point rule for a voice product), and all-party recording consent plus California’s artificial-voice disclosure. Knowing which of those binds you today shapes the product, not just the disclaimer. Statute list last reviewed 2026-07-19; I am an engineer, not your lawyer.

Honest scope: this runs against a deterministically seeded synthetic test world. No real candidate data, no production traffic, no users. It is a working system and a demo, and those are different things.

A private voice agent Unverified

A personal assistant that answers a real phone number. Twilio Media Streams → Deepgram for speech → Claude for reasoning → ElevenLabs for voice, on a 2013 Mac Pro with 12GB of RAM sitting under my desk. It holds a conversation and it can be interrupted mid-sentence, which is the part that’s actually hard.

Most of what I learned here came from breaking it. A single missing config section took down the entire stack — because one module read credentials at import time, and three other modules imported it. The watchdog then relaunched the corpse every ten seconds. The fix wasn’t a patch; it was a floor: no subsystem is allowed to take the phone line with it.

Corrected 2026-07-19

Then the audio broke up on a live call, and I read it wrong first. My guess was pacing — 40ms of audio sent every 20ms, twice real-time — so I matched the sleep to the chunk size, and it didn’t hold. The delay lived one layer down: with TCP_NODELAY unset, the socket did exactly what Nagle’s algorithm is built to do — hold each small audio write back to coalesce it with the next — and that stall reads on the wire as the same choppy lag a pacing bug produces, which is why I misdiagnosed it. The fix is one socket option, not the sleep loop. The pacing change was reverted.

I only got to see that because I first fixed why the bug was invisible — and that is a separate claim from the one above, not a competing explanation. The process ran without -u, stdout was block-buffered, and the evidence sat in a buffer nobody flushed. Once the log flushed, it showed the delay was below the application, not in it. An algorithm doing precisely its job in the wrong place looks identical to a bug — only an instrument pointed at the right layer tells them apart.

Why this reads Unverified and not Live: it answers the phone, and I have no dependency health check with a date I can stand behind. A status without a date is a status I’m asking you to take on faith, and the stamp component on this site refuses to render green without one. When I re-measure, it changes. Interrupt telemetry is instrumented and reads UNKNOWN until its next live call — I’m not going to colour it green because it would look better.

CiteGuard Prototype v0.3

A separate venture, standalone. An API-first verification rail for legal citations: it checks that a cited authority exists and that a quoted passage is real, then issues a hash-bound certificate. Deliberately positioned underneath the market rather than inside it — not a tool firms buy, the rail everyone else runs on.

The thesis rests on two verified facts and one bet. Grounded legal AI still hallucinates — Lexis+ AI at roughly 17% and Westlaw’s AI-Assisted Research at roughly 33%, per Magesh et al., Journal of Empirical Legal Studies 22:216 (2025), on tools as tested in 2024. And Florida Rule of General Practice and Judicial Administration 2.515(d)(2), effective 15 June 2026, requires every filer — including pro se — to certify that cited authorities exist and are accurately cited. That second clause matters: it covers misquotation, not just fabrication, which is the harder half.

The bet is about shape, not vacancy. A market already exists — Clearbrief, BriefCatch, Counsel Stack and others ship verification, some with APIs. I am not claiming an empty field. The wager is that verification belongs underneath as neutral infrastructure with a hash-bound certificate, rather than inside any one vendor’s product, and that a filer certifying to a court needs something they did not buy from the tool that generated the brief.

Honest status: Flask, eyecite-based extraction, a REST verify endpoint, key auth, stateless. Four-layer engine. It is a working prototype, not a product, and there are no users.

Comprehension tooling Concept — nothing built

A concept with real research behind it and zero lines of code. The idea: ingest any content and restructure it into the format a specific brain can process and finish. The north star is comprehension and task completion — explicitly not engagement.

The interesting part is what I ruled out. Optimising for stimulation would make the thing feel wonderful and accomplish nothing. Refusing that is the product’s spine. I also found that Bionic Reading is largely superficial — weak evidence, and a useful negative result.

Listed here because it’s honest work, not because it’s shipped. It isn’t.

How I decide what to build

The most expensive mistakes I have made were not bugs. They were correct implementations of the wrong thing. So the front of the process gets more weight than the middle.

  1. S/1
    Find the real problem.

    The biggest risk in building anything is building the wrong thing well. Before writing code I want to know what breaks if this doesn’t exist — and if the answer is “nothing,” that’s the finding.

  2. S/2
    Understand it with evidence, not intuition.

    Pull the real traffic. Read the actual logs. My instinct about why a system misbehaves has been wrong often enough that I now treat it as a hypothesis with a test attached, not a diagnosis.

  3. S/3
    Build the smallest thing that can be proven.

    Ship it behind a gate, off by default, with a way to watch it and a way to turn it off. If I can’t describe how it fails, I don’t understand it well enough to deploy it.

  4. S/4
    Write down what it taught me — including when I was wrong.

    A correction that stays in someone’s head gets made again in six weeks. Mine go on the record next to the thing they correct, which is uncomfortable and has saved me more time than any tool.

What I actually know