FIQ·26Case file

FieldIQ — an AI field-selling platform, built solo

Four agents in production for CPG field reps, with the unglamorous parts — schema contracts, coded guardrails, and a hand-adjudicated eval harness — treated as the product.

Role
Solo PM — discovery, PRDs, UX, prompt design, eval, integration
Timeline
Jan 2026 – present
Stack
TanStack Start · Gemini 2.5 Flash · JSON schema contracts
Status
4 agents shipped · 2 PRDs in pipeline

Demos don't survive contact with commercial rules

The problem

CPG field reps need same-day, trustworthy answers: what to draft as an order, what they need to know before walking into an outlet, how their territory is actually tracking, and where a new outlet is stuck in onboarding.

Agent demos handle none of that reliably, because the real constraints are commercial — contract terms, minimum order quantities, activation status, promo cycles. An agent that proposes a confident, un-submittable order is worse than no agent at all.

Four agents in production

What shipped

  • Draft Order Agent — proposes orders with per-line commercial reasoning. The rep edits before submitting, and contract achievement recalculates live.
  • CommCheck — pre-visit intelligence, sorted into Act Today / Opportunity / Escalate.
  • Territory Pulse — a ten-second daily territory narrative: position, trajectory, concentration.
  • OnboardIQ — a four-stage new-outlet onboarding tracker with bottleneck detection.
  • ContractRadar and PromoPostMortem are PRD-complete and next in the pipeline.

Decisions that made it safe to ship

Architecture

  • Model-agnostic gateway with server-side inference — API keys never touch the client.
  • A strict JSON schema contract per agent, with typed fallbacks when the model deviates.
  • Gemini 2.5 Flash over a frontier model: rule-following beats deep reasoning for structured drafting, and mobile field use is latency-bound.
  • Guardrails hard-block recommendations outside the contracted SKU list and block ordering on unactivated accounts. Pack rounding, MOQ, and velocity caps are enforced in code, not in the prompt.
  • The mock data layer is an explicit validation-vs-scale scope decision, not a hidden shortcut.

26 golden cases, and a gate that failed

Eval — Draft Order Agent

26 hand-adjudicated golden cases across 13 categories: voids, out-of-stock recovery, post-promo damping, new-outlet, missing and conflicting data, and three safety traps. Quantities are scored on a tolerance band; reason code and safety behaviour are exact-match.

The ship gate is zero critical failures and ≥90% pass. This run cleared neither.

22 / 26

85% pass · 3 critical failures

Gate: Fail — by design
GC21Recommended an unauthorized SKUCritical
GC19Reconciled a conflicting signal instead of escalatingCritical
GC24Ignored a chain MOQ — un-submittable orderCritical
GC12Chased a post-promo spike it should have dampedNon-critical

19 cases, three findings worth keeping

Eval — CommCheck

19 cases across schema validity, rule adherence, and adversarial input — including a prompt-injection attempt buried in free text. Schema validity came back 19/19; rule adherence 18/19.

  • A "no markdown" formatting instruction had 0% compliance across all 19 runs.
  • The model silently extended a tier-scoped promo rule to tiers it was never given — a defensible decision, but an unowned one.
  • One failure was my own spec bug: I conflated a performance gap with a contractual breach. The model was right.
Prohibitions in a prompt are requests.

What held up: the injection attempt failed, and a "sympathetic context" case did not soften a mandatory payment escalation.