Agent-based decision support in commerce platforms for small and medium-sized firms: a conceptual framework

1Context and motivation

Small and medium-sized firms (SMEs) that sell online make the same kinds of decisions as large retailers: what to charge, how much stock to hold and where, which campaigns to fund, and which customer problems to fix first. They usually make them with fewer analysts, less tooling and less time. Survey evidence gathered by the OECD shows that the gap between SMEs and large firms is small for basic digital practices such as having a website or selling online, but widens as technologies become more sophisticated, and data analytics is one of the cases where it widens¹. The same report notes that SMEs often compensate for weak internal capability by sourcing functions from outside, and that digital platforms such as e-commerce marketplaces can supply business intelligence and data analytics services at low cost¹.

That second observation is the starting point of this paper. If a firm already runs its sales, catalogue, payments and customer messages through a hosted commerce platform, the data a decision needs is already in one system, and the platform is a natural place to offer decision support. Most platform analytics today is descriptive: dashboards and reports that say what happened. We ask what it would take for the platform to support the decision itself, and we propose a conceptual framework for doing so.

We call the framework agentic commerce intelligence. It is a platform-level architecture in which several software agents observe signals, reason within a scope, coordinate through a shared layer, and pass prioritised, explained recommendations to a person who keeps the decision. This paper argues the framework from literature. It does not report a system's effects, because we have not measured any.

2Background

2.1Bounded rationality and decision capacity

The classical model of the economic decision-maker assumes complete information and computation without limit. Simon proposed replacing it with a model of choice that fits the information and computational capacity a decision-maker actually has². The proposal fits the owner of a small online shop closely. Price, stock, campaign and service decisions interact, and the owner has neither the time nor the staff to trace every interaction. Under those limits, decisions are made on partial information and are revisited only when a problem becomes visible.

We use this framing to define what decision support is for in this setting. Its job is not to make the firm's choices for it. Its job is to widen the information and computation available at the moment of choice, so that fewer decisions are made on partial information.

2.2Data-driven decision-making and who adopts it

There is evidence that data-driven decision-making is associated with better firm performance, and also that its adoption is uneven. Using Census Bureau data on a large representative sample of US manufacturing plants, Brynjolfsson and McElheran found that the share of plants using data-driven decision-making nearly tripled, from 11% to 30%, between 2005 and 2010, and that plant size was among the key correlates of adoption³. A later Census survey of more than 30,000 US manufacturing establishments found higher productivity among plants that use predictive analytics, with instrumental-variable estimates and the timing of gains consistent with a causal effect; the gain appeared only where predictive analytics was combined with at least one complement: accumulated IT capital, educated workers, or production designed for high flow efficiency⁴.

Two cautions follow for our argument. Both studies concern manufacturing in the United States, not online retail, and neither studies SMEs specifically. And the second study's central finding is that analytics alone does not pay; complements do the work. A platform cannot supply educated workers. It can, however, supply part of the IT capital and part of the process design, which is the gap the framework addresses.

2.3Decision support systems

Decision support systems (DSS) are a long-established field. Arnott and Pervan trace its evolution through personal DSS, group support, negotiation support, intelligent DSS, knowledge-management DSS, executive information systems and business intelligence, and data warehousing, and analyse the state of published DSS research⁵. The framework we propose sits in this lineage: it is an intelligent DSS whose data store is the commerce platform and whose users are small teams rather than analysts.

Davenport argues that the business value of AI is mostly practical rather than spectacular: better-informed decisions and more efficient processes, with machines working alongside people rather than replacing them⁶. We adopt that stance as a design constraint, not as evidence that the framework works.

A further limit of descriptive analytics is causal. A dashboard shows associations, and a decision needs to know what would happen under an action. Identifying the effect of an action from observational data requires assumptions about the causal structure that the data alone cannot confirm⁷. Where an action can be randomised, a controlled experiment estimates its effect directly⁸. A decision-support system that recommends actions therefore has to be explicit about which of its claims are causal and on what basis.

2.4Agents and multi-agent systems

In the agent literature, an agent is a computer system situated in an environment that acts with some autonomy, responds to changes in that environment, pursues goals on its own initiative and interacts with other agents⁹. Multi-agent systems study how several such agents coordinate, cooperate and resolve conflicts when no single agent has the whole picture or full control¹⁰. More recently, large language models have been used as the reasoning core of agents; a survey of this work proposes a common construction (profile, memory, planning and action modules) and records open problems in evaluation and reliability¹¹.

Commerce decisions decompose naturally by function, and the functions are coupled: a promotion moves demand, demand moves stock, stock moves delivery promises, and delivery promises move service contacts. That pattern, separable domains with coupled effects, is the one multi-agent systems were developed for.

3The framework

Agentic commerce intelligence has four layers.

3.1Observability layer

The observability layer collects signals from sales, inventory, customer behaviour, marketing and operations into one event record with shared definitions of the business objects (order, product, customer, campaign). On a hosted platform most of these signals are already produced as a side effect of running the shop, which is the practical reason for placing the framework inside the platform.

3.2Domain reasoning layer

Each domain (pricing, stock, marketing, service) has an agent that watches its signals, detects departures from expected behaviour, and forms hypotheses about their cause within its scope. An agent states the kind of each claim it makes: an observed change, a forecast, or a causal estimate, and for the last, the identifying assumption or the experiment behind it^{7, 8}.

3.3Coordination layer

Agents publish findings to a shared layer, where findings that concern the same products, customers or time window are linked, conflicts between recommendations are surfaced (for example a marketing agent proposing a promotion on a product the stock agent expects to run out), and items are ranked by their expected effect on the whole business rather than on one domain. Coordination and conflict resolution between agents with partial views is a core problem of multi-agent systems¹⁰.

3.4Human decision interface

The interface presents a short, ranked list of issues, each with its evidence, its expected effect, its uncertainty and the action proposed. The person accepts, edits, defers or rejects it, and that choice is recorded. Design guidance for human-AI interaction asks, among other things, that a system make clear what it can do and how well, show why it acted, support efficient correction and dismissal, and learn from user behaviour¹². We take those guidelines as requirements for this layer.

Table 1 summarises the layers, the decision problem each addresses, and the published work each rests on.

Layer or mechanism	Decision problem it addresses	Evidence
Platform-hosted analytics	SMEs lag in sophisticated analytics and source capabilities outside	1
Observability layer	Decisions made on partial information under limited capacity	2
Analytics plus complements, not analytics alone	Analytics pays only with supporting capital and process design	3, 4
Domain agents	Coupled functions that no single view covers	9, 11
Coordination layer	Conflicting recommendations across domains	10
Explicit causal status of each claim	Associations mistaken for effects of actions	7, 8
Graded automation per decision type	Choosing how much of a decision to automate	13
Explained, correctable recommendations	Misplaced trust or distrust in automated advice	14, 15, 12

Source: our design, with the works cited in the table.

4Decision latency

We use the term decision latency for the time from the moment a signal that matters appears in the data to the moment a decision responds to it. It has three parts: the time until someone notices, the time to understand what happened and why, and the time to choose and carry out a response. In a small firm the first two usually dominate, because nobody is watching most signals most of the time.

This is our framing, not a measured quantity. We know of no published estimate of decision latency in SME e-commerce, and we do not offer one. What the framework claims is narrower: if signals across domains are watched continuously and linked before a person sees them, the noticing and understanding parts of the delay should shrink. Whether they do, by how much, and whether shorter latency changes outcomes, are empirical questions (see the research agenda below).

5Human-in-the-loop design

The framework keeps a person responsible for decisions. The reason is not only caution. Parasuraman, Sheridan and Wickens distinguish four functions that can be automated (information acquisition, information analysis, decision and action selection, and action implementation), each on a continuum from fully manual to fully automatic, and note that automation changes human work and adds coordination demands rather than simply replacing it¹³. In those terms, the framework automates acquisition and analysis heavily, offers decision selection as a recommendation, and leaves implementation to the person except for actions the firm has explicitly delegated.

Trust is the second reason. People rely on automation appropriately only when their trust matches its actual capability, and trust guides reliance most when a system is too complex to understand fully¹⁴. Experiments by Dietvorst, Simmons and Massey show a further effect: people who see an algorithm make errors lose confidence in it faster than in a human making the same errors, and become less likely to use it even when it outperforms the human¹⁵. A decision-support system for small firms has to expect both failure modes, over-reliance and abandonment after a visible error. Showing evidence and uncertainty with each recommendation, and recording when and why a person overrides it, is the design response we propose.

6Propositions

The framework implies propositions that could be tested. We state them as hypotheses, not findings.

• P1. Where the framework is in use, the time from a material signal to a recorded decision is shorter than where the same firm relies on dashboards alone.
• P2. The share of recommendations that persons accept and do not later reverse rises as the system's stated uncertainty becomes better calibrated.
• P3. Recommendations from the coordination layer produce fewer cross-domain conflicts (for example promotions on products that then run out) than recommendations from domain agents alone.
• P4. Any effect on business outcomes is larger in firms that also have the complements identified for predictive analytics, such as staff time set aside to act on recommendations⁴.

7Research agenda

Testing these propositions requires measurement we have not done. Decision latency needs an operational definition and instrumentation: when a signal crossed a threshold, when the recommendation appeared, when a person acted. Effects on outcomes need controlled comparison, ideally randomised at the level of the firm or the recommendation, with pre-registered metrics and guardrails⁸. Trust and reliance need behavioural measures, such as override rates and their reasons, as well as surveys. The governance questions also need study: who is accountable when a delegated action goes wrong, and how a firm audits what its agents did.

8Limitations

• No measurements. We have built no evaluation of this framework and report no outcomes. Every benefit it suggests is a hypothesis.
• Evidence from other settings. The evidence on data-driven decision-making comes from US manufacturing plants^{3, 4}. Its transfer to small online retailers is an assumption.
• Agent reliability. Agents built on large language models have open problems in evaluation and reliability¹¹. A coordination layer can surface conflicts between agents; it does not make each agent's reasoning correct.
• Causal claims. Recommendations that rest on observational data inherit untestable assumptions⁷. Small firms often have too little traffic for experiments to detect small effects, so many recommendations will remain associational.
• Trust dynamics. Visible errors can lead users to abandon a system that is, on average, useful¹⁵. The framework does not show how quickly trust recovers, or how to design for that.
• Concentration and dependence. Placing decision support inside a platform makes the firm more dependent on that platform. We do not analyse that trade-off here.
• Scope. We consider single-firm decisions. Effects across many firms acting on similar recommendations, such as correlated pricing, are outside the framework.

9Conclusion

Small and medium-sized firms adopt sophisticated analytics less often than large firms, and many already rely on platforms for capabilities they cannot build¹. We have proposed a conceptual framework in which agents inside the commerce platform observe, reason within domains, coordinate across them, and hand explained recommendations to a person who keeps the decision. Each part rests on published work, summarised in Table 1. The framework's value depends on propositions we have stated but not tested; the next step is to instrument decision latency and reliance on one decision type and measure them.