Build POS with an AI agent

Most of what makes a register distinctive is Salesforce records and Liquid: layouts, layout fields, views, action groups, action items, and print templates. That is work an AI agent is well suited to, because it can read what already exists and write more of the same shape.

The route to it is the Salesforce CLI. POS configuration is not currently in scope for the StoreConnect MCP, so an agent works with POS the way a developer does, by querying and changing Salesforce records directly. This suits partners and implementation teams, who already have the CLI authenticated against the orgs they build in.

What the agent needs

Two things, and neither requires a store connection.

• The StoreConnect AI skills. These are knowledge rather than access, and are fully useful with nothing connected. They teach an agent StoreConnect’s Liquid, its record conventions, and its object model, which is what stops it writing plausible Salesforce code that StoreConnect does not accept. See Install the StoreConnect AI skills.
• An authenticated Salesforce CLI. The agent reads and writes POS records through it, in whichever org you point it at.

The reference material an agent needs is already published. Point it at the POS actions reference for what an action can do and the parameters it takes, the POS object references for the configuration objects and their fields, and the Liquid references for what a view can render.

What it can do

• Read the current configuration and explain it, which is often the first useful thing when you have inherited a register setup nobody documented.
• Build a layout and its fields for an object, including the filters and sort order a list needs.
• Write a POS View, since a view is a Liquid template and the skills cover Liquid.
• Assemble an action group and its items, including the home grid and menu structure.
• Reproduce a working register for a new purpose, adapting an existing setup rather than starting from nothing.
• Draft a print template for a receipt, docket, or label.

Describe the counter you want in plain language, such as the job the register does and what the operator should see first, rather than naming the records you expect to be created.

Two guardrails that matter here

A CLI write is immediate. There is no staging step and no approval prompt between the agent and the org. What it writes is live the moment it writes it. Give the agent a sandbox to work in, review what it produced, and move the result deliberately rather than building against a trading org. See Deploy POS configuration to production.

Because there is no approval step, the authenticated user’s permissions are the guardrail. Give the agent its own API-only integration user, scoped to the objects the work needs, rather than letting it act as yours. See Build across multiple orgs as a partner.

POS configuration is org-wide. None of the POS configuration objects carry a store, outlet, or register field. A POS Layout, POS View, POS Action Group, POS Action Item, POS Layout Field, POS Layout Filter, and POS Print Template are all placed by their Identifier, so two stores in the same Salesforce org share them. A change intended for one store reaches every store in the org. Be specific about which identifier you intend to change, and where behavior needs to differ between stores or outlets, build that into the view rather than expecting the record to be scoped.

Ask for configuration that will deploy

An agent reading a sandbox will copy the Salesforce IDs it finds there, and those are exactly what breaks on the way to production. Include it in the instruction: placement by identifier, products by product code rather than product ID, and environment-specific values read from Store Variables. See Deploy POS configuration to production for the full set of patterns.

Work in this order

1. Install the skills for your agent, so it works from StoreConnect’s conventions rather than generic Salesforce ones.
2. Authenticate the Salesforce CLI against a sandbox, and confirm the agent is pointed at it and not at production.
3. Show the agent an existing layout or view to follow, so what it writes matches the conventions already in the org.
4. Review the records it created in Salesforce, then load a register and check the screens render.
5. Move the result to production by the same route as any other POS configuration.

An agent working this way produces the same records an administrator would, which means the result is reviewable in Salesforce and deployable by the normal path.