The always-on agent question every seller with a lean ops team should be asking
Most cross-border operators I know are running a two- to ten-person team against a workload that used to require a twenty-person back office. The bottleneck is no longer sourcing or even ad spend — it’s the ambient, low-grade operational noise: checking whether a supplier replied, watching a listing for a hijack, pulling a morning snapshot of yesterday’s ad spend, chasing a 3PL on a stuck inbound. Cloud AI assistants have been useless for most of this because they only exist while you’re staring at them. So when a maker launches an always-on agent that runs on your own machine and pings you on Telegram or Slack, that’s not a novelty — that’s a candidate replacement for the human whose entire job is “watch things and tell me when something changes.” Agibot, built by Ökte Çilmi, is exactly that bet, and it’s worth dissecting on operator terms rather than enthusiast terms.
What Agibot actually is, and what problem it’s solving
Strip away the launch copy and the pitch is narrow and specific: an always-on personal AI agent that runs on your own computer, keeps working after you close the window, and reaches you through Telegram or Slack in one shared conversation rather than forcing you into yet another dashboard. The maker’s framing is blunt — “Most AI assistants only work while you’re chatting with them. Close the tab and they stop” — and that’s the correct diagnosis. The failure mode of every chat-wrapped assistant is that it has no persistence, no schedule, and no initiative.
The four capabilities that matter, translated into operator language:
- Background execution. It keeps running after the window closes. For a seller, that’s the difference between a tool you remember to open and a process that exists whether or not you remembered.
- Scheduled briefs. A morning brief on a schedule. This is the single most commodity-shaped feature in the product and also the one most sellers will actually use first.
- Change-triggered alerts. It watches things and only messages you when something changes. This is the real product. “Only messages you when something changes” is the entire value proposition of a good ops hire.
- Web task execution, plus Mac app control. It handles tasks on the web and, on Mac, can drive your apps. That’s where it stops being a notifier and starts being a worker.
The trust architecture is the part I’d scrutinize hardest, and the maker was unusually forthcoming about it in the comments. Every tool is set to allow, ask, or block. Out of the box, file writes, web fetches, scheduling, memory deletion, and browser control all default to ask. Shell access is off entirely until you enable it, and even then every command asks — you cannot set it to always-allow. New tools, including anything from an MCP server you just added, start at ask. Approval requests arrive as buttons in Telegram or Slack, and — this is the detail that matters — if you don’t answer, the answer is no. A commenter on the launch thread flagged exactly why that’s the right default: “a lot of approval systems silently default to allow on a timeout instead, which defeats the whole point.”
Pricing is the other headline: free forever with your own API key. You bring OpenAI, Anthropic, Google Gemini, or others, or run a free local model, and you pay the provider directly with nothing added on top. Mac waitlist is open now, Windows next. There’s a product site if you want the waitlist.
Why this matters more to a marketplace seller than a DTC brand
Here’s my read on who should care, and it isn’t who you’d expect.
A Shopify DTC brand owner has a clean stack. Klaviyo fires the flows, Shopify’s admin is one dashboard, and most of the “watch things” work is already handled by platform-native alerts. An always-on agent is a nice-to-have there.
An Amazon seller lives in the opposite world. Your operational truth is scattered across Seller Central, a Helium 10 or Jungle Scout tab, a supplier’s WeChat thread, a 3PL’s email, and a spreadsheet somebody maintains by hand. There is no single pane of glass, and there never will be, because Amazon has no incentive to build one. That fragmentation is precisely the environment where a local agent that can fetch a page, diff it against yesterday, and message you only on change earns its keep. Same story for TikTok Shop sellers juggling affiliate commission changes and Temu or SHEIN operators who are effectively renting their storefront and get almost no native monitoring.
How it differs from the incumbents you’d actually compare it to
The obvious question, and one a commenter asked directly, is why not just use Dots or Grok Bot? The maker’s answer is the most useful part of the entire thread, so let me restate it as a competitive positioning table in prose.
Cloud-agent alternatives — Dots, Grok Bot, and the general category of cloud-hosted agents — give you an agent with its own cloud computer that keeps running while your laptop is off. If you already pay for ChatGPT or SuperGrok, they’re a great fit. That’s a genuine advantage Agibot does not have: Agibot only runs while your computer is on, or on a server you leave running. The maker says this plainly rather than hiding it. For a seller in Shenzhen or Istanbul whose laptop is closed for eight hours, that’s a real gap.
Where Agibot differentiates:
- Cost. It’s free with your own API key; Dots and Grok Bot need paid plans.
- Model portability. Dots runs on OpenAI’s models, Grok Bot on xAI’s. Agibot lets you use Claude, GPT, Gemini, Grok, DeepSeek, and more, switch when something better ships, and set backup models for outages. For operators, model portability is a hedge against both price hikes and capability shifts.
- Memory ownership. What it learns is saved on your computer and you can read, edit, or delete any of it. If you switch models, the memory comes with you. This is the anti-lock-in argument, and it’s the one I find most persuasive.
- Channel flexibility. App, Telegram, or Slack, all one conversation. The maker confirmed memory belongs to the agent, not the app — tell it in the app to keep briefs to five lines and the Telegram and Slack briefs stay at five lines. The only split is when you run separate agents, e.g. a work agent on Slack and a personal one on Telegram, each with its own memory.
- Rule granularity. Allow/ask/block per tool, a daily spending cap, and a full activity log.
Compare that to what a seller is using today. Zapier and Make automate deterministic if-this-then-that flows — they’re reliable but brittle and can’t reason about a page they’ve never seen. Shopify Flow is powerful but only inside Shopify. Native platform alerts are shallow and unconfigurable. Agibot sits in the gap: reasoning-capable, cross-platform, and reachable from a phone.
Where the math breaks
Two places, and both are worth pricing out before you commit.
First, the spend cap is a guardrail, not a ceiling. The maker was admirably precise here: Agibot checks the estimated cost before every call, estimates on the high side and sets aside the full possible reply length, and refuses the call if it doesn’t know a model’s price rather than guessing. But he also conceded the honest part — “Those are estimates, though, so I’d still set a limit with your provider too.” If a provider changes pricing after you installed, there’s a window where a stale cached price could let a call through above your real daily cap. The fix is in progress: connecting the cap to live provider pricing. Until then, set the hard ceiling with your provider, not with Agibot. An unattended agent on a metered API is a billing surface, and you should treat it like one.
Second, the local-only constraint has a hidden cost. “Runs on your own computer” sounds free. It isn’t, if you want 24⁄7 coverage — you’re now paying for a machine that stays on, or a VPS you maintain, plus the operational overhead of keeping that box healthy. Cloud agents bundle that cost invisibly into a subscription. Neither is wrong; just don’t model Agibot as $0 if you need it awake at 3 a.m. during a supplier’s business hours.
What cross-border sellers can borrow from this launch
Even if you never install Agibot, the design decisions here are worth stealing for your own ops.
Default to “ask,” and make timeout mean no. The single best line in the thread is “A safety check that fails open isn’t a safety check.” Apply that to your own automations. If you’ve built any repricing rule, any auto-responder, any inventory sync, ask yourself what it does when it can’t reach the API. If the answer is “proceeds anyway,” you have a bug waiting for a bad Tuesday.
Make memory portable and inspectable. The reason sellers get locked into Helium 10 or Klaviyo isn’t the software — it’s the accumulated configuration and history. Any tool you adopt should let you export what it knows about you. Agibot’s “see, edit, and delete everything it remembers” is the right posture, and it’s a filter you should apply to every SaaS renewal this quarter.
Route alerts to where you already live. Telegram and Slack, not another dashboard. Every additional tab is a place notifications go to die. If your current monitoring pings you by email, you have already lost.
Start with one scheduled brief, not ten tasks. The morning brief is the lowest-risk, highest-signal entry point. It’s read-only, it’s scheduled, and it teaches you how the agent behaves before you hand it anything with write access.
Where my judgment says it falls short
I’ll be direct, because the launch thread was unusually honest and the product deserves the same treatment.
The local-only model is a real ceiling for this audience. Cross-border sellers are, by definition, often away from their machine — on a sourcing trip, in a different time zone, asleep during their supplier’s workday. An agent that sleeps when your laptop sleeps is structurally mismatched to the job. The maker acknowledges the trade-off and suggests a server you leave running, which is fine advice but shifts real work onto you. Until there’s a hosted option, I’d treat Agibot as a daytime ops assistant, not a 24⁄7 watchtower.
“Handles tasks on the web” is underspecified. The launch copy doesn’t say which sites, how it handles auth, or what happens when a site changes its DOM. For an Amazon seller, the difference between “can read a public page” and “can log into Seller Central and pull reports” is the difference between a toy and a tool. Not disclosed, and it’s the first thing I’d test.
Mac-first, Windows next, no date. If your ops person runs Windows — and plenty do — you’re waiting. No timeline was given.
The free-forever model has an obvious sustainability question. Free with your own API key means no revenue from the core product. That’s fine for a launch, less fine at scale. I’d want to know what the paid tier looks like before I build workflows on top of it.
No mention of team seats or shared memory. For a seller with three ops staff, “whose memory is it” becomes an immediate governance question. The maker’s answer covered per-agent memory, not per-person access control. Not disclosed.
What I’d watch / test next
This week, three concrete moves. One: join the Mac waitlist and, while you wait, write down the five things you currently check manually every morning — supplier replies, ad spend, listing health, inbound status, competitor pricing. That list is your test plan, and it’s also a useful audit of where your team’s hours are actually going. Two: if you’re already paying for an LLM API, set a hard provider-side spend limit today, before you connect anything unattended to it — the maker’s own advice, and it’s correct. Three: run a read-only experiment first. A scheduled morning brief that pulls public data and messages you on Telegram is low-risk, and it will tell you within a week whether change-triggered alerts reduce your tab-switching or just add another notification stream. If it’s the latter, you’ve learned something cheap. If it’s the former, you’ve found a candidate to replace the most expensive line item in your ops budget: the human whose job is to watch things and speak up when something moves.
