README.md

metadata

title: Commerce Ops Agent
emoji: 📈
colorFrom: yellow
colorTo: indigo
sdk: gradio
sdk_version: 6.20.0
python_version: '3.13'
app_file: app.py
pinned: false
short_description: Guarded operation planning for e-commerce stores
models:
  - SkyAsl/Qwen3.5-9B-com-agent

Commerce Operations Agent — Demo

Interactive demo for SkyAsl/Qwen3.5-9B-com-agent, a LoRA adapter on Qwen/Qwen3.5-9B fine-tuned for structured e-commerce operations.

It is a structured-JSON transducer, not a chat model. It performs exactly two tasks:

Task	Question it answers	Output
capability_advice	"What operational work can I monitor for this store?"	recommended operations + reasons
operation_plan	"Given these candidates, which do I act on?"	selected operations + priority + rationale

Why the guardrail panel matters

The model is trained to only select operations that appear in enabled_operations, and to only reference candidate_ids that were supplied in the input. The demo validates every response against those constraints and shows the result, so you can see the model decline to act when an operation is not enabled — the interesting behaviour, not just the happy path.

Use the "guardrail (should decline)" preset on the Operation plan tab: the candidate is urgent (zero stock, well below reorder point) but its operation is not enabled, so the correct answer is an empty operation list.

Notes for running it

• Hardware: the base model is ~9B params, so this needs a GPU. On cpu-basic it will not fit in memory. Set the Space hardware to ZeroGPU (or a paid GPU tier).
• Thinking mode is disabled deliberately. The base Qwen3.5 chat template injects a <think> block on generation. This adapter was trained on assistant turns that are pure JSON with no thinking blocks, so the app passes enable_thinking=False. Leaving it on produces malformed output.
• Sampling is greedy (do_sample=False) because the task is structured extraction, not creative generation.