[KongchangAI]
· 2 min read· 1,396 words

Local 27B AI Agent Autonomously Completes Amazon Shopping: A Full End-to-End Run

Local 27B AI Agent Autonomously Completes Amazon Shopping: A Full End-to-End Run

Local Qwen3 27B Agent autonomously shops on Amazon in 24 minutes, proving privacy-first Agents are viable.

A developer handed their Amazon account to a fully local AI Agent with one instruction — "buy A4 paper" — and the Agent autonomously handled search, price comparison, product selection, and order preparation, with human intervention only at login and final confirmation. The system runs on Qwen3 27B, TensorSharp, and Playwright, keeping all reasoning and decision-making off the cloud. The tradeoff is speed: what takes a human two minutes took the Agent 24, highlighting the real limits of local inference today.

A Real-World Local Agent Experiment

A developer shared a thought-provoking experiment on Reddit: when the A4 paper at home ran out, instead of placing an order manually, they handed their Amazon account to a fully local AI Agent with a single instruction — "Search Amazon for A4 paper, find a good deal, and buy it. Handle as many steps as you can on your own." The result: the Agent completed the task in a single run.

The value of this experiment isn't that "it bought a ream of paper" — it's that it validates a technical approach gaining growing attention: driving a browser Agent with a locally running large language model, keeping inference, decision-making, and tool execution almost entirely on your own machine.

Reddit post screenshot

Tech Stack Breakdown: Nearly Fully Local

Based on the author's disclosed setup, the system consists of three components:

  • Model: Qwen3 27B running locally (referred to in the original post as Qwen3.8 27B)
  • Runtime: TensorSharp, an open-source local LLM inference engine + Agent runtime
  • Tool layer: Browser interaction via a Playwright skill

The most notable aspect is how local the Agent loop is. The author emphasizes that reasoning, the Agent's state management, code generation, and tool execution all run locally. The only thing that leaves the machine is network traffic to Amazon itself. In other words, the model's "brain" and decision-making process never pass through any cloud API — the user's intent and intermediate states are never exposed to a third-party model provider.

For privacy-sensitive scenarios — such as operations involving personal accounts and payment information — this architecture has a natural advantage. You don't need to hand your account credentials or shopping intent to a remote model; the model simply "thinks" on your own hardware, then instructs the browser to click.

Qwen3 27B is one of the open-source large language model series released by Alibaba's Tongyi Qianwen team. The "27B" refers to approximately 27 billion parameters. Parameter count determines a model's "size" — more parameters generally means stronger reasoning and instruction-following capability, but also higher local hardware requirements. Running a 27B-scale model typically requires a consumer GPU with at least 24GB VRAM (such as an RTX 3090/4090) or a high-end Mac with unified memory architecture (such as the M2/M3 Ultra). The Qwen3 series is known for strong multilingual understanding, code generation, and tool-calling performance, making it a natural fit for Agent tasks that require generating Playwright code to control a browser. Playwright itself is an open-source browser automation framework developed by Microsoft, supporting scripts in Python, JavaScript, and other languages to control Chromium, Firefox, and WebKit browsers — handling clicks, form filling, screenshots, and page navigation — making it the core tool layer for driving a "browser Agent."

Human Intervention: Only Twice

Throughout the entire task, the author only intervened manually twice:

  1. Logging into the Amazon account — for security reasons, the login step was not delegated to the Agent
  2. Confirming the final purchase — a human approval step before placing the order

Every other step was handled autonomously by the Agent: searching for keywords, browsing product listings, comparing different items and prices, navigating between Amazon pages, deciding which product to buy, and preparing the order.

This pattern — human checkpoints at critical nodes, full automation everywhere else — is actually the most realistic and safe deployment model for browser Agents today. Letting an Agent operate a payment account completely unsupervised is too risky, but retaining human confirmation at the two high-risk actions (login and payment) strikes a balance between automation efficiency and security.

The Real Cost: 24 Minutes

The author provided a full raw video of the Agent and tool execution trace, including the browser instructions and Playwright code the Agent generated. Worth noting: the video was played back at 8x speed — the actual task took approximately 24 minutes.

That number is telling. A human buying a ream of A4 paper manually might take one or two minutes; the local 27B model-driven Agent took nearly half an hour. The gap comes primarily from local inference speed, the reasoning overhead at each decision step, and wait times from browser interactions.

This is a reminder that local Agents are currently more of a proof of feasibility than a speed advantage. It demonstrates that "complex, multi-step real-world tasks can run without relying on the cloud," but the speed gap to practical usability remains significant. For users who prioritize privacy, controllability, and offline capability, that tradeoff may be worth it — but for everyday efficiency-focused use cases, it's not the optimal solution yet.

The 24-minute runtime points to a key technical bottleneck: local inference token generation speed (tokens per second, TPS). Cloud APIs can typically deliver tens to hundreds of tokens per second, while running a 27B model on a consumer GPU often yields only 10–30 tokens per second. For a multi-step shopping Agent, each decision requires the model to fully "think" through the current page content, analyze the state, and generate the next action command — each reasoning pass can produce hundreds to thousands of tokens. Add in the wait time for Playwright to execute browser operations, page load times, and the longer reasoning chains produced when Qwen3 runs in extended thinking mode, and the overall task duration stretches considerably. That's why the video needed to be played at 8x speed to not feel tedious. Advances in quantization techniques (such as 4-bit quantization in GGUF format) and inference optimization frameworks (such as llama.cpp and MLX) are continuously improving local inference speed, but the gap with cloud services will remain significant in the near term.

Next Stop: Local Agent on iPhone

The author mentioned that the next challenge is running the same experience on an iPhone via TensorAgent. The obstacles on mobile are fairly clear: local inference speed is constrained by phone hardware, and iOS browser restrictions make tool execution significantly harder.

If a mobile local Agent can actually be realized, its significance would exceed the desktop version — it would mean a personal assistant that fits in your pocket, can think without an internet connection, and can operate apps on your behalf. But given the compute demands of a 27B model and iOS sandbox restrictions, this path is clearly not going to be easy.

TensorAgent is a project within the TensorSharp ecosystem targeting mobile devices, with the goal of bringing local LLM inference and Agent runtime to iPhones and similar devices. The limitations on iOS aren't just about compute — the latest Apple silicon (such as the A17 Pro and A18) is already quite capable for neural network computation. The more critical obstacle is iOS's system sandbox. Apple does not allow third-party browsers to use their own rendering engines (all iOS browsers must use WebKit under the hood), and inter-app interactions are strictly limited. This means desktop browser automation tools like Playwright cannot be directly ported. Developers need alternative approaches — such as embedding WebViews within an app for controlled interactions, or simulating operations via iOS's Accessibility API — both of which face additional challenges around permissions and stability. On the model side, phones can typically only run quantized models in the 1B–7B range, a meaningful capability gap compared to 27B.

The Value and Limitations of Local Browser Agents

This experiment sparked discussion because it touches on a core question: Do we need to keep the intelligence layer of an Agent local?

The case for local is compelling: data privacy, no API costs, offline capability, and full control. The entire decision chain is transparent to the user — you can even audit every line of Playwright code the Agent generates.

But the limitations are equally clear: running a 27B model requires substantial local hardware, slow inference means tasks take a long time, and the model capability ceiling is constrained by what you can deploy locally. Cloud-hosted frontier models driving Agents are typically stronger in both capability and speed.

For the broader industry, the significance of experiments like this is in continuously exploring a "privacy-first" Agent paradigm. As smaller models improve in capability and consumer hardware gains more compute power, the cost-benefit curve for local Agents may gradually shift. The value of open-source projects like TensorSharp lies precisely in putting this approach's feasibility on the table — giving more people the ability to reproduce and improve on it.

#local AI Agent#Qwen3 27B#browser automation#TensorSharp#Playwright#privacy-first AI#on-device LLM
Share:

Related articles