naeema.

a restaurant seller hands the agent a 22-line list — a whiteboard photo, a text message — and the agent turns it into a supplier cart. that only works if the seller trusts it. trust breaks at specific moments: did it read my list right? where is my password going? what is it doing inside my supplier account right now? did it order what i meant?

my work was those moments. the vendor plumbing and the agent itself belonged to others; the boundary where a seller sees, corrects and approves belonged to me.

it started in august with a live alpha: a real seller ran the first production order and it worked, but he spent two minutes hunting for his supplier password, and the team wanted a surface where sellers check what the agent read before anything touches the cart. i wrote a short brief claiming that review layer as my lane, then prototyped it as a storybook card in the production repo: every line from the seller's list beside its matched product, a confidence state (confirmed, needs review, no match), editable quantities, include or remove — approval before any mutation.

the password hunt became the next lane. suppliers authenticate differently — some use passwords, us foods emails a one-time code to a contact on file — and the capture ui had to hold a hard boundary: square's chat and the agent's model never see a secret.

i prototyped the whole flow as a single html file and iterated it in eight documented passes, each driven by real feedback. a whiteboarding session with product and engineering set the scoping rules: credentials belong to the merchant and the person, sharing defaults on with a per-login toggle. i signed into the real us foods portal and corrected my own prototype against it — the identifier is a user id, not an email, and offering a passkey makes no sense for a vendor that mails you a fresh code every time. a security pass rewrote code delivery so the seller picks a masked destination, (***) ***-4416, and square stores the pick, never the contact.

when the agent works inside a supplier's site, the seller watches it in a side pane: a remote browser running in the cloud, streamed into the dashboard, so supplier cookies and credentials never touch the seller's machine. the direction from the feature's owner: it should feel like an embedded page, not a browser. i ran three rounds of mockups pixel-matched against staging — down to measuring the remote browser's 49px toolbar and finding the viewport math drawing the page 9% too small — kept the team aligned on a figjam board that became the working status artifact, and shipped the polish as a train of small, single-change prs.

in october i went below the ui: the command layer the agent uses to drive a us foods account. i reverse-engineered the portal from recorded api traffic and the site's own javascript into a written command-surface spec, then built it — session status and sign-out, customer-location switching, product search, order guides, order create, edit and clear, delivery dates, and the browser handoff.

the vendor's quirks became the spec. us foods saves whatever totals you send and never recomputes them, and its own site underprices changed items, so my commands compute the review-page sum instead of trusting the site's. the server accepts delivery dates it will never honor, so the commands implement the date picker's rules themselves. a session reports ready only after waiting out the site's own token renewal.

the last week was testing the whole chain on staging: photo in, cart out. the runs surfaced real issues and the handoff names each one with evidence — the vendor's bot-blocking fired on the hosted browser while my laptop session worked, so the fix is an allowlist, not our code; the agent once saved an order without the cart-review step, the first thing i would fix; a stack of answered question cards buried the live one. i left a written handoff with the open prs, the test log, and a priority on every issue.