Case studies

Three systems, in detail.

The problem as it arrived, the decisions I made, the architecture I chose and how each system behaves when something goes wrong.

01 / Autonomous multi-agent content platform

dailynetwork.news

A network of city news sites publishing continuously, where every article has to clear editorial judgment before it reaches a reader, without an operator watching each step.

View live

Problem

High-volume publishing collapses under manual review. Quality, factual accuracy and geographic correctness all have to be enforced by the system itself, and a failure must be contained rather than published.

Approach

I designed the platform as a chain of specialised agents with explicit handoffs: sourcing and generation, fact verification against source material, quality scoring, a geography gate that rejects content mismatched to the city, image matching, then publication. Each gate is a release condition, not a suggestion, so an article that fails any stage never reaches the front page.

Architecture

Supabase and Postgres hold content, evaluation results and operational memory with row-level security. Deno edge functions run the agents and the control loops, scheduled with pg_cron. Health checks probe every domain on a short interval and a watchdog auto-unpublishes content when a gate result degrades after release, so the network heals without intervention.

Reliability

The platform carries its own operational memory: health state per domain, freshness of source feeds and a growing set of rules derived from past incidents. Recurring failure modes become permanent guardrails rather than tribal knowledge.

Outcome

A production publishing system designed to detect, contain and recover from quality failures autonomously across the whole network.

Deno edge functionsSupabasePostgrespg_cronRow-level securityMulti-agent orchestrationEvals

02 / Capital-raise lead engine

the Lawson CRM

A property capital raise with a specific investor process that generic sales software described badly and slowed down.

Private investor tool

Problem

Off-the-shelf CRMs assume a standard sales pipeline. A capital raise runs on relationship context, careful sequencing and messages that cannot be sent carelessly, so the team needed the tool shaped around their process instead of the reverse.

Approach

I ran discovery with the people doing the raising, mapped the real stages of an investor conversation, then built the CRM and lead engine end to end: enrichment of inbound and sourced contacts, sequencing tied to the stage of the relationship, and tracking of every touch in one place.

Human in the loop

Automation handles research, drafting and preparation. Anything consequential, particularly outbound to an investor, waits for explicit human approval. The design assumes the cost of a wrong message is far higher than the cost of a pause.

Architecture

A React and TanStack front end over Supabase and Postgres, with server-side logic for enrichment and sequencing and row-level security separating access. Deployed on Cloudflare.

Outcome

A private investor tool built around the team's actual fundraising process, with the manual busywork removed and the judgment calls kept with people.

ReactTanStackSupabasePostgresCloudflareEnrichment pipelines

03 / Resilient model orchestration and cost control

Provider-failover LLM router

Generation workflows that a business depends on, running across several model vendors whose availability, pricing and quality all move independently.

Problem

A single-vendor dependency turns any provider incident into a full outage. Left alone, model spend and output quality both drift, and the drift is usually noticed late.

Approach

I built a router across Anthropic, OpenAI and Google that treats vendors as interchangeable capacity behind one interface. Each task declares the quality bar it needs, and the router sends it to the lowest-cost model that clears that bar, falling through to alternative providers on error, timeout or rate limit so work keeps moving during any single-vendor outage.

Cost and quality control

A per-day spend guardrail caps consumption, and routing decisions are recorded so cost per task and quality per model stay visible. When a cheaper model stops clearing its bar, routing shifts rather than quality quietly degrading.

Architecture

A provider-agnostic calling layer with normalised errors, retries with backoff, per-task quality thresholds, spend accounting in Postgres and structured logging of every routing decision.

Outcome

More resilient AI operations, with quality and cost control built into routing rather than reviewed after the fact.

Anthropic / OpenAI / Google APIsTypeScriptPostgresFailover and retriesEvalsSpend guardrails

Start a conversation

Get in touch

Happy to walk through any of these systems in more depth, including the failure modes and the trade-offs behind them.

sa@dailynetwork.news Back to portfolio