Agent Nomad: first look, what's done, and getting it pilot-ready

Rules and patterns let your agents keep building while the product gets less overwhelming for a first-time user. That's the job before a pilot.

Molly Ford · September 2026

First look: six changes

A few hours in the app. Ranked by how much they move the product. What's already working: the signal detail has every view we listed on the call, the plan detail has the right bones, and the step chip row is the best pattern in the product. None of it needs rebuilding; it needs to be easier to read and act on.

  1. One vocabulary. The nav says signals, the home page says claims, the detail says finding, the banner says insights, and there are seven tier words. One noun per thing, four tier words on the surface.
  2. Subtract the prose. A paragraph defines "gradeable" on the home page, every signal repeats a disclaimer, each action is fifty words. One sentence per slot; the explanation lives once, behind "why."
  3. One rail, one toolbar, one behavior each. Ask swaps the evidence out for chat; Create a plan pushes the signal down the page. Evidence and chat share the rail; create-a-plan is a panel that ends on the plan.
  4. The create-plan seam. The plan carries one of the recommended actions and apologizes for the rest. It wants to be a checklist of every action, a target, the three switches, one Create button. You named this bug on the call.
  5. The row says how bad and how sure. Today a card is a four-line headline and an unlabeled meter; "how bad" exists only in the filter. Severity and tier as words on every row.
  6. The 400 open signals are mostly daily reissues. Churn Risk appears six times in seven days with the same title. New signal or refresh is a data-model question before a design one, and the biggest lever on the number in the nav.

What's done

A display-rules doc. When things open in a panel vs a page, what a human decision looks like, where agent output goes, one vocabulary. Written so your coding agents load it from the repo; it lands as a PR on a branch.

A prototype of the signals page, in progress, built by those rules on your own signals to stress-test them. Nothing added, only reworked. I'll walk you through it when it's ready.

Getting it pilot-ready

Sprint 1 · Signal to plan, end to end

In your components. This is the bar for putting a first pilot customer in front of it.

  • The signals list: how bad and how sure on every row, daily reissues collapsed
  • The signal detail: actions as a list, evidence readable at a glance
  • The create-plan seam: every recommended action carried, the approval switches set up front, lands on the plan
  • One vocabulary across list, detail, and plan
Done means a new user gets from the list to a plan carrying every recommended action without reading a paragraph.

Sprint 2 · Plans at scale

What pilots hit next, once plans accumulate.

  • The plans list at 100 active plans: what needs you, first
  • Auto-run with undo, behind the account writeback switch
  • What a plan shows after it runs: what changed, against what criterion
Done means a plan that has run shows what it changed and can be undone from the run, and the list still tells you which plans need you.

I move at your pace, days not weeks. Flat number for sprint 1 at the end of the walkthrough, once I've seen how you're building. After pilots are in, I iterate on what they hit, and we decide on ongoing support then.

What I need

  1. Read access to the repo and a way to run it locally. A dev instance is fine; I'll sign whatever.
  2. Who's building day to day, and in what stack, so the rules land where they get read.
  3. The pilot's target date, so sprint 1 lands before it.
  4. Two answers. When a signal re-records daily with the same title, is that a new signal or a refresh? And the "unanswerable" ones: a data gap for the customer, or a bug for you?