How embedded agents like shopify sidekick transform user experiences

Embedded agents like Shopify Sidekick improve user experiences by using in-app context to propose changes for review before applying them.

IRSIsh Rajesh ShelleyFounderAugust 7, 20269 min read
On this page

An embedded agent changes a product experience when it helps a user finish work in the place where the relevant data, controls, and consequences already live. Shopify Sidekick is a useful example: it operates in Shopify Admin, uses the store and current page as context, and presents changes for review before they are applied. That is a different proposition from placing a general chat box next to a product.

Product teams should study Sidekick's operating pattern, then redesign one frustrating sequence around their own customer goal. Let the agent gather permitted context, take a constrained set of product actions, show the resulting proposal or outcome, and hand the important decisions back to the user. The product remains the source of truth and the control plane.

The old experience asks users to translate intent into navigation

Most mature SaaS products have accumulated useful power in the form of records, settings, screens, rules, and workflows. The cost is that a user who knows the desired outcome must also learn the route through that power.

A store operator may know they need to prepare an order, investigate a drop in sales, update a group of products, or configure a promotion. In a conventional interface, that intent becomes a sequence: find the relevant records, open several screens, interpret current state, make choices, and check the result. Search and help content reduce some friction, but they leave the user responsible for coordinating the work.

An embedded agent changes the starting point from a command to an outcome. A request such as “prepare these products for a summer sale” requires the product to identify the products, surface relevant constraints, propose the changes, and make clear what will happen before it changes state. Reducing that translation and coordination creates the value. Conversational polish is secondary.

Shopify describes Sidekick as an AI-enabled commerce assistant in Shopify Admin that can answer questions, generate content, and complete tasks in everyday language. Its documentation also says it uses the current page as context, and that it presents changes for review before applying them. Shopify's Sidekick overview and getting-started guide are a useful reference for this pattern.

Context makes the interaction product-native

Strong embedded agents begin from the record, workspace, role, and workflow the user is already using. Requiring users to restate available product context adds friction and creates room for mismatches.

That does not mean handing the model the entire customer database. Context needs an explicit product boundary: the requesting identity, tenant, selected records, fields required for the job, and the policies that determine access. The server enforces that boundary. The model may help decide which permitted operation advances the job; it does not decide who is allowed to read a record.

The interface should keep the agent beside the work and show what it inspected, which records are in scope, what it found, and the next decision. Shopify's documentation illustrates this on mobile: Sidekick stays visible as a merchant moves among orders, analytics, and products, so follow-up work does not require abandoning the screen in front of them. Shopify's Sidekick setup guidance documents that behavior.

For a B2B SaaS example, consider an account manager who asks to prepare a customer for a renewal review. The agent can assemble authorized account history, open risks, recent activity, and missing fields into a reviewable brief. It can suggest an update. It should not silently change an owner, alter commercial terms, or send customer communication because its summary sounded plausible.

An agent earns trust through visible product work

The important user-experience shift is from answer delivery to work that can be inspected. A chat transcript is rarely enough when an agent affects a record, a configuration, or an external communication.

Sidekick's order-editing flow provides a concrete pattern. Shopify says Sidekick proposes order updates, highlights updated fields, and applies the update only after the user reviews it and selects Update order. The user evaluates the exact product change before execution. Shopify's order-editing documentation describes the flow.

The appropriate level of review depends on consequence. A product agent may collect evidence and create a draft with no extra approval. It should stop at a meaningful boundary before it merges records, changes access, moves money, publishes content, or contacts another party. The review surface needs the affected object, proposed action, evidence, and a clear way to reject or amend the change.

That design has an engineering consequence: proposal and execution should be separate product operations. Narrow actions such as get_renewal_context, prepare_renewal_brief, and apply_approved_updates are easier to authorize, test, and explain than an unrestricted update_account tool. The product API validates inputs, permissions, tenant scope, approval, and idempotency. The agent orchestrates the permitted work; the system of record decides whether a change is valid.

Background work must return to a durable result

An agent feels more capable when it can continue a longer task without keeping the user trapped in a chat session. But background execution is only a user-experience improvement if the result returns to an understandable product state.

Shopify says Sidekick can continue longer tasks in the background after a user closes the chat or navigates away, then notify the user when the work is ready for review. Its Sidekick documentation describes that behavior. A product team implementing a similar pattern needs durable workflow state: selected scope, completed checks, proposed changes, approval status, tool results, and the reason a run paused or failed.

Without that state, a refresh can make the agent rediscover work, a retry can duplicate a write, and a user cannot tell whether the result came from the intended records. A useful completion message links back to the draft, record update, exception, or task that now exists in the product. The durable product state is the result; the agent's prose guides the user to it.

Expose a deliberate action surface

Once an agent can act, every tool becomes part of the product's behavioral contract. Teams often make the mistake of exposing a broad administrative API and trying to control it with instructions. A better approach is to expose a small set of product operations that each map to a real user job.

Shopify's developer platform follows that direction for third-party integrations. Developers can register app tools that Sidekick invokes to search app data and answer questions, and Shopify describes the target and tool configuration in its app-tools documentation. Shopify's help center also notes that Sidekick requests approval before using an installed third-party app in a conversation. The Sidekick integration guidance shows that every integration needs an access and user-consent decision alongside the model connection.

For an embedded agent in another SaaS product, each action should have a narrow input schema, server-side authorization, predictable errors, and an observable result. Define what happens for missing data, ambiguous matches, denied permissions, tool failures, and already-completed work before launch. These cases are where a helpful demo becomes a dependable product experience.

Not every feature needs an agent. Use a chatbot when an answer, navigation instruction, or handoff resolves the request. Use deterministic automation when the trigger, sequence, and exceptions are already known. Use a copilot when the product can prepare useful work but the user should direct the sequence. An agent is warranted when the path depends on current product state and it must choose among constrained actions to reach a checkable outcome.

What to build first

The first embedded-agent experience should complete one valuable job. Choose a recurring workflow where users already spend time collecting context and navigating steps. Once it works reliably, the team can decide whether additional product surfaces should become promptable. Define:

  • the trigger and visible finish state;
  • the records and actions that are in scope;
  • the point at which a user must review a consequential change;
  • the owner for unresolved exceptions; and
  • the evidence that proves the workflow completed correctly.

Test that workflow against routine work and problematic states: incomplete records, conflicting evidence, ambiguous targets, denied access, failed tools, retries, rejected proposals, and work that is already complete. Evaluate the action sequence, final product state, and response quality.

Where Ginger Labs fits

Ginger Labs supplies the embedded agent or copilot layer inside a SaaS or web application, whether that is a side panel, inline surface, or modal. It can work with a product's schemas, stages, records, and data so a customer can ask for an outcome in the context of the work already in progress. The SDK includes retrieval, evaluations, self-learning loops, and observability.

In a Sidekick-style rollout, Ginger Labs sits between the customer-facing workflow and the product capabilities the team chooses to expose. Your team still owns the API and data model, domain rules, user permissions, tenant boundaries, approved actions, review experience, and business definition of a correct result. That division keeps the agent connected to the product without outsourcing product policy to a model.

If selected product capabilities also need to work in compatible external AI clients, Ginger Labs can manage MCP infrastructure. That is a separate distribution choice from the embedded experience. It does not remove the need to validate authentication, authorization, tenant scope, input handling, and approval behavior in each client.

Embedded agents transform the experience when they let a user state the job, see the product work, and remain in control when the consequence changes. Start with a job customers already struggle to finish. Make its result visible, its authority narrow, and its exceptions explicit. These properties give the agent a measurable role in the product experience.

If you have a workflow customers repeatedly struggle to complete, bring it to a 20-minute Ginger Labs demo. We can scope the job and demonstrate an agent in a sandbox of your product.

Sources

About the author

IRS

Ish Rajesh Shelley

Founder·Ginger Labs

Ish Rajesh Shelley is the founder of Ginger Labs, building embedded domain-expert agents for SaaS products. Ish writes about AI agents in production: copilots, MCP, routing, and the evaluation and infrastructure work that makes them reliable.