issue 001  //  09.08.2026  //  16:04 theme  //  snd: off
menu
homepage / 002 ux + product / Managerbot · supplier ordering03 / 07

Managerbot · supplier ordering

NDA
the images on this page are under NDA.if you have the password, you know what to do.
Square · Managerbot · August to October 2026

Managerbot supplier ordering

Managerbot is Square's AI agent for sellers. i designed and built the parts of supplier ordering where the seller signs in, checks what the agent did, and approves the order.

shipped · staging
the seller dashboard on staging, with the secure browser open
roleproduct designer + full-stack engineer
skillsinteraction design · prototyping · security UX · front-end · back-end
stackHTML/JS prototypes · Storybook · React/TypeScript · Go (Square's backend language)
teamme, the agentic commerce engineers, and the Managerbot designers
timelineAugust to October 2026
the problem

restaurant owners spend hours on admin, including ordering from suppliers like US Foods and Sysco. Managerbot can turn a handwritten list into a supplier cart, but sellers have to trust it with their logins and their money.

the work

i designed and built the steps where the agent hands control back to the seller: answering its questions, signing in, watching it work, and approving the order. i started with HTML prototypes, then built it in React and Go.

the outcome

sign-in, the secure browser, and the US Foods commands are merged and shipping soon. the whole flow ran end to end on staging, and i ranked every issue it turned up for launch.

anything that spends money or uses a credential goes to the seller first.the rule i designed around
chapter 01context
the business01
01managerbotSquare's AI agent for sellers, in open beta since April 2026 for most US food and beverage, retail, and beauty sellers at no extra cost. it's the proactive successor to Square AI: it watches the business and suggests what to do.
02from alert to orderit already tracks sales against stock and flags shortages before they affect service, and restaurants are among its most active users. supplier ordering is the next step: turning that alert into a cart.
03it proposes, the seller decidesSquare's public promise is that every action needs the seller's approval before it runs. my rule for sign-in and ordering follows the same idea.
the starting point02
01US Foods was lastthe team had already connected GFS, Sysco, and PFS, and hero sellers were using them. their sessions told us what sellers needed. US Foods was the one left.
02finding passwordsin the first alpha, a seller's order worked, but he spent two minutes looking for his supplier password.
03no view into the agentsellers couldn't see what the agent had read from their list before it changed their cart.
04my partevery step where a seller sees, fixes, or approves something, and the US Foods connection underneath it.
chapter 02designing sign-in
sign-in for a supplier that uses a password
prototype · early pass

sign-in for a password supplier

the supplier and website rows are locked, so the seller can see where the login goes. the password never goes into the chat or the model.

sign-in for US Foods
prototype · after checking the real portal

sign-in for US Foods

i signed in to the real US Foods portal and changed the prototype to match it: the login is a user id, and a new one-time code arrives every time.

saved-logins settings with design notes turned on
prototype · final draft

notes for engineering

each screen carries notes tied to the requirement it answers.

  1. 01a login belongs to the business and the person, is shared with the team by default, and has a toggle per login
  2. 02for one-time codes the seller picks a masked phone number like (***) ***-4416; Square stores the choice, not the number
  3. 03one question per card, so team sharing got its own card after sign-in
decisions03
01no reveal togglea saved password is never shown again. typing replaces it.
02autofillthe sign-in form lets the seller's password manager fill it. the settings form blocks autofill, so a browser never saves a supplier password as a Square login.
03the continue buttonthe handoff button says continue instead of complete, since the seller is taking control back.
04stopping on a rejected loginif a supplier rejects a saved login, the agent stops so the account doesn't get locked.
05the resize gripengineers wanted the grip between the chat and the browser always visible, and designers wanted it on hover. i went with hover, since that's how chat products handle it now and people already expect it.
06a sign-in that looks realthe supplier's sign-in runs in a hosted browser, which can feel off: the cursor doesn't change on hover like it would on a real site. i cropped the sign-in page to fill the card so it reads as a real sign-in, which matters when you're asking for a password.
chapter 03building it
connecting US Foods04

the goal was an alpha a US Foods seller could start using quickly, so hero sellers could tell us what to fix.

01learn from the othersthe two engineers behind the other suppliers built theirs differently: one from recorded browser traffic, one by clicking through the site. both told me not to copy the other suppliers.
02do bothi recorded the traffic and clicked through every US Foods screen, then wrote a spec for each command.
03find the limitsour test account had one location and no past orders, so reordering and switching locations couldn't be checked until a hero seller tried them.
04build for paritycommands built around how US Foods works, with the same capabilities sellers already had for the other suppliers.
the build05
01the secure browsera cloud browser beside the chat, so supplier cookies never reach the seller's machine. i measured staging down to the remote browser's 49px toolbar, found the page drawing about 9% off, and shipped the fixes as small, single-change code reviews.
02US Foods, in Gothe US Foods site saves whatever totals it's sent and underprices single items, so my commands calculate the total the review page shows. it also accepts delivery dates it won't honor, so the commands follow the date picker's rules.
a full run on staging, from a photo to a cart
shipped · staging

from a photo to a cart

each step is a point where the seller checks or approves something.

01 · the input, a whiteboard list
02 · the agent asks about the order guide, the location, and quantities
03 · the proposed order
shipped · staging

the proposed cart

the agent builds the order and stops there. nothing is submitted until the seller approves it.

issues from staging06

running the whole flow turned up problems. i fixed what i could and wrote up the rest, ranked for launch.

01the cart opened in the chatmy first version showed the finished cart in Managerbot. sellers submit the order on the supplier's site themselves, so i added a command that opens it in the sidebar browser, like the other suppliers.
02the run stalled at sign-inthe flow froze at the sign-in card, and i adjusted the handoff around it.
03US Foods blocked the cloud browserUS Foods turned away the hosted browser while my laptop session worked. the fix is an allowlist with US Foods, not a change in our code.
04an order saved without reviewonce, the agent saved an order without showing the cart review. i ranked it first to fix before launch.
05answered questions piled upa stack of answered question cards pushed the live one off screen. i ranked it high, next to an existing fix to the card layout.
06a misread countthe agent read x3 as x5 from the photo. the quantity question in step 02 is where the seller catches it.
by the numbers07
8prototype passes, each after a review
7Go changes merged for the US Foods commands
22lines read from one whiteboard photo
6issues found on staging, fixed or ranked for launch
AI in the process08

AI did a lot of the legwork, and i checked its work at each step.

01the prototypei built the HTML sign-in prototype with Claude, then revised it pass by pass.
02mapping US Foodsi ran every action on the US Foods site by hand first. then i had Codex drive the browser while i watched, recording the network traffic for each action.
03reading the codebasei used Claude to explore the repos, with an open-source clean-code skill ↗ to keep my changes tidy.
04review by handi reviewed every change myself before asking anyone else to review my prs.
what i learned09

ordering through the agent shouldn't take longer than doing it yourself.

most of the design had precedent in patterns the team already used, so the interesting work was in the details and in how the agent behaves.

if the agent asks five follow-up questions, the seller could have picked the items in that time. i worked on cutting steps, sometimes down to one, and on what goes into the agent's instruction file so it only asks when the answer actually matters.

the hosted browser showed me how much small details affect trust. a cursor that doesn't change on hover makes a page feel fake, so i spent real time making the sign-in look like a real one.

← homepage  //  002 ux + product © 2026 Naeema :)