Fluid
An agentic orchestration platform — and three real products built on top of it.
The thesis
Most "AI agent" demos are a single script on a happy path. Fluid is built like a platform. Underneath sits an orchestration engine — a heartbeat scheduler that wakes agents, an OS-level watchdog that catches them when they hang, and recovery gates that bring them back instead of leaving them stuck at 2 AM. On top of that engine sits a module-agnostic shell. To prove the abstraction is real and not a one-off, the same shell runs three unrelated products: an autonomous Job Hunt pipeline, an Exam Hub tutor, and a 7-agent Product Studio that ships working web apps. The evals, truth-grounding, and cost tracking aren't the product — they're the reliability guarantees the platform hands to every module built on it. A second bet rides on Product Studio: that output quality is mostly a property of the harness, not the model — proven by holding a mid-tier local model to near-frontier results through context chaining, verification gates, and adversarial review.
What it does
Three real products on one orchestration layer
Fluid runs three unrelated modules on the same shell: Job Hunt (an autonomous application pipeline), Exam Hub (a spaced-repetition exam tutor), and Product Studio (a software team that ships working web apps). Adding a module means defining its agents, rubrics, and tables — not rebuilding the scheduler, supervisor, or model routing. That reuse is the whole point: it's a platform, not a one-off demo.
Job Hunt — a five-stage pipeline with approval gates
A Scout discovers opportunities and applies, a Researcher analyzes each company into a fixed 5-section dossier, and a Writer drafts tailored resume bullets and outreach. Every stage emits a reviewable, versioned artifact and waits for approval before the next stage starts. Match scoring uses hard-rule caps (deal-breaker keyword caps at 30, below salary floor at 50) so the model can't be polite past a structural mismatch.
Product Studio — a 7-agent team that ships running software
One sentence of product idea flows through PM spec, parallel Tech Lead and UI Designer design, a falsifiable-objection kickoff review, parallel Frontend/Backend build, an automated boot check, and QA that actually runs the built app in a sandboxed browser. QA once caught a real accent-color drift between shipped CSS (#7C3AED) and the designer's locked token (#E8846B) — a defect only visible by looking at the running product, not the transcript.
Reliability, handed down by the platform
Because every module inherits it: a truth-grounding verifier that refuses claims it can't cite, an evaluation harness that scores each agent against an explicit rubric (graded quality vs. pass/fail guardrails, averaged over N iterations), and a Model A/B Lab with a fairness contract that makes swapping models a measured decision rather than a guess.
In focus
The orchestration layer
How Fluid keeps agents running — not just running once
The part that makes Fluid a platform instead of a demo: an engine that schedules agents, supervises them, and recovers them when they fail, so the modules on top don't have to.
- →A heartbeat scheduler wakes the right agent for the right task across an async path (background, long-running work that becomes tracked issues) and a low-latency sync path (interactive Tutor / Quiz Master sessions) gated by a concurrency semaphore.
- →An OS-level timeout watchdog runs on its own daemon thread calling os._exit(124) directly — immune to event-loop starvation — so a stuck agent gets caught even when the main loop is blocked. It was built after a wedged agent ran 15 minutes because the parent-process timeout starved with the event loop.
- →Recovery gates at three points bring a failed run back into a known-good state instead of leaving it hung — made non-recursive and escalate-in-place after a cascade once turned 3 failures into ~40 blocked issues.
- →A Hermes Bridge telemetry seam tracks substrate health, cost, and parse confidence across every agent — the platform's nervous system.
One shell, three products
The abstraction that proves it's a platform
Job Hunt, Exam Hub, and Product Studio share nothing as products, yet all three run on the same orchestration shell — Product Studio with zero new scheduler machinery. That's the design bet at the heart of Fluid, and the evidence it pays off.
- →Adding a new module means defining its agents, rubrics, and domain tables — not rebuilding the scheduler, supervisor, or model routing.
- →Per-agent {model, provider} lives in an adapterConfig JSON column, so model swaps are a data-model concern, not a code change — Exam Hub's interactive agents each run a different role-matched model (Tutor on Nemotron-3-Super-120B, Quiz Master on Arcee Trinity, Planner on DeepSeek-V4-Flash).
- →The same approval gates, verifier, and eval harness wrap all three modules for free — quality and safety are platform properties, not per-module rework.
Harness over model
Product Studio's five-sprint thesis
Product Studio pushes a second bet: that output quality is mostly a property of the harness, not the model. It held a mid-tier local model (MiniMax-M2.7) to near-frontier results across a 5-sprint hardening program.
- →A full context supply chain feeds each agent exactly what it needs; a boots-or-blocked smoke gate refuses to advance a build that won't run.
- →Cross-run lessons.md memory carries hard-won fixes between runs, and browser-driving QA verifies the actually-built product with per-criterion verdicts — it once statistically verified a Pokemon mini-game's wild-encounter rate over 300 trials.
- →HTML-mockup design handoffs and a falsifiable-objection kickoff review make the team argue with the plan before it writes code.
A look inside
Architecture & decisions
- →Two-layer design: an orchestration engine underneath (heartbeat scheduler, OS-level watchdog, three-point recovery gates, a Hermes Bridge telemetry seam) and a module-agnostic shell on top that now runs three unrelated modules — Job Hunt, Exam Hub, Product Studio.
- →Two explicit execution paths under one shell: an async/heartbeat path where work becomes a tracked issue a scheduler wakes an agent to handle (Job Hunt, Exam Hub curation, Product Studio), and a low-latency sync path for interactive sessions (Tutor / Quiz Master) gated by a concurrency semaphore. Keeping them separate is what made Exam Hub tractable on the Job Hunt shell.
- →Electron desktop shell embedding a Node/Express server (REST + SSE) and PostgreSQL via Drizzle ORM with explicit migrations from 0090 through 0125; a CDP-controlled Chromium panel on port 9223 for real (non-headless) agent web work.
- →Agents run on a local Hermes CLI, each on a dedicated on-disk profile (~/.hermes/profiles/fluid-{role}-{id}/) with a composed SOUL.md (base persona + task-completion block + injected user context); per-agent model selection lives in an adapterConfig JSON column.
- →Product Studio reuses the generic issue/wakeup path with zero new scheduler machinery, adding a managed sandboxed headless Chromium (CDP :9224) so its QA agent drives the actually-built product; each product leaves canonical SPEC.md / DESIGN.md / DESIGN_UX.md on disk.
- →Reliability is inherited by every module: a deterministic truth-grounding verifier that refuses claims it can't trace to a cite-keyed fact base, an eval harness separating graded (0–100) from guardrail (pass/fail) dimensions with N-iteration averaging, and a Model A/B Lab that turns model choice into a measured experiment.
Engineering highlights
- →Ran a real bug-tracking program as a first-class artifact: 173 issues logged across 8 subsystems in per-issue markdown files, indexed by a generated ISSUE_LOG.md (pnpm bugs:build) — 172 Fixed with every Critical- and High-severity defect closed (1 Critical / 43 High / 86 Medium / 43 Low logged; one Analysed Medium enhancement remains).
- →Gated new feature work behind a multi-sprint stabilization plan after dogfooding surfaced systemic failures, then kept the discipline: atomic issue-number counters, optimistic-concurrency claims per automation tick, per-company FIFO locks on fact rebuilds, and an SSRF guard (scheme + IP + redirect + size + timeout) on URL import.
- →Diagnosed and fixed genuinely hard operational failures: a 30GB+ memory crash from importing a heavy SDK just to probe availability (fixed with importlib.util.find_spec, ~50ms); a wedged agent that ran 15 minutes because the parent-process timeout starved with the event loop (fixed with an in-process daemon-thread watchdog calling os._exit(124)); and a recovery cascade where 3 failures fanned out to ~40 blocked issues (fixed by making recovery non-recursive and escalate-in-place).
- →Built a fairness contract into the Model A/B Lab so it's an honest experiment, not a leaderboard toy: coverage-aware de-rating, null instead of fake-zero for ungradable output, cost + latency folded into the verdict, and one-click apply/revert of the winner. The first run kept Researcher on MiniMax-M2.7 over Hermes-3-405B on a measured 15-point graded edge with no guardrail regression.
- →Made model swaps a data-model concern rather than a code change: per-agent {model, provider} in adapterConfig, with the eval harness recording the model used on every run.
- →Proved a harness-over-model thesis for Product Studio through a 5-sprint arc on a mid-tier local model (MiniMax-M2.7): full context supply chain, a boots-or-blocked smoke gate, cross-run lessons.md memory, browser-driving QA with per-criterion verdicts, HTML-mockup design handoffs, and a falsifiable-objection kickoff review.
Why this matters
This is the PM artifact I'm proudest of, because it's a platform decision, not a feature demo. I built one orchestration layer and proved the abstraction held by shipping three unrelated products on top of it — the exact call a real platform team makes when deciding what to centralize. Getting there forced the questions that separate a product from a demo: where autonomy should stop (approval gates as reviewable, interruptible, reversible artifacts), how to define 'good' (per-role rubrics with graded vs. guardrail dimensions and N-iteration consistency), how to pick a model (an experiment with a fairness contract and cost in the verdict, not a vibe), and what happens when an agent fails at 2 AM (watchdog + recovery). It also shows operator honesty: a 173-issue tracker treated as the artifact, a 'what I'd do differently' section (evaluation before features), and a harness-over-model thesis I stress-tested over five sprints rather than asserted.
Want the full story?
Ask the portfolio chat, or reach out directly.