Follow us on Facebook
Follow us on Facebook

Designing an Agentic AI Operations Layer for a Rural Marketplace

Turri public marketplace and internal Operations Dashboard shown as one connected platform

Turri’s Operations Dashboard brings product, producer, listing, image, and relationship data into one internal workspace for running a rural marketplace.

At its center is an LLM-powered chatbot that lets operators ask questions in natural language, query live operational data through validated tools, and receive streamed answers without leaving the dashboard.

Case Description

Context

Turri’s operational information spans products, producers, variants, listings, images, contacts, and conversations. Without a shared internal system, answering cross-domain questions requires navigating multiple tables and tools.
The dashboard combines a structured operations product with a conversational access layer. The chatbot uses an LLM to interpret requests, select from six read-only tools, query the MDM and CRM data domains, and stream concise Spanish responses while preserving human control over data changes.

Objectives

  1. Consolidate core marketplace operations in one workspace
  2. Make cross-domain data queryable in natural language
  3. Implement a bounded tool-using LLM agent
  4. Protect operational data with read-only access
  5. Keep model and runtime choices server-controlled
  6. Separate AI assistance from explicit write workflows

Process

    Steps: Operational and AI Problem Framing

    To make internal marketplace operations easier to understand and query, we mapped the data domains and the questions operators needed to answer:

    1. Identified products, producers, contacts, conversations, images, and aggregate statistics as the initial chatbot domains.
    2. Distinguished conversational read access from operational mutations.
    3. Defined the chatbot as an assistant embedded in the dashboard rather than a separate agent service.
    4. Set Spanish responses, concise answers, and real-data-only behavior as interaction constraints.

    Output

    • A bounded problem definition for conversational operational access
    • A read-only boundary for the first chatbot release
    • A system prompt that directs the assistant to use live data and avoid invention

    Steps: Dashboard and Data Architecture

    To connect the assistant to trustworthy operational data without bypassing the application boundary, we implemented the dashboard route, runtime registry, and server-side data access together:

    1. Routed authenticated chat requests through the Next.js application.
    2. Resolved a logical model role through the server-side runtime registry.
    3. Connected tools to the Supabase mdm and crm schemas.
    4. Validated tool inputs with Zod and bounded result sizes to control context and latency.
    5. Kept credentials, provider identifiers, and database access on the server.

    Output

    • A deployable dashboard-native AI integration
    • Explicit runtime and data-access boundaries
    • Validated, bounded tool contracts

    Steps: Agentic AI Chatbot

    To let the LLM answer multi-step operational questions rather than only generate text, we implemented a bounded tool-using agent loop:

    1. Converted the operator’s conversation into the model’s message format.
    2. Provided six read-only tools for products, producers, contacts, conversations, images, and statistics.
    3. Allowed the model to select a tool and receive its live result.
    4. Fed the result back into the interaction for follow-up reasoning when needed.
    5. Capped the loop at five server-controlled steps.
    6. Streamed the final Spanish response to the chat interface.

    Output

    • An implemented agentic AI interaction inside the Operations Dashboard
    • Natural-language access to live operational data
    • A bounded loop that cannot mutate records through the chatbot

    Steps: Operational Workflows and Generation

    To keep conversational assistance useful without turning it into an unsafe automation layer, we separated agentic querying from explicit dashboard workflows and typed generation features:

    1. Kept create, update, and delete actions in structured dashboard forms.
    2. Routed content-generation features through typed functions and approved runtime roles.
    3. Maintained separate workflows for descriptions, SEO, image prompts, image metadata, and enrichment.
    4. Directed write requests from the chatbot back to the relevant dashboard workflow.
    5. Preserved review and approval steps for generated content.

    Output

    • Clear separation between conversational retrieval and operational mutation
    • Structured generation workflows that remain independently testable
    • Human review as the control point for changes and published content

    Steps: Verification and Safeguards

    To make the AI feature credible for operational use, we verified its boundaries and documented what remains unknown:

    1. Checked the tool inventory and server-side execution path.
    2. Confirmed the five-step maximum is controlled by the server.
    3. Verified that the chatbot is read-only.
    4. Recorded safe error handling, model-role controls, and runtime safeguards.
    5. Kept quantitative operational outcomes explicitly unmeasured until source evidence is recovered.

    Output

    • An auditable agentic AI architecture record
    • A publication boundary that excludes sensitive operational data
    • A clear distinction between implementation evidence and outcome evidence
    Collage of the Turri Operations Dashboard overview, product management, and data assistant
    Sanitized overview of the Turri Operations Dashboard modules
    Sanitized example of a grounded catalog query in the Turri Operations Dashboard data assistant
    Sanitized product catalog management table in the Turri Operations Dashboard
    Sanitized overview of the Turri Operations Dashboard modules

Results

The most important design decision was to make the chatbot agentic but bounded. The LLM can choose how to retrieve information and use tool results as context, while server-side limits, read-only access, validation, and explicit workflows preserve operational control. This separation creates a practical path toward more advanced orchestration without presenting an unimplemented architecture as completed work.

Main TakeAway

  • Implemented an LLM-powered chatbot inside the Operations Dashboard.
  • Enabled natural-language queries across products, producers, contacts, conversations, images, and aggregate statistics.
  • Connected the LLM to six validated read-only tools with bounded execution.
  • Preserved explicit human control over mutations and content approval.
  • Established a foundation for future centralized orchestration.

No quantitative claims about time saved, adoption, data quality, revenue, or operational efficiency are included because they have not yet been verified.

  • Collage of the Turri Operations Dashboard overview, product management, and data assistant
  • Sanitized overview of the Turri Operations Dashboard modules
  • Sanitized product catalog management table in the Turri Operations Dashboard
  • Sanitized example of a grounded catalog query in the Turri Operations Dashboard data assistant