How Alessio Fanelli uses Open AI Symphony for Autonomous Coding and Pokémon Card Trading Workflows

Alessio Fanelli runs coding agents the way most teams manage coworkers: through queues, review states, and long running infrastructure that stays online while he walks away. In this episode of How I AI, he shows a setup where moving a Linear issue into "To Do" can trigger a full coding run through OpenAI Symphony, complete with planning, implementation, pull requests, and rework cycles.

Alessio is the founder of Kernel Labs, a partner at Decibel Partners, and a co-host of the Latent Space podcast. His core idea is that the useful shift is from being an "agent prompter" to being an "agent manager." Instead of chasing the perfect prompt, he focuses on durable context, persistent runtimes, lightweight operating rules, and review systems that let agents keep working without constant babysitting.

The coding workflow runs on an always-on cloud machine tied into Linear and GitHub, so tasks can move forward whether Alessio is at his desk or checking a pull request from his phone. The second workflow applies the same orchestration mindset to a very different problem: identifying and pricing expensive Pokémon cards across messy marketplace listings, images, grading systems, and incomplete data.

Together, the demos are a useful reality check on agent workflows. The impressive part is not that the AI works unattended forever. It is that the surrounding system makes recurring work easier to queue, monitor, review, and improve over time.

Running coding agents through Linear and Symphony

Alessio started by running coding agents locally, but long tasks became fragile and annoying to manage. Machines would sleep, runs would stall, and intervention required physically returning to the computer. Moving everything to a VPS-style cloud setup changed the ergonomics. Now the agents stay online continuously, and he can manage work from Linear on desktop or mobile instead of treating each coding session like a one-off chat.

The stack behind the coding workflow

Three pieces anchor the system:

• Zo Computer: An always-on cloud computer with 32 GB of RAM and four cores hosts Alessio’s coding agents and repositories so the work can continue independently of his laptop.
• OpenAI Symphony: The open-source orchestration layer watches Linear for new work, creates coding runtimes, generates workpads and checklists, and moves tasks through the software delivery lifecycle. You can follow the full implementation in Automate Software Development with an AI Agent Manager using OpenAI Symphony and Linear. See Automate Software Development with an AI Agent Manager using OpenAI Symphony and Linear.
• Linear: The project board acts as the state machine. Alessio creates issues there, moves them between statuses, reviews work, and sends tasks back for rework.

From Linear issue to merged pull request

The workflow itself looks surprisingly close to a normal engineering process. The difference is that Symphony coordinates the implementation loop in the background:

1. Create the task: Alessio writes a short issue in Linear instead of opening a chat window. In the demo, he asked the agent to clean up a noisy table UI and remove a spread column.
2. Start the run: Moving the issue into "To Do" signals Symphony to begin work. Alessio treats the board itself as the interface for managing autonomous runs.
3. Plan and implement: Symphony creates a Codex workpad where the agent lays out acceptance criteria, validations, and an implementation plan before touching the code. The operating instructions live in a workflow.md file that explains how the project should behave.
4. Review: Once the agent finishes, the issue moves into Human Review and the code appears in a GitHub pull request. Alessio checks both the diff and the Vercel preview instead of reading every intermediate trace.
5. Rework: Comments left on the pull request get converted into a structured checklist. The agent addresses each item, updates the implementation, and cycles the task back through review.
6. Complete: After approval and merge, the issue lands in Done. Because the whole system lives in the cloud, Alessio can monitor and redirect multiple active runs from his phone while away from his desk.

Using token costs to spot broken workflows

One of the more practical parts of the setup is a custom ledger that tracks token usage per task. Alessio showed runs ranging from roughly 15 to 60 million tokens for ordinary work, while one deployment refactor ballooned to 221 million tokens.

He treats those spikes as operational signals rather than just billing data. If a task burns far more tokens than expected, the agent probably struggled with missing tools, vague instructions, or a brittle environment. In one example, a deployment migration consumed huge amounts of context because the original app assumed local storage behavior and had to be reworked for Vercel deployment.

That feedback loop is why Alessio keeps refining the tooling layer around the models. Kernel Labs built a Playwright extension called Glimpse so agents can capture screenshots, compare visual diffs, and inspect front-end changes more reliably during long autonomous runs. He also talked about regularly purging and simplifying markdown instruction files because agents tend to accumulate contradictory guidance over time. Instead of endlessly adding rules, he now trims workflows back down and keeps the instructions focused on what context the agent needs, what state to record, and what tools are available.

Using Codex to research and price Pokémon cards

Alessio also owns Merlin Games, a trading card store, and the business exposed a different kind of automation problem. Valuable cards are scattered across inconsistent marketplace listings, grading systems, screenshots, and reseller inventories. Humans can do the work manually, but it is slow, repetitive, and easy to miss opportunities.

Why trading card data is difficult to automate

The data behind collectible cards is highly inconsistent. Listings may contain partial names, blurry images, different grading companies, or missing identifiers. Pricing a single high-value card can mean checking eBay and TCGPlayer, comparing recent sales, understanding how PSA grades relate to CGC or BGS grades, and verifying certificate numbers from images.

That makes it a good fit for a browsing and vision workflow. Alessio uses Codex less like a chatbot and more like a research assistant that can navigate the web, inspect images, and compile structured information into the store’s inventory systems.

How the Pokémon card workflow operates

1. Build the reference list: High-end PSA graded cards include certificate numbers, but Alessio could not simply download a complete database of the cards he cared about. Instead, he gives Codex a starting point and a target, such as identifying every card worth more than a thousand dollars. See Build an AI Agent to Find Underpriced Pokémon Cards for Arbitrage.

fill out the certificate number for every card that costs more than a thousand dollars.

Codex browses the web, downloads listing images, extracts PSA certificate numbers with vision capabilities, and fills in missing records for the store’s internal data. The process replaces what would normally be a long manual search across marketplaces and grading sites.

1. Search for opportunities: After building the reference dataset, Alessio invokes a custom eBay skill that teaches the agent how to search for underpriced inventory.

use the eBay PSA premium. Let's find some underpriced cards from our premium list.

The skill includes marketplace-specific tactics and pricing logic. It explains how to batch requests without getting blocked, how to compare equivalent grades across PSA, CGC, and BGS, and how to identify listings that may be priced below market value. Alessio noted that the workflow is mainly useful for expensive inventory in the ten, twenty, or fifty thousand dollar range rather than ordinary low-cost cards.

1. Analyze the listings: Codex navigates eBay listings, compares them against the store’s premium inventory data, and flags potential arbitrage opportunities. Alessio and his team still make the purchasing decision, especially because condition, liquidity, and collector demand require judgment that does not fit neatly into rules.

What makes the workflow interesting is not just the card niche itself. It is the kind of business process it represents. The work spans images, browser sessions, inconsistent product metadata, and constantly changing listings. Traditional software struggled with that messiness, while an LLM-based agent can navigate it much more flexibly.

Alessio also pointed to another real-world use case still in progress: helping staff price cards in real time at trade shows, where sellers walk up with inventory and expect immediate offers. Today, workers manually search marketplaces card by card. An agent that can accelerate pricing and comparison work directly translates into saved clock time and faster purchasing decisions.

The shared pattern behind both systems

One of the clearest points from this episode of How I AI is that Symphony itself is not magic. Alessio repeatedly describes it as a way to shape context around the work. The models already know how to code. The value comes from creating durable state, predictable workflows, review loops, logs, and structured operating rules.

The Pokémon workflow follows the same pattern. The custom eBay skill captures the search process, Codex handles repetitive browsing and extraction work, and humans stay responsible for the consequential decisions. In both cases, the surrounding system matters more than any single prompt.

That is probably the most transferable lesson here. Alessio is not building giant orchestration diagrams or endlessly complicated agent frameworks. Much of the behavior lives in markdown files that describe expectations in natural language. The work is in defining the environment clearly enough that the agents can keep moving without constant intervention.

He also surfaced an important maintenance problem that many teams are starting to hit: instruction files accumulate junk. Agents add rules, workflows expand, and old constraints linger long after they stop being useful. Alessio now revisits and simplifies those files regularly instead of treating them as permanent system prompts.

The strongest idea worth copying is the combination of lightweight orchestration and strong review boundaries. Linear as a control surface, persistent cloud runtimes, structured rework states, and token tracking all seem genuinely useful for teams already comfortable reviewing AI-generated work.

The Pokémon workflow is compelling for a different reason. It shows where agents already outperform traditional automation: messy environments with images, browsing, inconsistent schemas, and fragmented marketplaces. But neither system removes human judgment. Someone still decides whether a pull request is safe to merge or whether a supposedly underpriced card is actually worth buying. The automation works best when the agent handles the searching, sorting, and repetitive coordination work while the operator stays responsible for the expensive decisions.