Voice systems
Real-time conversational AI
Work on the timing and dynamics of spoken interaction: when a system should speak, listen, backchannel, or hold back so it feels responsive rather than reactive.
ABOUT
About
John Brown works on real-time conversational AI for voice systems: turn-taking, backchannel behavior, and affect-aware decisions under hard on-device timing constraints.
PRACTICE DOSSIER
Who John is
John works on the timing and dynamics of spoken interaction: not only what was said, but when a system should respond, listen, backchannel, or stay out of the way.
The work spans the full path from PyTorch/MLX research to Swift/CoreML on-device deployment, with full-stack and polyglot tooling around it in Python, Swift, TypeScript, and Bash.
A long background in music production, synthesis, and signal processing shapes how he thinks about timing, texture, and dynamics. The photography and cinematography, guitar and synthesis threads stay here as supporting context for that same constraint-driven practice.
- JB// VOICE TIMING
- JB// PYTORCH / MLX
- JB// SWIFT / COREML
- JB// AGENT TOOLS
- JB// TIMING / DSP
CAPABILITY MAP
What the work spans
The through-line is real-time constraint: research, software, agent infrastructure, and technical direction all have to survive contact with production.
Deployment path
On-device research to runtime
Research prototypes in PyTorch/MLX have to survive export, Swift/CoreML deployment, streaming state, causal models, fixed hop budgets, and real-time audio loops.
Full-stack systems
Full-stack and polyglot tooling
Python, Swift, TypeScript, and Bash show up around the core work: research harnesses, local runtimes, frontends, protocol surfaces, and operational tooling.
Agent tools
AI-agent tooling and orchestration
Protocol servers, model-provider abstractions, agent gateways, lifecycle tooling, and wave-structured delivery with clear ownership boundaries.
Technical direction
Programs that can be operated
ADRs, staged releases, acceptance gates, interface contracts, and roadmaps keep ambiguous research work legible enough to ship and maintain.
PUBLIC RECORD
Why the other media are here
Music, photography, and art stay on the site because they show the same concern with timing, texture, tools, and constraints from another angle.
Images
Photography and cinematography
Camera work, surface studies, and visual systems track how light, texture, framing, and repetition become a record rather than a feed.
Sound
Guitar and synthesis
Music practice connects rhythm, synthesis, guitar, hardware routing, and SoundCloud sketches to the same timing instincts used in voice systems.
Notes
Notes as working memory
Technical notes, process records, and public entries make the work easier to inspect, critique, revisit, and hand to another person.
STACK
Publishing system
A lightweight static stack keeps the site inspectable, versioned, and easy to deploy.
- Astro static publishing
- GitHub Actions deployment
- SiteGround SSH sync
- Structured content collections
- Design tokens and reusable cards
- llms.txt and public docs
Operating rule
Public pages should be specific enough that a stranger can tell what is finished, what is a note, and what constraints shaped it.