Agentic AI for eCommerce: What It Actually Means, Why It Matters, and How to Build It on Rails and Solidus

What "Agentic" Actually Means (In Plain English)

Let me start with an analogy that makes this click immediately.

A chatbot is like a waiter. It takes your order, delivers it to the kitchen, and brings back what you asked for. It doesn't decide what you should eat. It doesn't notice that the kitchen is running low on salmon and suggest the chicken instead. It just does exactly what you tell it, one interaction at a time.

An automation rule is like a timer on your oven. It turns off at 6pm every day regardless of whether anything is cooking. It follows a fixed rule with no awareness of context.

An AI agent is like a restaurant manager. It notices when inventory is running low and places orders with suppliers. It sees that table 5 has been waiting too long and reassigns a waiter. It spots that salmon isn't selling tonight and adjusts the specials board. It makes dozens of decisions throughout the evening, each one informed by what's actually happening, not just following a script.

The technical definition is that an agent operates in a perception/action loop:

1. Perceive: The agent observes its environment (new orders coming in, inventory levels changing, customer messages arriving, prices shifting)
2. Reason: It analyses what it's seeing against its goals and decides what to do
3. Act: It takes action (reorders stock, responds to a customer, reroutes an order, adjusts a price)
4. Observe: It checks the results of its action and feeds that back into its next decision

This loop runs continuously. The agent doesn't wait to be asked. It doesn't need a prompt. It's always watching, always deciding, always acting. That's what makes it agentic.

Contrast this with a traditional chatbot. A chatbot waits for input, processes it, returns output, and stops. No loop. No initiative. No autonomy. A chatbot is reactive. An agent is proactive.

Why This Matters for eCommerce Right Now

The numbers tell the story. McKinsey estimated in October 2025 that agentic commerce could generate between 3 and 5 trillion dollars globally by 2030. An IBM study from 2026 found that 45% of consumers already use AI for part of the buying journey. Gartner predicts that 40% of enterprise applications will embed AI agents by the end of 2026, up from less than 5% in 2025.

This isn't future speculation. This is happening right now. And the businesses that don't adapt will find themselves competing against businesses where AI agents handle the tedious operational work while humans focus on strategy and creative decision making.

Let me walk through the specific ecommerce applications where agentic AI is already delivering real value.

Agentic Inventory Management

Traditional inventory management is reactive. You check stock levels, notice something is running low, place a reorder, and hope it arrives in time. If you're sophisticated, you have reorder points set up, basically an "if stock falls below X, order Y" rule. But those rules are static. They don't account for seasonal demand spikes, marketing campaigns about to launch, competitor stockouts, or emerging trends.

An agentic inventory system works completely differently. It monitors stock levels in real time, analyses sales velocity, factors in upcoming promotions and seasonal patterns, watches supplier lead times, and makes autonomous restocking decisions.

Here's what that looks like architecturally in a Rails/Solidus application:

class InventoryAgent
  include AgentLoop

  def perceive
    {
      stock_levels: Spree::StockItem.includes(:variant).low_stock,
      sales_velocity: SalesVelocityService.calculate(period: 7.days),
      upcoming_promotions: Spree::Promotion.upcoming.with_products,
      supplier_lead_times: Supplier.active.pluck(:id, :avg_lead_days).to_h,
      pending_orders: Spree::StockItem.backordered_variants
    }
  end

  def reason(observations)
    observations[:stock_levels].map do |stock_item|
      variant = stock_item.variant
      velocity = observations[:sales_velocity][variant.id] || 0
      lead_time = observations[:supplier_lead_times][variant.supplier_id] || 7
      promo_boost = promotion_demand_multiplier(variant, observations[:upcoming_promotions])

      days_of_stock = velocity > 0 ? stock_item.count_on_hand / velocity : Float::INFINITY
      reorder_point = (velocity * lead_time * 1.3 * promo_boost).ceil

      if days_of_stock < lead_time * 1.5
        { action: :reorder, variant: variant,
          quantity: reorder_point, urgency: calculate_urgency(days_of_stock, lead_time) }
      end
    end.compact
  end

  def act(decisions)
    decisions.each do |decision|
      case decision[:urgency]
      when :critical
        PurchaseOrderService.create_and_send!(decision[:variant], decision[:quantity])
        notify_operations_team(decision)
      when :standard
        PurchaseOrderService.create_draft(decision[:variant], decision[:quantity])
      end
    end
  end
end

Notice the tiered autonomy here. For critical restocking (you're about to run out), the agent creates and sends the purchase order automatically, then notifies the team. For standard restocking, it creates a draft for human review. The agent has agency, but within clearly defined boundaries.

Agentic Customer Support

Most ecommerce "AI customer support" today is just a fancier chatbot. It understands natural language better than the old keyword matching bots, but it's still fundamentally reactive: customer asks question, bot provides answer.

An agentic customer support system is different. It monitors the entire customer journey and intervenes proactively.

Imagine a customer places an order. The agent monitors the fulfilment pipeline and notices the shipment is going to be delayed by two days because the warehouse is behind. Before the customer even notices, the agent sends a proactive message: "Hi, your order is being prepared but we expect delivery on Thursday rather than Tuesday. We've applied a 10% discount to your next order as an apology. Would you like us to upgrade to express shipping at no extra cost?"

The customer didn't complain. The customer didn't even know there was a problem. The agent perceived a situation, reasoned about the best response, and acted. That's agentic support.

In a Rails application, this might look like:

class CustomerExperienceAgent
  include AgentLoop

  DELAY_THRESHOLD = 1.day

  def perceive
    {
      delayed_shipments: Spree::Shipment
        .where(state: 'ready')
        .where('expected_delivery_at > ?', original_estimate_plus(DELAY_THRESHOLD)),
      open_tickets: SupportTicket.unresolved.order(created_at: :asc),
      sentiment_alerts: CustomerSentiment.where(score: ...(-0.5)),
      cart_abandonments: AbandonedCart.recent.with_high_value_items
    }
  end

  def reason(observations)
    actions = []

    observations[:delayed_shipments].each do |shipment|
      actions << {
        type: :proactive_delay_notification,
        order: shipment.order,
        delay_days: calculate_delay(shipment),
        compensation: determine_compensation(shipment.order)
      }
    end

    observations[:cart_abandonments].each do |cart|
      actions << {
        type: :recovery_outreach,
        cart: cart,
        incentive: calculate_recovery_incentive(cart)
      }
    end

    actions
  end

  def act(decisions)
    decisions.each do |decision|
      case decision[:type]
      when :proactive_delay_notification
        CustomerMailer.proactive_delay_notice(
          decision[:order], decision[:delay_days], decision[:compensation]
        ).deliver_later
        apply_compensation(decision[:order], decision[:compensation])
        AuditLog.record(agent: self.class.name, action: decision[:type], details: decision)
      when :recovery_outreach
        CartRecoveryMailer.personalised_recovery(
          decision[:cart], decision[:incentive]
        ).deliver_later
      end
    end
  end
end

Agentic Order Routing

If you sell across multiple channels, manage multiple warehouses, or work with drop shipping suppliers, order routing is one of the most impactful places to deploy agentic AI.

Traditional order routing uses fixed rules: orders from Region A go to Warehouse A, orders from Region B go to Warehouse B. But what happens when Warehouse A is overwhelmed? Or when the item is out of stock there but available at Warehouse C? Or when a supplier can fulfil faster and cheaper than your own warehouse for this particular order?

An agentic routing system evaluates every order against the current state of the entire fulfilment network: stock availability across all locations, current processing capacity and queue depth at each warehouse, shipping costs and delivery times for each route, supplier availability and pricing for drop ship options, and customer delivery preferences.

For a Solidus store, you'd build this as a custom stock allocator:

class AgenticStockAllocator
  def allocate(order)
    available_sources = find_all_sources(order)

    scored_options = available_sources.map do |source|
      {
        source: source,
        score: calculate_score(source, order),
        estimated_delivery: estimate_delivery(source, order.ship_address),
        cost: estimate_fulfilment_cost(source, order)
      }
    end

    best_option = scored_options.max_by { |o| o[:score] }

    if best_option[:cost] > cost_threshold(order)
      escalate_to_operations(order, scored_options)
    else
      assign_fulfilment(order, best_option[:source])
      AuditLog.record(
        agent: 'OrderRouting',
        decision: best_option,
        alternatives_considered: scored_options.size
      )
    end
  end

  private

  def calculate_score(source, order)
    weights = { speed: 0.3, cost: 0.3, reliability: 0.2, capacity: 0.2 }
    speed_score = score_delivery_speed(source, order)
    cost_score = score_fulfilment_cost(source, order)
    reliability_score = source.fulfilment_reliability_rating
    capacity_score = source.current_capacity_ratio

    weights.sum { |factor, weight| send("#{factor}_score".to_sym) * weight rescue binding.local_variable_get("#{factor}_score") * weight }
  end
end

Agentic Dynamic Pricing

Dynamic pricing is where agentic AI gets particularly powerful, and particularly dangerous if you don't build in proper guardrails.

An agentic pricing system monitors competitor prices, demand patterns, inventory levels, margin targets, and seasonal factors, then adjusts your prices in real time to optimise for your business goals, whether that's revenue maximisation, margin protection, or market share growth.

But here's where the guardrails matter. Without boundaries, a pricing agent could theoretically enter a race to the bottom with a competitor's pricing agent, destroying margins for both businesses. Or it could spike prices during a demand surge in a way that damages customer trust. This is exactly the kind of multi-agent conflict I've been working through with GrowCentric.ai, where competing clients using the same optimisation algorithms can create destructive bidding wars.

The solution is clear boundaries:

class PricingAgent
  GUARDRAILS = {
    min_margin_percentage: 15.0,
    max_price_change_per_day: 10.0,  # percentage
    max_above_rrp: 5.0,              # percentage above recommended retail
    min_price_floor: :cost_plus_shipping,
    require_approval_above: 20.0     # percentage change needs human approval
  }.freeze

  def propose_price(variant)
    current = variant.price
    optimal = calculate_optimal_price(variant)

    # Apply guardrails
    constrained = apply_guardrails(variant, optimal)

    change_pct = ((constrained - current) / current * 100).abs

    if change_pct > GUARDRAILS[:require_approval_above]
      PricingApprovalQueue.enqueue(variant: variant,
        proposed: constrained, current: current, reasoning: @reasoning)
    else
      update_price(variant, constrained)
    end
  end
end

The agent proposes prices. The guardrails constrain them. Large changes require human approval. Every decision is logged with reasoning. This is agentic AI done responsibly.

How This Maps to Rails and Solidus Architecture

If you're already building on Ruby on Rails and Solidus, you're in a surprisingly good position to implement agentic patterns. Here's why.

Event driven architecture. Rails has ActiveSupport::Notifications built in, and Solidus fires events throughout the order lifecycle. These events are the perception layer for your agents. When an order is placed, when a payment is captured, when a shipment is delayed, your agents can subscribe to these events and react.

# Subscribe agents to Solidus events
ActiveSupport::Notifications.subscribe('order_completed') do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  OrderRoutingAgent.new.process(event.payload[:order])
end

ActiveSupport::Notifications.subscribe('shipment_shipped') do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  CustomerExperienceAgent.new.track_delivery(event.payload[:shipment])
end

Background job infrastructure. Agents need to run continuously or on schedules without blocking the main application. Rails has excellent background job support through Sidekiq, Solid Queue (new in Rails 8), or GoodJob. Your agent loops become recurring jobs.

class InventoryAgentJob < ApplicationJob
  queue_as :agents

  def perform
    agent = InventoryAgent.new
    observations = agent.perceive
    decisions = agent.reason(observations)
    agent.act(decisions)
  ensure
    # Re-enqueue for continuous operation
    self.class.set(wait: 15.minutes).perform_later
  end
end

Solidus's open architecture. Unlike closed platforms (Shopify, BigCommerce), Solidus gives you full access to every model, every service, and every workflow. You can override the stock allocator, extend the order state machine, add custom promotion rules, and hook into any part of the checkout flow. This openness is essential for agentic systems that need to interact deeply with the commerce engine.

API readiness. Solidus ships with a comprehensive API (and the newer solidus_api provides both REST and GraphQL endpoints). This matters because agentic systems are increasingly multi-service architectures where specialised agents communicate via APIs. Your Rails/Solidus application becomes one node in a larger agentic network.

Building Agentic Systems into a SaaS: The GrowCentric.ai Approach

The work I'm doing with GrowCentric.ai (launching publicly in June 2026) is directly informed by these agentic patterns. GrowCentric is a SaaS platform that uses machine learning to automatically optimise ecommerce marketing campaigns. At its core, it's a multi-agent system.

The platform uses specialised agents for different functions:

The Analytics Agent continuously monitors campaign performance, detects anomalies, identifies trends, and surfaces insights. It doesn't wait for a weekly report. It watches in real time and alerts when something needs attention.

The Budget Allocation Agent distributes marketing spend across campaigns based on performance signals. It shifts budget from underperforming campaigns to high performers, respects daily and monthly spending limits, and accounts for diminishing returns at scale.

The Audience Agent analyses customer behaviour patterns and builds audience segments for targeting. It identifies high value customer clusters, detects lookalike patterns, and recommends new targeting strategies.

The Conflict Resolution Agent addresses the multi-agent conflict problem I've written about before, where competing ecommerce shops using the same optimisation algorithms can create destructive bidding wars. It detects when clients are competing for the same audiences, implements intelligent segmentation to reduce overlap, and uses game theory concepts to find equilibrium states that benefit all parties.

All of these agents are built on Rails, using the same event driven, background job, API first patterns I've described above. The key architectural decision was designing each agent as a standalone service with clear inputs, outputs, and boundaries. They coordinate through a shared event bus (using ActiveSupport::Notifications in the monolith and message queues for the distributed components), and every decision is logged for auditability.

The Honest Limitations (And Why Guardrails Matter)

I'd be doing you a disservice if I didn't talk about what can go wrong. Agentic AI is powerful, but it's also new, and the failure modes are real.

Cascading errors. When an agent makes a bad decision, the consequences can propagate quickly. An inventory agent that misreads a demand signal could over-order stock. A pricing agent that misinterprets competitor activity could tank your margins. Unlike a human mistake that gets caught in a review, an agent acting autonomously can execute hundreds of bad decisions before anyone notices.

The solution: tiered autonomy. Low risk, reversible decisions (sending a cart recovery email) can be fully automated. Medium risk decisions (adjusting a price within guardrails) can be automated with monitoring and alerts. High risk decisions (placing a large purchase order, changing pricing strategy) require human approval.

Lack of common sense. AI agents can optimise within their parameters but they don't have the contextual understanding that humans do. An agent might suggest a promotion on a product that's been recalled. Or it might route orders to a warehouse in a region experiencing a natural disaster. Or it might send a cheerful upsell email to a customer who just filed a complaint.

The solution: context enrichment and blocklist mechanisms. Feed your agents the broader business context, not just the data they need for their immediate task. And build explicit blocklists for situations where automated action is inappropriate.

Over-reliance and skill atrophy. If agents handle everything, your team loses the skills and knowledge needed to run the business when the AI is unavailable. And AI will be unavailable sometimes, whether due to API outages, model degradation, or edge cases the agent can't handle.

The solution: graceful degradation. Every agentic system should have a manual fallback. If the inventory agent goes down, reorder points kick in. If the pricing agent fails, prices freeze at current levels. If the routing agent crashes, orders go to the default warehouse. Design for failure.

Regulatory considerations. As I covered in my posts on the Cyber Resilience Act and NIS2 Directive, European businesses face increasing obligations around cybersecurity, data protection, and algorithmic transparency. An agentic system that makes autonomous decisions about pricing, customer communications, or data processing needs to be auditable, explainable, and compliant.

The solution: comprehensive audit logging (every agent decision, every input, every output), human override capabilities, and clear documentation of how agents make decisions.

Getting Started: A Practical Roadmap

If you're running an ecommerce business on Rails and Solidus and you want to start building agentic capabilities, here's the path I'd recommend.

Start with observation, not action. Build an agent that monitors and alerts but doesn't take action yet. Let it observe your inventory levels, your order fulfilment times, your customer sentiment. See what it notices. Build trust in its perception before giving it the ability to act.

Pick one low risk, high impact area. Cart recovery is a great starting point. The downside of a bad cart recovery email is minimal. The upside of recovering even 5% of abandoned carts is significant. Build an agent that monitors cart abandonments, analyses the customer's browsing history and purchase patterns, and sends personalised recovery communications with tailored incentives.

Implement tiered autonomy from day one. Don't build an agent that does everything autonomously and then try to add guardrails later. Start with the guardrails. Define what the agent can do on its own, what requires monitoring, and what requires human approval. Make these boundaries configurable, not hardcoded.

Log everything. Every perception, every reasoning step, every action, every outcome. You'll need this for debugging, for compliance, and for improving the agents over time. In Rails, this is straightforward:

class AgentAuditLog < ApplicationRecord
  belongs_to :agentable, polymorphic: true, optional: true

  validates :agent_name, :action_type, :decision_payload, presence: true

  scope :recent, -> { where('created_at > ?', 24.hours.ago) }
  scope :by_agent, ->(name) { where(agent_name: name) }
  scope :escalated, -> { where(escalated: true) }
end

Measure impact ruthlessly. Before deploying an agent, define how you'll measure its success. Revenue impact, cost savings, customer satisfaction, operational efficiency. If an agent can't demonstrate measurable value within a reasonable timeframe, turn it off and redirect the effort.

The shift from traditional ecommerce to agentic commerce isn't going to happen overnight. But it is happening. The businesses that start building these capabilities now, even in simple forms, will have a significant head start when autonomous commerce becomes the expectation rather than the exception.

And if you need help building agentic systems into your Rails and Solidus ecommerce platform, or if you want to see how GrowCentric.ai's multi-agent approach can optimise your marketing operations, that's exactly what I do. Let's talk.