Platform Capabilities
The six case studies cover the systems I would talk through in an interview. This is the fuller inventory — what exists across the codebases, what it does, and whether it is actually running.
Each entry carries a runtime state. Several are complete designs that are not wired up, and a few are experiments. Labeling them is more useful than a page that implies everything ships: it distinguishes what was built from what was specified, and it is the same distinction I would want from someone else's portfolio.
54 capabilities, by runtime state
- Runtime state: Running in production39
- Runtime state: Partially wired4
- Runtime state: Declared, not wired2
- Runtime state: Built, dormant3
- Runtime state: Experimental6
Declared, not wired means the design is complete and version-controlled but nothing executes it yet. Built, dormant means it works and is not currently in use. Neither is padding — both are real engineering, and pretending they were live would be the wrong trade.
12 capabilities
Sending and deliverability
The revenue path, and everything that protects it.
- Runtime state: Running in productiongiMTA
Lane and engine delivery model
Sending identity and throughput capacity are separate concepts. A lane is one outbound address, one sending domain, one signing key; engines are parallel workers operating for a lane. Keeping them independent is what lets capacity scale without ever compromising sending identity.
- Runtime state: Running in productiongiMTA
Crash-safe delivery recovery
An immutable injection-time index plus an append-only outcome log. A restart replays the log and rebuilds scheduler state, so terminal messages are excluded mechanically rather than by an operator's judgment.
- Runtime state: Running in productionMailerClub
Delivery protection engine
Fourteen rules in four priority bands, evaluated on a fixed tick against live delivery signal. Eleven action types covering provider, campaign and offer control, behind a kill switch and an advisory-or-enforcing mode gate.
- Runtime state: Running in productionMailerClub
Adaptive deliverability and warm-up control
A closed control loop: normalize raw delivery signals, score reputation per entity, decide, then apply warm-up or throttle changes. Includes an automated recovery path and a reactive mode.
- Runtime state: Running in productiongiMTA
Closed-loop throughput tuning
Smoothed per-destination outcome tracking drives a recommended concurrency, clamped by configured ceilings. Statistics rather than inference — it cannot hallucinate a rate.
- Runtime state: Running in productiongiMTA
Bounce classification with hot-reloadable rules
Enhanced status code classification driven by rule files that reload without a restart, with per-lane bounce policy and signaling feeding the reputation loop.
- Runtime state: Running in productionMailerClub
Feedback loop and complaint attribution
Polls provider feedback mailboxes, parses complaint reports, and decodes the encoded return path to attribute a complaint back to the specific send that caused it, then suppresses.
- Runtime state: Running in productionMailerClub
Inbox-placement measurement
A fleet of seed mailboxes polled across several provider APIs to measure where mail actually lands, detect the receiving provider, and correlate placement back to a send. Described at this level deliberately — the mechanics are legitimate deliverability testing but read poorly out of context.
- Runtime state: Running in productionMailerClub
Blocklist reputation policy
Reports which recipient domains reject blocklisted sending addresses, and why. Notably it reports and never blocks a send — the boundary is printed on the page itself.
- Runtime state: Running in productiongiMTA
Deterministic ISP throttle harness
A test SMTP server with round-trip-time and slow-server modes, plus a provider behavior simulator. Together they make provider throttling reproducible on demand instead of something you wait to observe in production.
- Runtime state: ExperimentalgiMTA
Concurrency verification under a model checker
Concurrency models runnable under a permutation checker, kept deliberately outside the main build so the check is opt-in. The workspace also forbids unsafe code entirely, with no exceptions.
- Runtime state: Running in productiongiMTA
Server-side personalization and rendering
Template compilation and rendering with a macro registry, message assembly, escaping, segmentation and validation — the personalization engine that runs before a message is spooled.
9 capabilities
Data, discovery and enrichment
Finding contacts, verifying them, and knowing something about them — without any of it touching the send path.
- Runtime state: Running in productionMailerClub
Lead discovery, decoupled from sending
Finds publicly published business contacts through reproducible seeded searches. Its defining property is what it cannot do: there is no code path from a discovery result into the sending pipeline, so an operator must review and explicitly create a list.
- Runtime state: Running in productionSupporting
Self-hosted scraping service
A drop-in replacement for a paid scraping API, implementing the same request and response shapes so callers did not change. Queues fetch jobs, renders through a headless browser, stores results, and returns them in the original format.
- Runtime state: Running in productionMailerClub
Layered email verification
Syntax, then mail exchange, then an SMTP handshake, then catch-all detection, then disposable-provider and role-address detection. One concern per stage, so a failure tells you which layer rejected it.
- Runtime state: Running in productionMailerClub
Contact enrichment pipeline
Background-only enrichment with a circuit breaker per upstream, response and domain caches, connection prewarming and a quality scorer. Architecturally barred from blocking a send, and every consumer must tolerate a missing record.
- Runtime state: Running in productionSupporting
Domain trap and parked-domain scoring
A standalone scoring service consumed by the enrichment pipeline, separating trap detection and parked-domain detection from the enrichment stages that use them.
- Runtime state: Built, dormantMailerClub
Ad-network attribution and creative teardown
Crawls advertising creatives and attributes each to the network that served it using roughly seventeen independent detectors, with perceptual hashing for deduplication and optical character recognition on creative images. A model layer then produces angle analysis and draft copy. The detector heuristics are deliberately not described.
- Runtime state: Built, dormantMailerClub
Offer intelligence
Ingests offer and network data, scores it, computes trends over time buckets, rotates offers, and auto-pauses on cap exhaustion or performance decay. Scoring inputs and outputs are described; the formulas are not.
- Runtime state: Running in productionMailerClub
Click and open tracking with bot filtering
Runs as a separate process exposing only tracking endpoints — no authentication surface, no dashboard, no administrative API. Adds bot detection, device fingerprinting, per-link risk scoring and rule-based routing. The exposure boundary is a process boundary, not a proxy rule.
- Runtime state: Running in productionMailerClub
Analytical event store
A column-oriented store alongside the transactional database for engagement and delivery analytics, with its own migration path.
12 capabilities
AI and agent governance
The part I would most want to be asked about: what an agent is allowed to do, and how that is enforced when things fail.
- Runtime state: Running in productionMailerClub
Fail-closed capability registry
Every agent action names a capability that must exist in a registry. If the lookup cannot complete — a database fault, a network problem — the action is denied. An outage cannot become an authorization bypass.
- Runtime state: Partially wiredMailerClub
Seven-check job governance gate
Kill switch, phase compatibility, allowlist, concurrency, hourly rate, then verification and canary for autonomous changes only. One entry point, ordered cheapest-first, every check audited with a machine-readable reason.
- Runtime state: Partially wiredMailerClub
Staged autonomy with canary rollout
Autonomy is ordered — observe, then assist, then autofix — and a capability advances through a canary window with automatic rollback on regression. Scoped policy resolves narrowest-first, so one capability can be trusted without loosening the fleet.
- Runtime state: Running in productionMailerClub
Per-job budgets
Token, tool-call and runtime ceilings on every agent job, paired with rate limiting — because a bounded job rescheduled immediately is an unbounded job in installments.
- Runtime state: Declared, not wiredMailerClub
Declarative agent workflow catalog
Thirty-eight workflows declared as capability graphs with ordered and parallel steps, named tools, an autonomy mode and required evidence. Reviewable in a pull request rather than buried in a prompt string.
- Runtime state: Declared, not wiredMailerClub
Decision explainer
An agent decision can be stored with its reasoning tree, the signals it used, a confidence breakdown, an input snapshot and the alternatives it considered — and two decisions can be compared signal by signal. Auditable AI decision-making rather than logging.
- Runtime state: Running in productionMailerClub
Confirm-before-execute assistant
An in-app assistant with twenty-six registered platform tools. When it wants to take an action it writes a pending row and stops; a human must confirm before it executes. Every run is auditable fleet-wide.
- Runtime state: ExperimentalMailerClub
Replay under modification
Snapshots a workflow trace, then replays it with overlays and tool substitutions in observe, assist or autofix modes. A genuinely useful primitive for verifying a change against a real past execution rather than a synthetic one.
- Runtime state: Running in productionMailerClub
Scraper egress compliance guard
Classifies a destination before a proxied request is allowed, and blocks scraper egress to financial, payment, checkout and login endpoints. Per-feature kill switches with a full audit log.
- Runtime state: Running in productionMailerClub
Encrypted multi-provider model credentials
Three allowlisted providers, keys stored encrypted with only a last-four fragment retained for identification, plus a live credential validation endpoint and an A/B performance view over the routing pool.
- Runtime state: ExperimentalMailerClub
Continuous experimentation platform
Generates candidate variants from both deterministic strategies and a model proposer, canaries them, evaluates live and promotes winners.
- Runtime state: ExperimentalMailerClub
Goal, planning and arbitration tiers
Mission planning with alignment scoring, executive resource allocation, and an arbitration layer that detects and resolves conflicts between competing agent decisions.
7 capabilities
Knowledge and retrieval
Grounding agents in what the system actually is, rather than what its directory names imply.
- Runtime state: Partially wiredKnowledge Engine
Hybrid retrieval with rank fusion
Vector similarity and keyword search merged by reciprocal rank fusion, with text-hash deduplication and a same-document diversity penalty. Hybrid because the questions agents actually ask are often exact-term questions where pure semantic search returns things merely about the right topic.
- Runtime state: Running in productionKnowledge Engine
Secret-scanning quarantine on ingest
Every document is scanned before indexing, and a document containing secrets is quarantined rather than chunked or embedded. The best safety detail in the whole retrieval stack, because it fails toward not-indexed.
- Runtime state: Running in productionKnowledge Engine
Token-budgeted context packing
Assembles a context pack to an explicit token budget rather than returning as much as it found, so retrieval cannot crowd out the task it was meant to support.
- Runtime state: Running in productionKnowledge Engine
Code intelligence extraction
Extracts services, endpoints, environment variables, database objects, streams and command-line entry points from the codebase into queryable knowledge, so structural questions are answered from code rather than prose.
- Runtime state: ExperimentalKnowledge Engine
Memory distillation
Distills accumulated runs and events into learnings, patterns and runbooks — turning operational history into retrievable guidance instead of an ever-growing log.
- Runtime state: Running in productionKnowledge Engine
Retrieval over a tool protocol
The same retrieval surface exposed as tools an assistant can call directly, so grounding is a tool call rather than a manual copy-paste step.
- Runtime state: ExperimentalMailerClub
Append-only learning graph
An idempotent graph of agent and system events with traversal and resolution, so causal chains across runs can be walked rather than inferred.
11 capabilities
Developer platform and safety
The unglamorous machinery that makes changing a live system survivable.
- Runtime state: Running in productionMailerClub
Staged feature-flag gating
Over a hundred flags, all defaulting to off, plus a three-stage gate across eight subsystems — shadow logs only, advisory warns, enforce blocks — defaulting to shadow. A behavior change and a deployment are never the same event.
- Runtime state: Running in productionMailerClub
Written invariants with evidence
The rules that must not break, each paired with a pointer to the code or document that proves it holds. The cheapest artifact I maintain and the one that has prevented the most expensive mistakes — it also onboards AI assistants on day one.
- Runtime state: Running in productionSupporting
Deterministic commit gates
Formatting, linting, type checking, secret scanning and content-schema validation on every commit, with no model call and no network access. Fast and identical every run, which is why they are not worked around.
- Runtime state: Running in productionSupporting
Task-class model routing
Four tiers including a no-model tier for anything a query answers exactly, with tracked spend per class and defined fallbacks. Availability problems degrade the tier, never the approval boundary.
- Runtime state: Running in productionMailerClub
Resilience primitives
Circuit breakers and retry policies for database and HTTP dependencies, applied consistently rather than reinvented per call site.
- Runtime state: Running in productionMailerClub
Message state machine with safe claiming
A closed transition graph — queued, leased, delivered, deferred, failed, suppressed — with skip-locked claiming so competing workers never process the same row twice.
- Runtime state: Running in productionMailerClub
Failure-mode catalog
A written record of how this system actually breaks, most of it silently, each entry paired with a positive liveness check. Monitoring asks whether a counter is still moving rather than whether an error appeared.
- Runtime state: Running in productionMailerClub
Registrar and DNS automation
A multi-registrar abstraction for programmatic domain acquisition and DNS setup, with domain intelligence refresh, DNS validation and a cache warmer.
- Runtime state: Running in productionMailerClub
Proxy node provisioning and guarding
Three layers: a pool, a guard enforcing per-proxy bandwidth and rate limits before a connection is permitted, and a node manager handling provisioning, certificates, key rotation and traffic alerting.
- Runtime state: Built, dormantMailerClub
Pre-send content QA
A rule-based analyser grading an email before it ships across six independent families — authentication, compliance, content, markup, links and macros — feeding a single score.
- Runtime state: Running in productionMailerClub
Content risk scoring
Scans campaign content and scores spam and compliance risk before send, with a caching layer and rule configuration held outside the code.
3 capabilities
Legacy and migration
Where this all started, and why the current architecture looks the way it does.
- Runtime state: Running in productionLegacy
The predecessor platform
A PHP monolith of roughly 173 standalone page scripts and 30 scheduled scripts, with no router, no autoloader, hand-rolled cryptography and no queuing layer. It ran the business for years and it is the reason the replacement was built around invariants and queues.
- Runtime state: Running in productionMailerClub
Dual sending paths during migration
The commercial mail transfer agent fleet stayed operational for months while the replacement engine matured. Twice the operational surface, deliberately accepted rather than performing a hard cutover on live campaigns.
- Runtime state: Partially wiredSupporting
Supplier and infrastructure CRM
A separate product: a dashboard and API where an agent watches an operator mailbox, classifies inbound infrastructure offers and writes them into the CRM without human intervention, alongside an encrypted credential vault.
Where to go deeper
The case studies cover six of these in full — the problem, the architecture, where AI is used and where it deliberately is not, the decisions, testing, results and lessons. The workflow library documents the process designs, each labeled with the same status values used here.