Get in touch
DAVID HUSTLER · HSTLRLABS

I build agentic systems, end to end.

Every single day since early 2025. Voice interfaces, agent memory, multi-agent coordination, developer infrastructure, iOS apps, servers, the lot.

I direct, route, and manage the coding agents that write the code. Most of the work is the structure around them: the harnesses, the memory, and the guardrails. Here's what came out of it.

  • Since Jan 2025
  • Solo, architecture through deploy
  • TypeScript · Swift · Python · Go
  • Ontario, Canada
THE WORK

Working systems and prototypes built in my own lab on client-provided placeholder data, or publicly available source materials.

A voice surface: a water droplet resting on brushed metal under a single overhead light, with the greeting Good evening above it. Touching the droplet starts talking.
Voice first. Opens a direct peer-to-peer channel straight to a terminal on an Apple Silicon Mac.

Klystron An iOS app opening a direct voice channel to an Apple Silicon Mac.

A voice-first iOS app that operates hands-free on an iPhone. It opens a direct peer-to-peer channel over a private tunnel straight into a terminal on an Apple Silicon Mac at home, with no intermediary cloud in the path. From there, a coordinating agent routes tasks across slotted local agents, open-source models running on device via MLX, or frontier models using monthly subscriptions or API keys. It answers back out loud while streaming live telemetry at twenty updates a second.

The hard part. The seam. Speech has to start before the model has finished thinking, so the first sentence synthesizes while the rest is still generating. And the transport has to survive a car, hotel Wi-Fi, and 5G handoffs without dropping the audio session, which is why it is a private tunnel first and a relay second.

Stack
iOS (Swift 6) · Apple Silicon Mac · MLX · WireGuard · Node · TypeScript · Go · Metal
Numbers
583 real voice turns over 23 days · 390 tests passing headlessly · 11 custom Metal shaders
Status
In development, unreleased · sole author · 2025 to now
The Arbour local graph viewer showing a memory grove with botanical packet nodes, organic vines, and typed relationships rendered in real time without embeddings.
The local memory grove viewer. Renders packet structures, vines, and history directly from flat files.

Arbour Memory for agents, with no embeddings anywhere in it.

Everybody reaches straight for a vector database. This one is flat packets on the filesystem: a directory per thing, a file for what is true now, a file for what you want it to be, and append-only logs of what changed and who changed it. You can sit and read the whole thing with your own eyes, or open the optional local graph viewer to inspect the whole grove without touching a cloud.

The hard part. Building a structured memory system that agents can reliably read, navigate, and update on their own without breaking. It organizes context into clean units of work, so an agent gets exactly what is relevant to the active task without starting cold every time.

Stack
TypeScript · Python · in-engine BM25 · JSONL · zero runtime dependencies
Numbers
425 tests passing · 10 packages · 0 embeddings
Status
Runs daily, unreleased · sole author · 2025 to now
A front desk console showing a queue of calls needing a decision, one open job with the vehicle, reported symptom and requested time, and owner approval buttons for approve, callback, hold, or take over.
The owner's console. Nothing leaves it without somebody pressing one of those four buttons.

Vinny A front desk that never misses the call.

It answers, asks what they're driving, what it's doing, how urgently they need it and when they can come in, then texts the owner for a yes, a callback, a hold, or a full takeover. Pricing and diagnosis stay with the owner. Every booking, promise and commitment waits for a human to say yes, and every decision is written down.

The hard part. Multi-tenant from the first line, because one shop is a demo and forty is a business. Customers get in on a single hashed expiring token tied to their own job, so there's no login to manage and nothing to leak between shops.

Stack
Node · Postgres · Twilio voice and SMS · ElevenLabs · Cloudflare
Numbers
448 tests · 42 modules · 3 runtime dependencies, no web framework
Status
Live at vinny.work, taking waitlist calls. No shops in production yet.
A feasibility readout headed Principal decision required, listing the main concerns, the immediate actions, and a trust boundary stating the record is useful for principal review and not for pursuit or permit authorization, over 86 live and reachable sources.
Every reading carries its source and a line saying who still has to sign it.

Northline Architecture project intake and site viability.

Built to run on an architecture firm's local hardware using a local agent, so private client and pursuit data never touch a cloud. Give it an address and a brief. It pulls live municipal GIS parcel data, parses zoning by-laws and heritage schedules, and delivers a cited project record: what is blocked, what is confirmed, and what open risks need licensed professional sign-off. Certification stays with the professionals who carry it.

The hard part. Municipal endpoints go down, change shape and disagree with each other. So the record reports what it could reach and what it couldn't, and a source it failed to open shows up as a gap rather than quietly disappearing.

Stack
TypeScript · Node · Local LLM · live municipal GIS endpoints · deterministic rule engine
Numbers
86 live and reachable sources · 100% local data boundary · every reading marked for licensed review
Status
Working prototype on real Hamilton sources · sole author · 2026
A live Cathode Rodeo gameplay table showing player cards, custom vacuum-tube card art, staged matching-rank play, and bot opponents.
Live multiplayer table. Custom vacuum-tube card art, real-time WebSocket state, and learned PyTorch bots. Play live table

Cathode Rodeo A multiplayer card game with an unusual name.

The name is weird and a bit funny, but it shares the same vacuum-tube lineage as Klystron, blended with my Alberta roots. I built it for fun so my family could play Swoop together from anywhere. It is a live multiplayer card game with custom card art, isolated private tables, and offline-trained PyTorch policy bots compiled to run directly in edge isolates. Originally built just for us, but it turned into a fast, reliable system you can play live on this site right now.

The hard part. State synchronization without lag. Every table runs in its own isolated Durable Object keeping player hands secret, enforcing game rules, and synchronizing moves over WebSockets so you can play smoothly from any phone or computer.

Stack
Cloudflare Workers · Durable Objects · TypeScript · WebSockets · PyTorch
Numbers
2 to 8 players · offline-trained policy bots · 0 web framework
Status
Live and playable right now at play.hstlrlabs.xyz · sole author · 2026
THE PART THAT'S ACTUALLY HARD

Anyone can generate code now. Deciding what the machine is allowed to do is the job.

There's a lot of noise about how easy this got. Type the right prompt, ship a product, make ten grand a month. It's still alarmingly hard to build anything complex, and harder again to bolt it onto workflows that were built for people rather than agents. You can't build a house with just drywall. You need all the parts.

The decision that matters comes before any of it. What's this thing allowed to do on its own, what has to wait for a person, and what happens when it's confidently wrong at four in the morning.

HOW I THINK ABOUT IT

A few things I've picked up doing this every day for the last eighteen months.

  1. 01
    Memory is the hard problem, not context length. Everybody reaches straight for a vector database. I built mine without embeddings. Flat packets, links between them, and lexical recall scoped to whatever you're actually working on. You can sit and read it, which matters more than people think, and it doesn't quietly hand you the wrong thing because two sentences happened to land near each other in vector space.
  2. 02
    Nothing should outlive its purpose. Agent systems make mess faster than people do. Stray processes, working trees, scratch files, half-finished branches. So everything I run has a rule attached and something that actually sweeps: no process outlives its purpose, no working tree outlives its work order, no scratch outlives its owner.
  3. 03
    No automation without an observer. If I schedule something, there's a second thing whose only job is to prove it actually did what it was supposed to. Exit code zero isn't evidence. Most automation rots quietly and nobody finds out for months.
  4. 04
    Directing agents is a management job. They're like juniors right out of school, and alarmingly smart with it. They need a lane, the context, and a standard for done. Most of the job is dividing the work up properly, catching drift early, and making the calls they'll cheerfully get wrong on their own.
  5. 05
    You can't bolt an agent onto a workflow built for people. You build it in parallel, on placeholder data, prove it out, then move it across a bit at a time. And you put a gate in front of anything with consequences. If you're booking a trip you don't want your agent holding your credit card and your inbox and just going ahead on its own.
GET IN TOUCH

I like talking about this stuff.

Three sentences is plenty to start. Any of these are a good reason to write.

  • HIRING

    You're putting together a team that does this sort of thing and you want to know whether I'd fit it.

  • BUILDING SOMETHING

    You've got a problem you reckon might be shaped like one of the ones above.

  • JUST WANT TO TALK

    A podcast, a panel, or a room full of people trying to work out where AI actually belongs in their operation. I usually say yes.