
3
2
Viet Nam
2+ years of experience
I build AI agent systems end to end: Python, FastAPI, Docker, and whatever runtime the job needs. Currently building an agent that runs untrusted code in a throwaway container and measures what escapes. I join hackathons to learn fast and ship real demos. Open to joining a team to learn more.

We did not build a wallet app. We built the thing that builds one, and pointed it at a wallet. Three coding-agent seats share one BAND room. One decomposes a stage of the written specification and routes it, one implements to that specification, runs the checks and commits, and one reviews that exact revision and replies ACCEPT or REJECT. The reviewer never edits service code, so it cannot make a failing check pass by changing the thing being checked, and it writes its own adversarial scenarios in a folder the implementer is forbidden to read. The band reached stage 4. Each stage-N/ folder is a complete service that builds from a clean container, answers /health with no outbound network, and still passes every earlier stage's suite: 147 checks at stage 1, +35 at stage 2, +6 at stage 3, +5 at stage 4, plus the reviewer's own scenarios. The event's own harness scored every folder share 1.0, highest contiguous stage 4. Once a stage was dispatched no human touched it again. That is a property of the room, not of this paragraph: all 121 messages in room.json carry an agent sender and not one is from a human. The reviewer found six defects the published checks never named, and every fix came back through the room as its own commit. What we will not claim: the reviewer never actually vetoed anything. Every verdict in the room is an ACCEPT, six carrying findings. The veto the factory is built around is untested in this run, and FACTORY.md says so rather than leaving it for a judge to find. The factory is three mandates, three adapters and one room. The mandates name no endpoint, no field and no error code, so they could be pointed at a different specification tomorrow. verify_claims.py checks all 36 figures in the documents against room.json, the git history and the committed harness report, and CI fails the build when one disagrees.
6 Oct 2026

Elderly patients often depend on family to book clinic visits through apps with tiny text. One confusing screen and they give up — or travel to the clinic just to ask. VoiceCare Scheduler lets them speak instead, on the AssemblyAI Voice Agent API (agents.assemblyai.com: short-lived token minted server-side, live browser voice WS, English inline session with keyterms + barge-in turn-taking, vendor TTS voice, 2 tools check_availability/book called as tool.call->tool.result): say the need, the agent transcribes, extracts day/time entities, asks for confirmation aloud, then books only after the patient says YES (strict, transcript-proof). STT batch/WS fallback (Universal-3-5-pro, en, diarization) keeps the demo runnable. If the user interrupts mid-flow, the agent stops, listens, and continues with the better-understood sentence. If confidence is low, it never guesses — it escalates to a human hotline. Every run prints per-stage latency (reproducible locally). Measured live: WS handshake ~1.0s, PARTIAL ~1.2s, FINAL ~3.9s (Speaker A, `sample_en.wav`); batch ~8.5s with entities. Accessibility-first: slow clear TTS, large-text cards and autoplay replay serve elderly users, while barge-in turn-taking and never-guess escalation keep patients with unclear pronunciation safe instead of misbooked. Users: clinics serving elderly patients who don't use apps. Market: ~12M over-60 VN (UNFPA 2023) + ~5k private clinics (MOH est.); SAM 500 x $39/mo = $234k ARR yr1. Revenue: per-clinic SaaS $39/$99 per month, cheaper than a $250 phone receptionist. Track: Main Voice Agent (full operating loop: token + live WS + TTS + 2 tools + barge-in + YES-gated consent + escalation + measured latency; doubles as Accessibility entry for elderly/low-clarity speech). Live demo + video with EN overlays showing the full loop.
30 Sep 2026