I build the infrastructure that agent systems run on — orchestration, retrieval, evaluation,
and the cost and latency controls that decide whether a system survives contact with production.
Nine years of production engineering, the last several on LLM and agent platforms.
Venture teams sat through roughly 120 calls a week — about 100 hours. The knowledge in them
was real and it evaporated. I architected the platform that turned that stream into structured,
queryable business intelligence for several teams at once.
Recordings land in a nine-worker pipeline spread across seven queues, each with its own
dead-letter queue and bounded retries: transcription, speaker identification, summary, learning
extraction, collage, reflection. A shared concurrent message-pool library is the reliability
backbone underneath all nine.
The decision I'd defend hardest is the promotion ladder. Extracted learnings climb four
stages — candidate, emerging, validated, decision-grade — and never demote.
Monotonicity means a signal's stage is a fact about evidence accumulated, not a value that can
flap between runs, so 31 prerequisite-chained artifact types can be evaluated in two database
queries instead of recursive traversal.
Retrieval runs over 3,072-dimension embeddings in pgvector across transcript segments,
summaries, and reflection insights. On top sits a chat assistant with a 24-tool
function-calling registry — thinking-token streaming, parallel tool dispatch over SSE — plus an
MCP server that exposes the whole intelligence layer to external agents.
Tenants are isolated by PostgreSQL row-level security in a single deployment rather than one
deployment per customer, with all infrastructure as code at full dev/prod parity. Compute cost
fell about 94% when I moved off per-task serverless containers to three EC2 capacity providers
tuned per workload shape, autoscaled on queue backlog per task rather than CPU.
100 hrs/week ingested
9 workers
7 queues + 7 DLQs
3,072-dim pgvector
24 tools
~94% cost cut
Ingestion → queue fan-out → worker pipeline → vector store → two query surfaces.
Case study 02
Multi-agent NLP pipeline on a decentralized data platform
Senior Software Engineer · 2025
The problem was a firehose of chat events that needed to become a queryable social graph —
users, messages, topics, inferred relationships — without ten agents corrupting shared state on
the way in.
A meta-orchestrator fans each batch out to seven model-backed agents in parallel: sentiment,
embedding, toxicity, spam, emoji, topic, relationship. Each makes exactly one model call and
returns a result. None of them touches the graph. Three coordination agents handle the rest, and
a single writer merges every result in. Autonomy in the reads, serialization in the writes — no
locks, no partial merges, no ordering bugs at 3am, and adding an eighth agent doesn't multiply
the interleavings anyone has to reason about.
The second decision that paid for itself was content-hash idempotency at the storage layer.
Every write is keyed by a hash of its source content, so re-running the pipeline over the same
input produces byte-identical output. That made Postgres disposable: wipe it entirely, rebuild
from source events, get the same graph. Debugging stopped being archaeology. The discipline it
demands is keeping anything non-deterministic — timestamps, temperature, retry counts — out of
the hash.
Semantic retrieval runs on 384-dimension embeddings in pgvector with dynamic topic clustering at
a 70% similarity threshold, over a 27-table schema. Five query operations are exposed as MCP
tools through the platform gateway, so external LLMs can query the graph directly. Pipelines
themselves are declared as infrastructure-as-code over custom resource types — a new pipeline
ships as a stack file and deploys without recompiling any backend service.
10 agents
7 parallel · 1 writer
fully replayable
384-dim pgvector
27 tables
5 MCP tools
Fan out the reads, serialize the writes. Content-hash idempotency makes the whole path replayable.
Case study 03
Embedded AI companion platform
Founder & Principal Engineer · 2025–present
A companion device has two hard requirements that pull against each other: it has to remember
you across months, and it has to answer fast enough to feel like conversation rather than a
query. I built the platform end to end — custom ESP32-S3 hardware, the memory system, and a
multi-tenant cloud backend licensed to third-party brands as a white-label “brain.”
Memory is four layers across Redis, PostgreSQL, and a graph store: short-term context, episodic
facts, emotional state, and a long-term relationship graph. The unusual choice is that every new
session reprocesses the full history of prior sessions rather than reading a fixed retention
window. There is no retention ceiling, so recall stays consistent at month nine the way it was
at week one — the failure mode I was designing against is a companion that quietly forgets you
as the window slides. A separate subsystem of background agents reads conversation metadata and
evolves the character configuration over time.
The voice path is streaming end to end — streaming speech-to-text into the model into custom
text-to-speech — holding under 500ms for real-time dialogue. Per-device memory separation across
licensed brands is enforced with PostgreSQL row-level security, so one brand's devices can never
reach another's. Hardware went from concept to first functional module in under four weeks.
sub-500ms voice loop
4 memory layers
no retention ceiling
ESP32-S3
RLS per device
concept → module in 4 weeks
Streaming voice loop under 500ms, with four memory layers rebuilt into every session.