MerchantPilot — AI Joe for Owner-Controlled Operations

MerchantPilot gives independent merchants AI Joe—an owner-controlled manager that coordinates specialist workers into practical plans with visible risks, approval gates, and action tracking.

Comment

Inspiration

When I think about MerchantPilot, I think about the owner of a small shop dealing with several problems at once. A slow week is not only a sales problem. It can affect inventory, pricing, marketing, customer retention, cash flow, and staff priorities—all at the same time.

A larger company can send those questions to different departments. An independent merchant usually has one owner making every decision, often under time pressure.

I did not want to build another chatbot that gives a long answer and leaves the owner to figure out what to do next. My idea was to give the merchant one AI manager, AI Joe, who coordinates several bounded specialists behind the scenes. Joe should return a visible plan—not take control of the business.

That owner-control principle became the most important part of MerchantPilot.

What it does

A judge can open MerchantPilot without creating an account, select Agentic AI Console, and run the Slow Sales Recovery workflow using safe sample information for a coffee shop.

AI Joe coordinates seven specialist workers covering:

  • Business health
  • Inventory
  • Pricing and margin
  • Marketing
  • Customer retention
  • Cash flow
  • Operating procedures

Their structured findings are assembled into one seven-day operating plan. The merchant can see which workers ran, what each one found, which results need attention, the main risks, and what still requires owner review.

A second workflow, Inventory Recovery, coordinates six workers to help a merchant sell through slow-moving stock while protecting margin and cash.

The Owner Action Tracker turns recommendations into reviewable work. The owner can mark an approval gate as approved or a checklist item as done, but these controls are tracking only. MerchantPilot does not automatically publish a price, contact a customer, purchase inventory, or move money.

Workflow history and tracker progress stay in the current browser. Raw optional context is intentionally excluded from reports and saved history.

How I built it

MerchantPilot uses a Next.js, React, TypeScript, and Tailwind frontend with a Python, FastAPI, and Pydantic backend.

The Branch G workflows use a typed registry and deterministic specialist worker functions. Each worker returns a structured result, and AI Joe assembles those results into the report, quality signals, execution timeline, operating plan, and owner action items.

I kept workflow history and action tracking in separate browser-local storage keys. I also added defensive handling for malformed saved data and blocked unsupported workflow IDs instead of allowing arbitrary work to run.

The frontend is deployed on Vercel and the backend on Render.

What changed during Build Week

MerchantPilot existed before OpenAI Build Week, and I want to be transparent about that.

The pre-event baseline is commit 08800e9, dated June 8, 2026. It already contained the MerchantPilot platform, the Branch G worker portfolio, and the first Slow Sales Recovery Workflow Center.

PR #206 was merged during the event, but its source commit was also authored on June 8. I therefore treat its workflow-history and safe-rerun implementation as pre-existing work. Eligible Build Week source work begins with PR #207.

During the submission period, I added:

  • PR #207: Detailed inspection of saved workflow runs
  • PR #208: Result-quality signals and summary badges
  • PR #209: The deterministic Inventory Recovery workflow and tests
  • PR #210: A searchable and filterable workflow catalog
  • PR #211: The workflow execution timeline and active run console
  • PR #213: Production-build hardening completed with GPT-5.6 Sol in Codex
  • PR #212: Owner approval gates and the browser-local action tracker

These additions changed the judge experience from viewing one workflow result into using a clearer operating console: choose a merchant problem, see the coordinated work, inspect the result, understand its risks, and track the owner's next decisions.

How I worked with Codex

I worked in small, focused tickets because MerchantPilot already had many connected frontend and backend components. Rather than asking Codex to “finish the application,” I gave each task a specific goal, safety boundaries, acceptance criteria, and tests.

Codex was especially valuable when one feature crossed several layers.

For example, the Owner Action Tracker required changes to TypeScript types, local persistence, workflow reports, saved-run details, history cleanup, and Markdown export. Codex helped carry the same contract through all of those areas without exposing raw optional context.

I made the product decisions: keep the owner in control, avoid external side effects, use local-only tracking for the pilot, focus on one reliable judge path, and stop adding features once the demonstration was stable. Codex accelerated repository inspection, implementation, testing, debugging, and preparation of reviewable pull requests.

How I used GPT-5.6 Sol

For TKT-G033, I opened a fresh Codex session with GPT-5.6 Sol Extra High selected.

The problem was surprisingly small but important: the frontend used next/font/google to download the Inter font during a production build. In a restricted or offline environment, that network request could fail before the application compiled.

GPT-5.6 Sol helped trace the failure to the root layout and produce a focused one-file fix. PR #213 removed the remote font dependency and preserved the visual design with Tailwind's existing font-sans stack. I then validated lint, TypeScript, the production build, and the judge demonstration path before merging it.

This is specifically an engineering-use claim. I am not claiming that the deployed MerchantPilot chat runtime uses GPT-5.6. Its verified contribution is the Codex production-readiness task documented in PR #213.

Challenges and lessons

The hardest product question was deciding what “Approved” should mean.

It would have been easy to make the interface look more autonomous, but that could mislead a merchant into thinking a price was already published or a customer had already been contacted. I chose a clearer boundary: approval records the owner's decision, while real-world execution remains outside the console.

Another challenge was presenting multi-agent work without exposing hidden reasoning or overwhelming the user. The execution timeline therefore shows observable worker results, statuses, safety notes, final assembly, and owner review—not private reasoning traces.

I also had to be careful about the Build Week boundary because MerchantPilot was not a new project. Preserving the baseline and distinguishing PR #206 from the eligible work beginning with PR #207 took extra effort, but it makes the submission more honest and reproducible.

I learned that useful agentic software is not defined by how much it can do automatically. Trust comes from clear boundaries, visible evidence, and knowing where the system stops.

I also learned that Codex works best when I give it a narrow problem, explain the constraints, and review the result as an engineering collaborator rather than treating its first answer as final.

What I am proud of

I am proud that MerchantPilot now turns one merchant problem into a coordinated plan that the owner can understand and control.

The detail I value most is that the system does not confuse a recommendation with an action. It shows the work, identifies the risks, asks for approval, and leaves the final business decision with the merchant.

What's next

The next step is to move tracker state from browser-local storage into authenticated merchant accounts with an audit-ready approval history.

I would then introduce carefully scoped, read-only POS and inventory connections, test MerchantPilot with pilot merchants, and measure whether it saves time and improves decision quality. Any future external action would remain behind explicit permission, owner approval, and reversible controls.

My long-term goal is simple: help independent merchants benefit from the coordinated thinking of a larger company without taking control away from the owner.

Built With

Share this project:

Updates