Case 01 / Product & operations
Pharmacia
I’m building a marketplace where pharmacies and pharmacists can arrange collaboration, hiring and shifts. I keep three things separate: completing a call, deciding to hire and committing to a shift. The product records each explicitly, rather than leaving the next person to infer what was agreed.
Outcome · what existsBuilt and operating; two founders’ decisions recorded. Operating record: 4 named ADRs, 3 documented failure modes, 26 logged build sessions. Launch planned 1 December 2026, a plan, not a shipped result.
The challenge
Pharmacy collaboration, hiring and shifts all turn on small decisions: did this call convert, is this person hired, is this shift committed? Chat threads and spreadsheets lose those decisions, and the next person guesses. The product records them instead: a completed call is not a hire, and every step stays explicit.
My role
In a two-founder team, I own the product rules and the engineering system around them: what the product decides, how work gets dispatched and reviewed, how context survives between sessions. Built with AI-assisted engineering, the rules and the review gates are mine; the product is ours.
The approach
I keep three states deliberately separate: a completed call gives eligibility, an explicit hire is a decision with reversal limits, and a linked shift is a commitment validated against both parties and the schedule’s state. The engineering side mirrors the discipline: bounded packets, a separate review gate, recorded decisions.
Agentic engineering
My rule is to change the worker and the reviewer separately, otherwise I cannot tell whether a new model did better work or faced an easier review. Each task states what the worker may change and what evidence it must return.
Task Packet. Task, risk tier, writable/forbidden paths, context pointers, locked constraints, completion criteria. Mixed security/UI work is split, never one unrestricted worker.
Result Packet. Changed files, tests, outcomes, residual risks. A confident summary is not acceptance evidence. The orchestrator owns routing and durable progress.
Review and escalation. I route schema, auth, data-isolation and payment changes to a review-only gate; bounded retries surface unresolved issues to a human, never spin.
Trade-off: handoffs add coordination work, and make scope, provenance and open risk inspectable. Records prove policy, not compliance.
Context layer
Rules: instruction files, versioned decisions. History: journals, error logs. Operations: skills, runbooks. Task state: planning systems, referenced not duplicated.
The trail is named and dated: ADR-003 (stable-prefix discipline), ADR-007 (context portability), ADR-009 (packet contracts, independent gate, model-swap governance), ADR-011 (two-founder governance). One documented claim, a header/body status inconsistency, was later superseded by journal evidence, and the record says so.
Swapping a model or session is an execution change, not a knowledge reset. Bootstrap checks reveal drift; files outrank compacted chat.
Trade-off: context needs upkeep. A stale journal still misleads, and local compliance ≠ server-enforced review.
Cache evidence
96.5% cached-input share: scope, method and what it does not prove
Cached-input token share
96.52% from local per-model usage counters · 26 project-scoped MiMo sessionsCohort: project-path sessions started 28 Sep–9 Oct 2026, from a local ledger snapshot on 12 Oct. Usage rows attributed to MiMo, not just the session’s initial label.
Method: 26 sessions, 51 usage rows from a local ledger, no conversation text read. Per-model rows beat session labels; mid-session model swaps otherwise misattribute.
| Counter | Tokens |
|---|---|
| Cache-read input | 66,925,152 |
| Uncached input | 2,414,418 |
| Cache-write input | 0 recorded |
Why the architecture is relevant. Prompt discipline puts stable instructions first, dynamic task state later. Durable context and targeted retrieval keep repeated material coherent while limiting waste. Caching, prompt similarity and session behaviour also matter.
What this does not establish. Not a request hit rate, not every agent’s cache result, not a 97% cost saving, not a controlled proof of causation. Input reuse alone says nothing about output spend, latency or correctness.
Evidence: read-only local usage ledger, inspected token-normalization logic. Selection by project paths, not a billing audit. Session-start dates define the cohort; zero cache-write tokens means none recorded, not free.
Decisions & failures
The failure record and how issues surfaced
Explicit hire state: product intent is guarded by server/database logic, not only a button. Reversal limits protect linked shifts.
Provider/model portability: project knowledge lives in versioned context and retrieved sources; model changes still require recorded role policy and validation.
Separate gate: reviewer and implementer changes are not combined in one evaluation window. A stable measuring stick matters when testing a new worker.
Known operational failures: stale context, model-pin drift, order-dependent test fixtures. The journals show how they surfaced, failure modes are part of the record.
Evidence inspected: architecture amendments, context-portability records, governance records, build journals. No private IDs, credentials or raw logs here.
The setup
Runs as a deployed product: Vercel and Stripe, staging until the planned 1 December 2026 launch. The engineering workflow runs against the repository: orchestrator dispatch, bounded workers, a separate review gate. The context layer, rules, journals, runbooks, lives in versioned files, portable across models and sessions.
Results and limitations
Code and history support the architecture; runtime, beta traction and release readiness aren’t revalidated here. The cached-input observation covers one project-scoped MiMo cohort, not the stack.
Product access. Andrea will provide a product demo. Launch is planned for 1 December 2026; no direct product access is offered here yet.
What I learned
Every late argument is a rule nobody wrote. If I restarted, the decision record would come before the first feature, the trail turned out to matter as much as the code it describes.