The ticket, not the chat, is the real unit of AI work — and that matters more to sellers than to devs
Most cross-border operators I talk to are running some version of the same experiment: point an AI coding agent at a scraper, a Shopify app, a custom FBA repricer, or an internal ops dashboard, and see if it can ship something useful. The experiment usually dies in the same place. Not at the first prompt — at the fortieth. The context window fills, the agent forgets what it was doing, and you spend your evening re-explaining your own codebase to a tool that was supposed to save you time. So when I saw Singularity, a beta desktop app from Meteor Factory that reframes AI coding around the ticket instead of the chat, I paid attention. The pitch — one ticket, one scope, one isolated Git worktree, only the context it needs — is a workflow claim, not a model claim. And workflow is exactly where cross-border sellers keep losing.
What Singularity actually solves, in operator terms
The founder, Antony Kervazo Canut, frames the problem from a decade in DevOps and SRE: the chat loop. Prompt, correct, re-prompt. Context fills, agent drifts, you end up babysitting. His answer is to stop treating the conversation as the unit of work and treat the ticket as the unit instead. Each ticket gets one scope, one isolated Git worktree, and only the context it needs. You can run several agents in parallel across multiple repos, get a native notification when one finishes, review the diff, and merge.
The reported usage numbers from a real week inside Meteor Factory: 227 tickets shipped, 86 features, 11 projects, up to 8 agents running at once, and roughly two messages per ticket. Those are the numbers I’d want every tool vendor to publish, because they describe throughput, not vibes. Two messages per ticket is the claim that carries the most weight and deserves the most skepticism — more on that below.
What you actually get, per the launch post: a desktop app that bundles a code editor, terminal, Git, and a ticket board; support for Claude, Codex, Copilot, and Gemini using your own API key; code that stays on your machine with only LLM calls going out; and a free core tier with unlimited agents, projects, and worktrees. It’s in beta, and the team is openly asking for feedback on what breaks and how it compares to what people already use.
Why this is a seller-side story, not a dev-tool story
Here’s the part most cross-border operators will miss. You are already running a multi-agent operation — you just don’t call it that. Your Amazon catalog, your Shopify storefront, your TikTok Shop listings, your Temu and SHEIN feeds, your Etsy shop, your eBay store: each is a “repo” with its own rules, its own data shape, and its own failure modes. When you ask an AI tool to “update the listing copy across channels,” you’re really asking it to touch five worktrees at once, and the tool almost never knows that.
The ticket model maps cleanly onto that reality. A ticket is “fix the A+ content on the three ASINs flagged for low conversion.” A ticket is “rewrite the TikTok Shop product titles to match the new keyword set.” A ticket is “reconcile the returns reason codes from last week’s FBA report.” Each of those has a scope, a diff, and a review step. None of them should require you to hold a 40-message conversation with a chatbot that has already forgotten your SKU taxonomy.
How it differs from the tools you’re probably already using
The incumbent most people will compare this to is Conductor, which a commenter named Bengeekly raised directly. Antony’s answer is the most useful part of the whole thread: Singularity doesn’t use conversation with AI, it uses instructions, so the AI only asks questions when required. It uses a kanban board, and the AI produces proof of work, builds, merges, and tests. He says he built it after testing Conductor because he needed AI working across multiple projects simultaneously — frontend, backend, CI/CD — and because some projects are shared (a backend used by both a mobile app and a frontend), which meant a workspace-scoped agent would only ever see part of the picture. He also notes that Conductor wanted a GitHub connection, whereas Singularity creates a Git repository if needed, lets you choose your provider, and lets you follow your gitgraph without a separate tool like Fork or GitKraken.
If you’re coming from the chat-first camp — Cursor, Claude Code, GitHub Copilot in its agent modes, or Devin — the difference is philosophical. Those tools assume the conversation is where the work lives. Singularity assumes the conversation is overhead, and the ticket is where the work lives. For a solo operator or a two-person brand team, that’s the difference between an AI that helps you ship and an AI that helps you talk about shipping.
On the model side, supporting Claude, Codex, Copilot, and Gemini with your own API key is the right call for this audience. It means you’re not locked into one vendor’s pricing curve, and it means the tool can improve as the underlying models improve without a migration. The “code stays on your machine, only LLM calls go out” line matters too — if you’re handling supplier contracts, margin data, or customer PII, you don’t want a third-party SaaS holding your repo.
Where the math breaks
The 2-messages-per-ticket figure is the one I’d pressure-test hardest, and a commenter named Gal Dayan made exactly the right objection: it’s believable for self-contained tickets like adding a field or fixing a lint rule, but the tickets that actually eat your time are the ones where the fix touches three files you didn’t expect and the agent needs a round of “no, not like that” before it lands. His question — does the isolated-worktree model hold up when 8 parallel tickets overlap in the same file, or does the babysitting just move to the merge step — is the question every operator should be asking before they trust the throughput numbers.
Antony’s answer on dependencies is worth quoting in substance: every ticket is first prequalified by a quick AI request, and the AI has access to all tickets in the workspace. If a development needs to build on previous work, the ticket is flagged as dependent on that other ticket. Otherwise, tickets run independently and the AI and Singularity merge the work without merge conflicts. That’s a reasonable design. It is not the same as proof that it works at 8-way parallelism on a messy real-world codebase. Beta means beta.
What cross-border sellers can borrow from this, regardless of whether they adopt it
You don’t have to install Singularity to steal its operating model. In fact, most of the value here is conceptual, and it transfers to tools you already pay for.
Ticket-first beats chat-first for marketplace ops
Take your Amazon Seller Central workflow. Right now, most sellers interact with AI as a chat: paste a listing, ask for a rewrite, paste the next one. That’s the exact loop Singularity is designed to kill. Instead, define tickets. “Rewrite the bullet points for ASIN X using the keyword set from Helium 10’s Cerebro export.” “Draft a response to the negative review on ASIN Y that matches our brand voice guide.” “Reconcile the FBA reimbursement report against the settlement report and flag discrepancies over $20.” Each ticket has a scope, an expected output, and a review step. You stop re-explaining context because the context lives in the ticket, not in a conversation that scrolls off-screen.
This is the same discipline that makes Helium 10, Jungle Scout, and Keepa useful — they’re structured workflows, not chat windows. The AI tools that win in cross-border will be the ones that adopt the same structure.
Isolated worktrees are the right metaphor for multi-channel catalogs
The Git worktree concept — a separate, isolated working copy of the repo for each task — is exactly how you should think about your channel expansion. Your Shopify storefront, your TikTok Shop listings, your Temu feed, your SHEIN catalog, your Etsy shop, and your eBay store are not the same repo with different skins. They have different title-length rules, different image specs, different return policies, different fee structures, and different customer expectations. Treating them as one blob is how you end up with a TikTok title that reads like an Amazon bullet and converts on neither.
If you’re running an AI agent across channels, give each channel its own worktree. Let the agent touch one channel at a time. Review the diff. Merge. The merge step is where you catch the cross-channel inconsistencies that a single chat session would have buried.
The “one ticket, one scope” rule fixes your returns and reconciliation work
Returns and reconciliation are where cross-border sellers lose the most money to sloppiness, and they’re also the most ticket-shaped work in the business. A return from a Fulfillment by Amazon order, a chargeback from a Shopify payment, a Temu penalty for a late shipment, a SHEIN quality claim — each is a discrete unit with a scope, a resolution, and a paper trail. If you’re handling these in a chat window, you’re losing the audit trail. If you’re handling them as tickets, you’re building one.
Why Amazon sellers should care more than Shopify ones
Shopify sellers tend to have one storefront and a relatively clean data model. Amazon sellers have a marketplace, a catalog, an ad console, a fulfillment network, a returns pipeline, and a reimbursement process — and each of those is effectively a separate project that shares data with the others. That’s exactly the “backend used by both a mobile app and a frontend” problem Antony described as his reason for building Singularity. If you’re running a multi-ASIN, multi-marketplace operation, the ticket model isn’t a nice-to-have. It’s the only way to keep eight parallel workstreams from stepping on each other.
Where my judgment says it falls short
Three concerns, in order of how much they’d slow me down.
First, it’s a desktop app in beta, and the entire value proposition depends on it being more reliable than the chat loop it replaces. If the app crashes mid-merge, or if the worktree isolation leaks, you’ve traded one babysitting job for another. The launch post doesn’t disclose pricing beyond “free core,” doesn’t disclose what the paid tier will cost, and doesn’t disclose a public roadmap. That’s fine for a beta, but it’s not enough to build a production workflow on top of yet.
Second, the “2 messages per ticket” number is a Meteor Factory internal metric on Meteor Factory’s own codebase, with a team that includes the tool’s own authors. That’s the most favorable possible test environment. Your codebase — a tangle of Shopify Liquid, Amazon SP-API calls, a half-finished Python repricer, and a Zapier chain nobody remembers building — is not that. Expect the number to be higher, possibly much higher, for the first month.
Third, the multi-model support is a strength and a trap. Supporting Claude, Codex, Copilot, and Gemini with your own API key means you’re paying per token across four vendors, and the quality of the ticket-prequalification step — the AI that decides whether ticket B depends on ticket A — will vary by model. If that prequalification is wrong, you get either false dependencies that serialize your work or missed dependencies that produce merge conflicts. The launch thread doesn’t say which model does the prequalification or how it’s tuned.
None of these are dealbreakers. They’re the reasons I’d pilot this on a side project before I let it anywhere near my production catalog.
What I’d watch / test next
This week, before you install anything, do the cheap version of the experiment. Pick one recurring ops task — say, rewriting the bullet points on your ten worst-converting ASINs. Write it as a ticket: scope, inputs, expected output, review criteria. Then run it through whatever AI tool you already pay for, but force yourself to work ticket-first instead of chat-first. Count how many messages it actually takes. If it’s more than five, the problem isn’t your tool — it’s your scoping, and Singularity won’t fix that either.
If the ticket-first experiment works, then go look at Singularity on Product Hunt and read the full comment thread, especially the exchange with Gal Dayan about parallel overlap and the one with Bengeekly about Conductor. Those two threads tell you more about the tool’s real limits than the launch copy does. Then install it on a throwaway repo — not your Shopify theme, not your repricer — and run three tickets in parallel. Watch the merge step. That’s where the babysitting either disappears or relocates. My bet: it relocates for the first week, then genuinely disappears for the kind of scoped, repetitive work that eats most of a cross-border operator’s calendar. That’s worth a beta test. It is not yet worth a workflow migration.
