The agentic stack is coming for your ops team, and Firetower is an early tell
If you run a cross-border store, you already know the dirty secret of “AI-powered” e-commerce: most of it is a chatbot bolted onto a dashboard, and the actual work — bulk-editing listings across Amazon Seller Central, reconciling Shopify payouts against Stripe fees, chasing TikTok Shop order exceptions — still lands on a human in a timezone you’re not in. The interesting shift isn’t better chat. It’s that coding agents like Claude Code and Codex are quietly becoming general-purpose operators, and the bottleneck has moved from “can the model do the task” to “can I keep the task running when my laptop closes.” That’s the exact gap Firetower, launched by maker Kevin Piacentini, is trying to own. And yes, it’s nominally a developer tool. Read it anyway.
What Firetower actually is, and why it’s not just a dev-toy
Firetower is an open-source platform for running coding agents — Claude Code, Codex, or Kimi Code — on infrastructure you control rather than on your laptop. The pitch, in the maker’s own framing, is that agents should feel “less like local CLI processes and more like persistent remote workers you can launch, leave running, and come back to from anywhere.” Concretely, that means sessions survive disconnects, each agent works in an isolated Git worktree, multiple agents run in parallel, and you can connect your own servers. The core is written in Rust, and the maker claims agent workers “add no memory overhead” — a pointed jab at the orchestration layers that eat half your machine before the agent does any work.
For a cross-border operator, strip away the Git vocabulary and the shape is familiar: it’s a job runner for autonomous workers, with state, isolation, secrets, and connectivity handled for you. That’s the same abstraction pattern behind Shopify Flow or Zapier — except the “step” here is an LLM that can write and execute code, not a pre-built connector.
Why Amazon sellers should care more than Shopify ones
Here’s my honest read: if you’re a Shopify-first DTC brand, Firetower is interesting but not urgent. Your stack is API-friendly, your data lives in systems with clean endpoints, and the marginal value of a persistent autonomous worker is real but incremental. If you’re an Amazon FBA seller, it’s a different story. So much of the operational pain in Amazon-land lives in places with no clean API: Seller Central bulk upload templates, flat-file reconciliation, dispute workflows, the endless spreadsheet gymnastics between Helium 10 exports and your replenishment model. An agent that can hold a browser session, survive a network blip, and keep grinding through a 4,000-row flat file while you sleep is worth more to you than to a merchant whose entire catalog is already in a well-documented REST API. The persistence layer is the product. Don’t lose sight of that.
How it differs from what you’re probably already using
Most sellers I talk to have one of three things in their “automation” bucket: a Zapier or Make account running brittle multi-step zaps, a Klaviyo flow they haven’t touched in six months, or a human VA in the Philippines doing the same task manually because the API doesn’t exist. Firetower sits in a fourth category: infrastructure for agents that write their own glue code. That’s a meaningfully different bet. Zapier assumes the integration already exists; Firetower assumes the agent will figure out the integration on the fly, in a sandboxed worktree, with your secrets injected.
The closest comparison in the e-commerce tooling world is probably the browser-automation layer — tools like Browserbase or the agentic features creeping into Gorgias and Zendesk. But those are vertical: they solve support tickets or scraping. Firetower is horizontal infrastructure. That’s both its strength and its weakness, which I’ll get to.
Where the math breaks
Two things in the launch thread jumped out at me as the real operational questions, and both come from other makers in the comments. Greg Glazewski asked who cleans up worktrees once a branch is merged, worrying about disk fill on a small server after weeks of agents. The maker’s answer — “when you close the workspace it sweeps everything that needs to be cleaned automatically” — is fine, but Glazewski’s follow-up is the one that matters: what about a workspace that’s been idle for days with nobody closing it? That’s not a hypothetical. That’s your Tuesday. An agent that stalls on a permission prompt at 2am your time and sits there consuming a worktree until you notice is a cost center, not a worker. The maker’s answer to that thread is, effectively, “push notifications are landing this week” — which tells you the idle-cleanup story isn’t fully solved yet.
The second is from Gal Dayan, who runs a lot of Claude Code sessions and asked the sharpest question in the thread: does Firetower keep the agent’s running session alive on the server across a client disconnect, or does checking in from mobile just reattach to a fresh session? The maker didn’t answer that one in the scrape. That’s the single most important architectural question for anyone evaluating this, because “persistent remote worker” and “reattaches to a fresh session” are completely different products. If it’s the latter, the persistence pitch is marketing. If it’s the former, it’s genuinely differentiated. Until that’s answered publicly, treat the persistence claim as unverified.
What cross-border sellers should borrow from this
Even if you never touch Firetower, three ideas here are worth stealing for your own ops.
First, separate the agent from the machine. Most sellers running AI tools today are running them in a browser tab on a laptop that closes, sleeps, or dies. Every workflow that depends on a human staying logged in is a workflow that breaks the moment that human goes to bed. The mental model Firetower is pushing — agents as remote workers with their own infrastructure — is the right one regardless of vendor. If you’re doing anything serious with AI in your ops, get it off your laptop.
Second, isolate by default. Git worktrees are a developer concept, but the underlying principle — every task runs in its own sandbox so a bad run can’t corrupt a good one — maps directly to how you should be structuring bulk operations. If your VA is editing live listings in Seller Central with no staging copy, you’re one fat-finger away from a suppressed listing. The worktree pattern is a rebuke of that.
Third, secrets and connectivity are the boring parts that kill you. The maker explicitly lists “repositories, worktrees, sessions, secrets, connectivity, and orchestration” as the boring parts Firetower handles. In e-commerce terms, that’s API keys, OAuth tokens, 2FA on marketplace accounts, and the connectivity that breaks when TikTok Shop rate-limits you. Whoever solves credential and session management for cross-border ops cleanly wins a lot of loyalty. Nobody has.
The Temu and SHEIN problem
One thing the launch doesn’t address, and it’s the elephant for anyone selling on Temu or SHEIN: those platforms are hostile to automation by design. Aggressive bot detection, opaque seller APIs, and terms of service that treat scraping as a violation. A tool like Firetower, which runs agents on infrastructure you control, is technically capable of operating against those surfaces — but “technically capable” and “won’t get your account nuked” are different things. If you’re on Etsy or eBay, where the APIs are more permissive and the seller community has a long tradition of third-party tooling, the calculus is friendlier. On Temu, I’d be very careful about pointing an autonomous agent at your seller account, no matter how good the orchestration layer is.
Where I think Firetower falls short
Let me be direct, because the launch thread is mostly congratulatory and that’s not useful to you.
It’s a developer tool wearing an operator costume. The entire vocabulary — worktrees, branches, Rust, Git — assumes a technical user. Most cross-border sellers I know are sophisticated operators, not engineers. They can configure a Klaviyo flow and read a P&L, but they are not going to spin up a Rust-based orchestration layer on their own server. Firetower’s real customer is probably an agency, a technical co-founder, or a seller who already has a dev on staff. That’s a smaller market than the pitch implies.
The persistence question is unanswered. As noted, Dayan’s question about session survival across disconnects didn’t get a public answer in the thread. For a product whose entire value proposition is “sessions survive disconnects,” that’s the one thing that needs a crisp, unambiguous answer. Until it’s there, I’d treat the core claim as a hypothesis to test, not a feature to rely on.
Push notifications are “landing this week.” The maker said this twice in the thread, in response to two different people asking how approvals work from a phone. That means the mobile approval loop — arguably the single most important feature for a seller in a different timezone from their infrastructure — is not shipped yet. If you’re evaluating this today, you’re evaluating a roadmap, not a product.
Open source cuts both ways. Open source is a genuine advantage for a tool that touches your credentials and your code — you can audit it, self-host it, and you’re not handing your API keys to a startup that might pivot. But it also means no SLA, no support contract, and a maintenance burden that lands on whoever on your team is most technical. For a seller with a dev, that’s fine. For a seller without one, it’s a trap.
What I’d watch / test next
If you’re a cross-border operator with any technical capacity on your team, here’s what I’d do this week. First, get a definitive answer on the session-persistence question — either from the maker directly or by spinning up a test instance and killing your client mid-session to see if the agent keeps running. That single test tells you whether Firetower is infrastructure or a wrapper. Second, pick one genuinely painful, API-less workflow — I’d start with Amazon flat-file reconciliation or TikTok Shop order exception handling — and prototype it as an agent task on a throwaway server, not your production credentials. Third, watch how the idle-cleanup story evolves over the next 30 days; if workspaces don’t auto-expire, your server bill becomes a silent tax. And fourth, keep an eye on whether the push-notification approval loop actually ships and works from a phone, because that’s the feature that turns this from a dev curiosity into something a seller in Shenzhen or Guangzhou can actually run against a US marketplace while they sleep. The category is real. Whether Firetower is the tool that wins it is still an open question — but the direction it points is where your ops stack is going, whether you adopt it or not.
