What the agent does
The agent starts from Square customer records and orders in the last 90 days, through the merchant account you authorize. The Square catalog entry in rush/shared/connectors/integrations.ts describes access to "orders, catalog/inventory, customers and invoices" and points to https://mcp.squareup.com/mcp. This job uses customers and orders only. It identifies the locations and reporting window covered by the connection before adding up spend, because a partial location list should never be presented as the whole business.
It joins orders to customers using the customer identifiers returned by Square, not matching names or email addresses by guesswork. Orders without a customer association are counted as unassigned coverage, not distributed across likely buyers. The agent writes down how it treats completed, cancelled and refunded orders and which amount counts as spend. Different currencies remain separate rather than being summed into a meaningless total. Any refund data the available tools do not expose is called out beside the spending definition.
For this report, define a visit as a distinct eligible order, unless you provide a different business rule. That makes the count reproducible without claiming to know whether someone entered a physical store. The agent ranks the top 20 linked customers by spend, includes order count and last eligible order date, and applies the lapsed-regular rule: at least three visits in the window and no visit for more than 30 days. The report labels that window-limited definition instead of calling it lifetime loyalty.
The result is customers.md, with ranking tables, the lapsed-regular list and the limitations needed to use both responsibly. There is no repository and no GitHub setup for this work. The minimal request below still requires connection setup: explicitly add your Square MCP connection's id in connections before a live run, following the developer API quickstart. Its prompt does not grant account access. The agent must report missing tools or permissions instead of writing a customer list from invented transactions.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the explicitly selected Square connection to read customers and orders for the last 90 days. Stop and report missing access if Square tools are unavailable. Write customers.md with locations, exact dates and timezone, the spend and refund treatment, the top 20 linked customers per currency by eligible order spend, order counts and last order dates. Define a visit as a distinct eligible order. List customers with at least three such visits in the window whose last visit was more than 30 days ago. Report anonymous/unlinked orders and incomplete coverage separately. Read only: do not update customer profiles, create audiences, send messages or change orders."
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
customers.md contains a scope and methods section, a spending leaderboard and a separate list of potentially lapsed regulars. Rows use customer identifiers and only the display information needed by an authorized reviewer. Each total includes its currency, eligible-order count and last-order date. A coverage section explains unlinked orders, inaccessible locations and any missing refund information, so the lists do not pretend to be more complete than their source data.
Review a few customers against their Square order histories before planning outreach. Confirm that the visit definition makes sense for your business: several delivery orders can represent repeat purchases without store visits. Check that a refunded purchase has not inflated a customer's rank. The report does not send thank-you notes, create a marketing segment or contact lapsed customers; those decisions remain with your team.
Run it on every customer retention review
A weekly or monthly job in your own scheduler can submit this request with fixed reporting dates and the selected Square connection. Use one Idempotency-Key for retries of a particular snapshot, then a different key for the next review. When Rush sends the completion webhook, your server reads the session and downloads customers.md into the approved internal reporting destination. Restrict its audience rather than publishing a customer list as a public artifact.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A useful retention list needs customer joins, currency separation and an explicit definition of a visit. Rush gives the agent a cloud sandbox to work through those details without leaving exports scattered across a laptop. The request carries the reporting rules, and the result explains how those rules translate into the customer rows you are about to use.
The recorded tool calls let an authorized reviewer trace a disputed total back to the order data rather than trusting a summary sentence. You can run independent reporting snapshots without keeping a local process alive, then retrieve the finished file through the session. That convenience does not remove the need to protect customer information or review the list before outreach.
Frequently asked questions
Does best customer mean lifetime spend?
This request ranks eligible spend inside the last 90 days. It does not claim to measure lifetime value. Change the reporting period and define the amount explicitly if you need a different comparison.
How does it identify a lapsed regular?
The rule uses at least three eligible orders in the reporting window and a last eligible order more than 30 days ago. It is a purchasing-history flag, not proof that the customer has left. Seasonal buying patterns can require a different threshold.
Can it include anonymous purchases?
Anonymous or unlinked orders can be reported as a coverage total, but they cannot be assigned reliably to a customer. The agent must not guess identities from similar names or purchase amounts. The customer rankings include only linked records.
Will it message customers or edit Square?
The prompt forbids customer updates, messaging and order changes. customers.md is the deliverable for internal review. Connecting an account with write-capable tools does not turn this read-only request into permission for outreach.