Intelligence Commerce Suite (ICS)
Functional Document
1. Overview
What is the Intelligence Commerce Suite?
The Intelligence Commerce Suite (ICS) is an AI-powered commerce platform that helps retail and e-commerce businesses run intelligent, automated operations — without building AI infrastructure from scratch.
Businesses today use multiple commerce platforms (Shopify, Salesforce, Equinox) and generate vast amounts of data — product information, customer orders, return policies, sales forecasts. But turning that data into real-time, intelligent actions is slow, manual, and fragmented.
ICS solves this by providing:
- A single place to build and run AI agents that act on your commerce systems automatically
- A Knowledge base where you upload your policies, documents, and architecture — and agents can use that knowledge when responding to customers or making decisions
- Predictive analytics that forecast demand, detect churn, and recommend actions using your own data
- Connectors to link your Shopify, Salesforce, or Equinox accounts — so agents can read and update real data on your behalf
- Strict data isolation so each business’s data, AI spend, and access controls are completely separate
Who is ICS for?
| Who | What they do on ICS |
|---|---|
| Platform Operator (Infosys / EQPLAT team) | Sets up organisations, manages the platform catalog of pre-built agents and models |
| Organisation Admin | Manages their company’s account, sets up tenants, invites admins, controls costs |
| Tenant Admin | Manages a business unit or store — connects to Shopify/Salesforce, creates agents, manages users |
| Business User | Day-to-day commerce operator (merchandiser, customer service rep, analyst) — uses agents and views dashboards |
2. Glossary
| Term | What it means |
|---|---|
| Agent | An AI assistant configured to perform specific commerce tasks — it can read data, make decisions, and take actions on your systems based on instructions you define. |
| Workflow | A multi-step automated process built from a sequence of agent, connector, and decision steps — like a flowchart that runs automatically. |
| Trigger | The event that starts an agent or workflow — can be a schedule (e.g., every Monday at 9 AM), a commerce event (e.g., a customer submits a return), or a manual button click. |
| HITL (Human-in-the-Loop) | A safety feature where an agent pauses and waits for a human to review and approve an action before it proceeds. |
| Connector | A link between ICS and an external commerce platform (Shopify, Salesforce, Equinox). Connectors let agents read and update data in those systems. |
| Domain verb | A standard action an agent can perform (e.g., product.update, order.read). Domain verbs are platform-agnostic — an agent doesn’t need to know whether it’s talking to Shopify or Salesforce. |
| Knowledge base | A repository of your organisation’s documents (policies, SOPs, architecture docs) that has been processed and made searchable for agents and users. |
| Organisation (Org) | A company or enterprise account on ICS. Each org has its own users, data, and settings, completely isolated from other orgs. |
| Tenant | A business unit or store within an organisation. A large retailer might have one tenant per brand or region. |
| Instance Admin | A platform-level administrator (Infosys/EQPLAT operator) who manages all organisations on the platform. |
| Org Admin | An administrator for a single organisation — manages tenants, users, and org-wide settings. |
| Tenant Admin | An administrator for a single tenant — connects commerce systems, creates agents, manages team access. |
| Business User | A day-to-day user within a tenant — uses agents, views dashboards, and acts on HITL approvals. |
| Role | A set of permissions assigned to a user that controls what they can see and do in ICS. |
| Domain tag | A label on a role (e.g., product, order, pricing) that restricts which business areas a user can access. |
| OOB (Out-of-the-Box) | Pre-built agents, models, or connectors published by the platform team and available to all organisations. |
| Playground | A testing area where you can run an agent or model interactively with real data, before making it live. |
| Run | A single execution of an agent or workflow. Each run has a lifecycle: pending → running → succeeded / failed / interrupted. |
| Version | A saved, frozen snapshot of an agent’s or workflow’s configuration. Once published, a version cannot be changed — you open a new version to make updates. |
| LLM (Large Language Model) | The AI model that powers agent responses and knowledge extraction (e.g., Claude Sonnet 5). |
| SLM (Small Language Model) | A smaller, fine-tuned model trained on your specific domain data for faster, more targeted responses. |
| Audit log | A tamper-proof record of every significant action on the platform — who did what, when. |
3. User Roles & Access Levels
ICS has four user tiers. Each tier includes all the capabilities of the tier below it.
│
└── Org Admin ▶ manages one organisation and all its tenants
│
└── Tenant Admin ▶ manages one or more tenants within the org
│
└── Business User ▶ works within one tenant, in specific business areas
| Capability | Instance Admin | Org Admin | Tenant Admin | Business User |
|---|---|---|---|---|
| Provision a new organisation | ✅ | — | — | — |
| Provision a new tenant | ✅ | ✅ | — | — |
| Invite users | ✅ | ✅ | ✅ (tenant) | — |
| Manage roles & permissions | ✅ | ✅ | ✅ (tenant) | — |
| Publish OOB agents/models to catalog | ✅ | — | — | — |
| Create & publish agents | ✅ | ✅ | ✅ | — |
| Run / chat with agents | ✅ | ✅ | ✅ | ✅ (permitted domains) |
| Approve HITL decisions | ✅ | ✅ | ✅ | ✅ (if subscribed) |
| Add / configure connectors | ✅ | ✅ | ✅ | — |
| Upload knowledge documents | ✅ | ✅ | ✅ | — |
| Review knowledge extractions | ✅ | ✅ | ✅ | — |
| Create prediction projects | ✅ | ✅ | ✅ | — |
| View cost dashboard | ✅ | ✅ | ✅ | — |
| View audit trail | ✅ | ✅ | ✅ (own tenant) | — |
4. Platform Pillars
4.1 Organisation & Tenant Management
The foundation of the platform. It controls how companies, business units, and users are set up, structured, and isolated from each other. Everything else on ICS depends on having an organisation and tenant correctly provisioned.
4.1.1 Creating an Organisation
Set up a new company account on ICS, completely isolated from all other companies.
- You must be an Instance Admin
- First org admin’s email address and display name must be available
- The organisation name (identifier) must be decided
- The platform creates a dedicated identity pool for the organisation
- Reserved admin roles (
org-admin,tenant-admin) are automatically created - The first org admin is invited and granted full org-admin access
- The org admin receives an email and sets their password on first login
4.1.2 Creating a Tenant
Create a business unit or store within an organisation — e.g., a specific brand, region, or channel. Each tenant has its own agents, connectors, knowledge bases, and users.
- You must be an Org Admin
- The organisation must already be provisioned
- First tenant admin’s email address (optional — can add one later)
- Go to Organisation → Tenants → Create Tenant
- A dedicated data partition is created for the tenant (all data is isolated)
- If a first admin email is supplied, that person is invited and granted tenant-admin access
- An AI cost allocation (virtual key) is automatically created so the tenant’s AI spend is tracked separately
4.1.3 Inviting a User
Add a team member to an organisation or tenant with an appropriate role.
- You must be an Org Admin (any user) or Tenant Admin (tenant-scoped users only)
- The role you want to assign must already exist (see section 4.7)
- The user’s email address must be known and unique within the organisation
- Go to Organisation → Users → Invite User
- Enter the user’s email address and display name
- Select the role(s) and scope (org-wide or specific tenant)
- The user receives an invitation email and sets their own password on first login
4.1.4 Offboarding a User or Tenant
Remove access for a departing team member or decommission a tenant that is no longer needed.
- You must be an Org Admin
- For tenant offboarding: all active agent runs should be stopped first
- Data export must be completed before hard deletion (GDPR compliance)
4.2 Commerce Agent Studio
Where business teams build, test, and run AI agents that automate commerce operations — customer service, return processing, pricing updates, inventory responses — all within guardrails you define. Agents are chat-driven: you interact with them through conversation, and they use their configured tools and knowledge to respond and act.
4.2.1 Creating an Agent
Build a new AI agent tailored to a specific commerce task, with its own instructions, tools, knowledge sources, and access to your connected platforms.
- You must be a Tenant Admin or have agent creation permission
- The organisation and tenant must be provisioned (section 4.1)
- An AI model must be available (default: Claude Sonnet 5 — configured by the platform team)
- If the agent reads/writes commerce data: a Connector must be set up (section 4.6)
- If the agent answers questions from documents: a Knowledge base must have approved content (section 4.3)
- If the agent produces predictions: the relevant Prediction model must be deployed (section 4.4)
- Go to Agent Studio → Mine → Create Agent
- Enter a name and description for the agent
- Choose the AI model (the default is recommended for most cases)
- Write the agent’s system prompt — its standing instructions, personality, rules, and scope
- Select the business areas the agent can access (e.g.,
customer,order,product) - Optionally enable the Knowledge Base for document-grounded responses
- Configure the approval gate if human sign-off is required before sensitive actions
- Save — the agent is now a draft. Test it in the Playground before publishing.
4.2.2 Testing an Agent (Playground)
Run the agent interactively with real data before making it live, to validate its behaviour and connector access.
- Agent draft must be saved with a valid definition
- If the agent uses connectors: the connector must be active and credentials valid
- You must be the agent’s author or a Tenant/Org Admin
4.2.3 Publishing an Agent
Freeze the agent’s current configuration as an immutable, live version that others can use.
- Agent must be in draft state with a valid saved definition
- You must have agent publish permission
- A changelog (description of what changed) must be written — the platform requires it
4.2.4 Scheduling an Agent
Run an agent automatically on a recurring schedule — e.g., every morning at 8 AM to check overnight orders.
- The agent must be published (at least v1 exists)
- You must have agent execution permission
- A valid cron schedule and timezone must be provided (minimum interval: 60 seconds)
- If the agent uses connectors: credentials must be active
- Go to the agent detail page → Triggers → Add Trigger → Schedule
- Enter a name, the cron schedule, and timezone
- Optionally enter a starting message (the first thing the agent will “read” when it runs)
- Save — the agent will start automatically on the next cron occurrence
4.2.5 Connecting an Agent to a Commerce Event
Run an agent automatically when something happens in your connected commerce platform — e.g., a customer submits a return request.
- The agent must be published
- A Connector must be set up and the marketplace app registered (section 4.6.2)
- The event name must be known (e.g.,
orderservice/return/requested) - You must have agent execution permission
4.2.6 Approving a Human-in-the-Loop (HITL) Decision
Review and approve (or reject) an action the agent has proposed but cannot execute without human sign-off.
- A run must be in the “Awaiting approval” state
- You must be a subscribed user, the agent’s owner, or a Tenant/Org Admin
- You receive a notification that an agent run is awaiting your decision
- Go to Agent Studio → Runs and open the waiting run
- Review the agent’s proposal (e.g., “I would like to issue a $349 refund — reason: damaged item”)
- Click Approve or Reject
- The agent resumes (approved) or closes cleanly (rejected)
4.2.7 Cloning an OOB Agent
Take a pre-built agent from the platform catalog and create your own customised copy for your tenant.
- The OOB agent must be published and available to your org
- You must have agent creation permission
4.3 Knowledge
Lets you ingest your organisation’s documents, policies, and architecture content into a searchable knowledge base. Once approved, agents can retrieve content when answering questions or making decisions, and users can query it directly through chat.
4.3.1 Creating a Knowledge Base (Institutional Brain)
Build a searchable knowledge base from your organisation’s internal documents — policies, procedures, meeting decisions, operational guides.
- You must be a Tenant Admin or have knowledge write permission
- The org and tenant must be provisioned
- Documents must be in a supported format: PDF, Word (.docx), or PowerPoint (.pptx)
- Documents should be relevant, accurate, and approved for internal AI use before uploading
- Go to Knowledge → Institutional Brain → Upload
- Upload your document(s)
- The platform extracts entities and key statements using AI automatically
- The extracted content appears in the Review Inbox
- A knowledge admin reviews, corrects if needed, and approves the batch
- Approved content is published to the knowledge graph and is now queryable
- Agents and users can now ask questions answered from this content
4.3.2 Adding Architecture or API Documentation (Enterprise Architect)
Build a searchable knowledge base from architecture diagrams, system documentation, API specifications, and OpenAPI specs.
- Same as Institutional Brain (section 4.3.1)
- Supported formats: PDF, Word, YAML, JSON, OpenAPI specs (.json/.yaml), architecture images (PNG, JPG)
4.3.3 Training a Domain Expert Model
Create a commerce-specialised AI model (Small Language Model) fine-tuned on your own domain documents, for faster and more targeted responses on specific topics like pricing, marketplace operations, or retail strategy.
- You must be a Tenant Admin or have knowledge write permission
- Source documents must be uploaded (PDF, Word)
- Sufficient source material is needed — the more relevant content, the better the model
- Compute resources must be available — contact the Instance Admin if unsure
- Go to Knowledge → Domain Expert → Specialisations → Create Specialisation
- Name the specialisation and describe its scope (e.g., “Commerce Operations — pricing and promotions”)
- Upload the source documents
- Click Generate Training Data — the platform creates question-and-answer pairs automatically
- Click Train — a model training job is launched (30–60 minutes typical)
- Once training is complete, click Bundle then Deploy
- The Domain Expert model is now live for agent conversations and direct chat
4.3.4 Querying the Knowledge Base
Ask natural language questions and get answers grounded in your approved documents.
- At least one capability must have approved content
- You must have knowledge read permission
4.4 Prediction
Provides AI-powered forecasting and recommendation models for commerce use cases — predicting customer churn, demand for a product, the likelihood a customer will buy again, and more. Use pre-built models immediately or train custom models on your own data.
4.4.1 Using an Out-of-the-Box Prediction Model
Deploy a pre-built commerce AI model against your own data without building from scratch.
- You must be an Org Admin or Tenant Admin
- The OOB model catalog must be available (provisioned by Instance Admin)
- A data source must be connected with relevant historical data (section 4.4.3)
- Sufficient compute quota must be available
Available OOB Models:
4.4.2 Building a Custom Prediction Model
Build a prediction model from scratch for a use case not covered by OOB models.
- You must be an Org Admin or Tenant Admin
- A labelled dataset must be available and connected as a data source
- You must know the problem type: classification, regression, or time series
- Sufficient historical data is needed (consult Instance Admin for guidance)
Project Lifecycle:
4.4.3 Connecting a Data Source
Link your commerce data to the Prediction platform so models can be trained on your real data.
- You must be an Org Admin or Tenant Admin
- Connection details for the data source (host, credentials, database/table name)
- The data source must be accessible from the platform’s cloud environment
- The data must contain historical records relevant to the prediction use case
4.5 Language
Manages the AI language models available on the platform — both large general-purpose models (like Claude Sonnet 5) and smaller domain-specific models (Domain Expert SLMs) trained on your commerce content. Provides a catalog, a playground for testing, and cost tracking for language model usage.
4.5.1 Browsing the Language Model Catalog
See which AI language models are available on the platform for use in agents and knowledge queries.
- You must be logged in as any admin tier
- Models are provisioned by the Instance Admin
4.5.2 Testing a Model (Language Playground)
Interact with a language model directly to test its responses before using it in an agent.
- The model must be available in the catalog
- You must be an Org Admin or Tenant Admin
4.6 Connectors
The integration layer between ICS and your commerce platforms. Lets agents read and update data in Shopify, Salesforce, or Equinox — without the agent ever seeing API details or credentials. When an agent issues a standard command (order.read, pricing.update), the connector translates it into the correct API call and injects credentials automatically.
Supported Platforms (V1)
Read and update products, pricing, inventory, and collections. Customers and orders support coming.
Read, create, update, and delete products, customers, orders, and pricing. Requires two connections for full CRUD.
Connect to Equinox cloud admin and subscribe to marketplace events for event-driven automation.
Register your own MCP server or REST/GraphQL API as a connector through a self-service flow.
4.6.1 Adding a Connector (Creating a Connection)
Link your Shopify, Salesforce, or Equinox account to your ICS tenant so agents can act on your behalf.
- You must be a Tenant Admin
- The connector type must be registered on the platform by the Instance Admin
- You must have the platform credentials:
- Shopify: Custom App Admin API access token with appropriate scopes
- Salesforce: Connected App Consumer Key & Secret, plus your org’s domain URL
- Equinox: OAuth client ID and client secret for the Equinox cloud admin
- Credentials must have the necessary permissions on the external platform
- Go to Connectors → Add Connection
- Select the platform (e.g., Shopify)
- Enter your credentials — they are stored securely in the platform’s Vault and are never visible again
- Click Test Connection to verify the credentials work
- Go to Connectors → Routing and map which business domains route through this connection
- Agents in your tenant can now use this connection
4.6.2 Subscribing to Commerce Events (Equinox only)
Automatically trigger an agent whenever a specific event happens in Equinox — e.g., a customer submits a return request or a product is updated.
- An Equinox connection must already be created and active (section 4.6.1)
- You must know the specific event name (e.g.,
orderservice/return/requested) - An agent must be published and ready to handle the event (section 4.2.5)
- You must be a Tenant Admin
4.6.3 Dry-Running a Connector Action
Test what an agent would do with a connector action without actually making any changes in your commerce platform.
pricing.update) are stubbed — the agent goes through all the steps but no actual change is made. Read-only actions (like product.read) execute for real so you see actual data.4.7 Access Control (RBAC)
Ensures that each person on ICS can only see and do what is appropriate for their role. Prevents unauthorised access, enforces business boundaries, and makes it easy to grant or revoke access as teams change.
4.7.1 Creating a Role
Define a new set of permissions for a category of user — e.g., a “Merchandiser” who can only work with products and pricing.
- You must be an Org Admin
- Decide which business domains this role grants access to (e.g.,
product,order,pricing,inventory,customer)
- Go to Organisation → Roles → Create Role
- Enter a name and description
- Select the business domains this role grants access to
- Save — the role is now available to assign to users in any tenant within the org
org-admin, tenant-admin) are automatically created when an org or tenant is provisioned — you do not create these manually. You only create roles for business users.4.7.2 Assigning a Role to a User
Grant a user access to specific business areas within a tenant.
- The role must already exist (section 4.7.1)
- The user must already be invited (section 4.1.3)
- You must be an Org Admin (any role) or Tenant Admin (tenant-scoped roles only)
4.7.3 Understanding Domain-Based Access
| User type | Can access |
|---|---|
Business User with product tag | Products only — cannot perform order or pricing operations |
Business User with product + order tags | Products and orders |
| Tenant Admin | All domains in their tenant — bypasses domain restrictions |
| Org Admin | All domains in all tenants in their org |
| Instance Admin | All domains across all orgs |
4.8 Cost Dashboard
Gives organisation and instance admins visibility into how much AI spend is being consumed — broken down by tenant, capability, model, and project. Lets org admins set monthly budget limits and alerts so costs stay within expected ranges.
4.8.1 Viewing AI Token Costs
Understand how much your organisation is spending on AI model calls for agents, knowledge queries, and other language model usage.
- You must be an Org Admin or Instance Admin
- The platform tracks costs automatically — no setup required
4.8.2 Setting a Budget
Set a monthly spending limit for your organisation’s prediction compute. The platform will alert you when you approach the limit.
- You must be an Org Admin
- Go to Prediction → Cost Analysis → Budget → Set Budget
- Enter the monthly budget amount
- Set an alert threshold (e.g., alert at 80% of budget)
- Save — you will be notified when spend approaches the threshold
4.8.3 Managing Idle Endpoints
Reclaim compute resources that are running but not being used, to reduce unnecessary costs.
- You must be an Org Admin
- At least one prediction model must be deployed
4.9 Audit
Provides a tamper-proof record of every significant action taken on the platform — answering “Who did what, and when?” for compliance, security reviews, and operational troubleshooting. The audit log cannot be altered retroactively — any tampering would be immediately detectable.
4.9.1 Viewing the Audit Trail
- You must be a Tenant Admin, Org Admin, or Instance Admin
| Category | What is logged |
|---|---|
| User management | User invited, password set, role granted, role revoked |
| Agent Studio | Agent created, published, deleted; run started, completed, cancelled; HITL approved or rejected; connector action invoked |
| Knowledge | Document uploaded, batch approved, content published, specialisation trained |
| Prediction | Model trained, model deployed, budget set, idle endpoint reclaimed |
| Organisation | Tenant provisioned, org provisioned, user offboarded |
5. End-to-End Scenarios
Scenario 1: Onboarding a New Retail Brand (Tenant)
Goal: Set up a new tenant for a retail brand, connect it to Shopify, and deploy a customer service agent.
| # | Who | What happens |
|---|---|---|
| 1 | Instance Admin | Provisions the organisation (if not already done) |
| 2 | Org Admin | Provisions a new tenant for the brand |
| 3 | Org Admin | Invites the brand’s team lead as Tenant Admin |
| 4 | Tenant Admin | Creates a Shopify connection (enters API token, tests connection, maps domains) |
| 5 | Tenant Admin | Uploads the return policy PDF to the Institutional Brain |
| 6 | Tenant Admin | Reviews and approves the extracted content |
| 7 | Tenant Admin | Creates a Customer Service Agent (selects model, writes prompt, enables customer + order domains, enables Knowledge Base, sets HITL approval for refunds > $200) |
| 8 | Tenant Admin | Tests the agent in the Playground with a sample return request |
| 9 | Tenant Admin | Publishes v1 of the agent |
| 10 | Tenant Admin | Arms an event trigger for orderservice/return/requested |
| 11 | Business User | The agent runs automatically when customers submit returns; high-value refunds pause for supervisor approval |
Scenario 2: Deploying a Demand Forecast Model
Goal: Deploy a SKU-level demand forecasting model on existing sales data.
| # | Who | What happens |
|---|---|---|
| 1 | Tenant Admin | Connects the sales data warehouse as a data source |
| 2 | Tenant Admin | Creates a Prediction project (type: Catalog Activation, model: SKU-Level Demand Forecaster) |
| 3 | Tenant Admin | Maps data fields (product ID, date, units sold, store) to the model’s inputs |
| 4 | Platform | Profiles the data, engineers features, and trains the model |
| 5 | Tenant Admin | Reviews accuracy metrics and selects the trained model as champion |
| 6 | Tenant Admin | Deploys the model — it is now available |
| 7 | Tenant Admin | Sets a budget alert at 80% of the monthly compute budget |
| 8 | Business Analyst | Uses the model for weekly demand planning reports or invokes it through an agent |
Scenario 3: Granting a Merchandiser Product-Only Access
Goal: Invite a new merchandiser who should only be able to work with products — not orders, pricing, or customer data.
| # | Who | What happens |
|---|---|---|
| 1 | Org Admin | Creates a “Merchandiser” role with domain tag: product |
| 2 | Org Admin | Invites the merchandiser’s email with the Merchandiser role assigned to the relevant tenant |
| 3 | Merchandiser | Receives invitation, sets password, logs in |
| 4 | Merchandiser | Can now chat with agents in the product domain; cannot see order or pricing agents |
6. Assumptions & Open Questions
| # | Area | Assumption or Gap | Impact |
|---|---|---|---|
| 1 | Language / SLM | The Language zone shows a model catalog and playground. The backend SLM Factory service was not fully accessible in the source repositories. | Language pillar description may be incomplete if SLM Factory has additional functionality. |
| 2 | Org Admin UI | An Org Admin frontend zone exists but its specific screens were not fully explored. Capabilities described here are based on the backend API and RBAC documentation. | Some Org Admin screens may have additional features not captured here. |
| 3 | Shopify — customers & orders | Shopify connector supports products, pricing, inventory, and collections in V1. Customer and order support is noted as “in progress” in the source repositories. | Agents using the customer or order domains with a Shopify connection will fail until this support is added. |
| 4 | Salesforce — two connections for full CRUD | Full create/read/update/delete on Salesforce requires two separate connections. This is a Salesforce platform constraint. | Tenant admins must create both connections if delete operations are needed. |
| 5 | Resource sharing between tenants | The platform references a resource sharing/approval workflow for sharing agents between tenants. The detailed flow was not fully documented in the source repositories. | Cross-tenant sharing capabilities may exist but are not described in detail here. |
| 6 | Prediction — tenant-level cost view | The prediction cost dashboard is accessible to org admins. Whether tenant admins can see only their tenant’s costs (vs. the full org) requires confirmation. | Cost visibility for tenant admins in prediction may be different from what is described. |
| 7 | Scale and performance | No SLA, throughput, or capacity figures were found in the source repositories. None are stated in this document. | Any performance commitments must be agreed separately with the platform team. |
Revision History
2026-08-13 | JP – Created the page and added the content.