See a real release go through an agent team

I ship products at Amazon scale and build the next ones with AI.

Senior Product Manager at GR8 Tech in Belgrade. Seven years in product: an app redesign for 18M daily users at Amazon Ring, an experimentation stack across four regulated EU markets at VBET. Now I run a pipeline of AI agents at work and an agent team on my own products.

How an agent team ships work. Hover any part to see what it does.

GR8 Tech, 2026. In use by my team.

The breakthrough: requests go in, build-ready specs come out, and a person signs every gate.

Product teams lose days turning a client's request into something engineers can build. I designed a pipeline of AI agents that does the heavy part and stops for a human decision wherever judgment matters. It is the first agent-run product workflow on my team.

  1. Raw request

    A client asks for something, in their own words, through whatever channel they like.

  2. Intake agent

    Structures the request, finds what is missing and asks for it.

    1 human gate

  3. Spec pipeline

    Two paths: full requirements or a light ticket. Five reviewer personas critique the draft. Duplicates are caught against the backlog by query and by meaning.

    4 human gates

  4. Readiness checks

    Rubrics run before engineering takes it: product handover, design conformance, contract readiness. Built with an engineer on the team.

    3 rubrics

  5. Build-ready spec

    Every change to the pipeline itself is scored by a critic with fresh context before it is promoted.

    eval-gated

5human gates between request and build
5reviewer personas critique every draft

Nothing ships on the builder's word

On my own products Claude writes the code, and a second agent, Codex, tries to break it. I make the call once the serious problems are gone. This is one real release going through it.

Fig. 1. Release candidate for queue reports on the Alta map, 9 Nov 2026. Replayed from the review documents; nothing here runs live.

Fig. 1How a release gets clearedreal recording
  1. Claude buildsWrites the code and the tests.
  2. Codex reviewsA second agent that didn't write the code looks for what's wrong.
  3. I decideShip it or send it back.

Again, until nothing serious is left.

Problems found per review round

  1. Round 282 serious
  2. Round 372 serious
  3. Round 42none serious

Four rounds in one day. Cleared with no serious problem open.

The two smaller ones went on my launch checklist.

Cleared to ship

See all 11 steps of the recording
  1. Dan frames

    Release candidate for queue reports on the Alta map. It ships only if the evidence holds up under an independent review.

  2. Claude builds

    Release candidate assembled, with a go or no-go recommendation, a launch runbook and a rollback plan.

  3. Codex reviews, round 1: changes requested

    The static review is done. The fresh execution evidence it requires is not there yet.

  4. Claude fixes

    Ran the gates and filed the evidence: test runs, a database migration rehearsal and a preview deployment.

  5. Codex reviews, round 2: changes requested

    8 findings, 2 high.

    • Runbook steps are unsafe or inaccurate.
    • Acceptance claims are stronger than the evidence behind them.
  6. Claude fixes

    Corrected the runbook and qualified the claims.

  7. Codex reviews, round 3: changes requested

    7 findings, 2 high.

    • Advertised execution logs are missing.
    • Preview claims exceed the retained transcript.
    • The acceptance test does not prove that Send is disabled.
  8. Dan decides

    One high finding was about my own rule on where heavy tests may run. That one was mine to settle: the final gates may run on Hermes, guarded.

  9. Claude fixes

    Supplied the missing logs and reconciled the numbers.

  10. Codex reviews, round 4: changes requested

    2 findings, none high.

    • Coverage of the unavailable mode is incomplete.
    • The recommendation still contains contradictory status wording.
  11. Dan decides: conditional go

    No high findings left. The two medium ones became launch conditions.

From the support floor to the product roadmap

I started at Ring in 2017 moderating data and answering support chats. By 2019 I was a product manager there. These are the results I would put my name on.

18Mpeople a day use the Ring dashboard I redesigned
4.5+CSAT after that redesign, the largest in the app's history
2%off support call costs with a chatbot on Amazon Lex
4regulated EU markets on one experimentation stack at VBET
15%more registrations reaching a first deposit at VBET
20+people working to one product ops framework
  1. 2017RingData moderator, support rep, supervisor of 14, then head of learning and development.
  2. 2019RingProduct Manager. Chatbot on Amazon Lex, ML and computer vision features in the app.
  3. 2021Betinvest, Parimatch TechSenior Technical PM. Web and native betting products, two companion apps.
  4. 2022Ring, via SQUADSenior PM. Main dashboard redesign, ML personalization, notifications.
  5. 2025VBETGroup PM, Tier 1 markets. Experimentation stack, product ops, four EU markets.
  6. 2026GR8 TechSenior PM, Platform Product. The agent-run spec pipeline above.

Four results, told as problems you might have

Each card names the general problem first, then what I did about it.

Amazon RingConsumer app at scale

Redesign the screen everyone opens without breaking their habits

Before: every team has a tile, and what you came for is buried in there.

Read the full storyHide the story

The general problem

The home screen of a mature app is the hardest thing to change. Millions of people have muscle memory for it, every team wants a slot on it, and a redesign that tests well can still sink satisfaction the week it ships.

Home screensDashboardsNavigation overhaulsLegacy app redesigns

What I did there

On the Ring app, opened by 18M people a day, I led the largest redesign of the main dashboard in the app's history. It shipped with a satisfaction score above 4.5.

18M daily users4.5+ CSATlargest redesign in the app's history

Context: Ring

Amazon RingAI in a consumer product

Put a model where a queue used to be

Without it, everyone waits in one line for a person, even with the same five questions.

Read the full storyHide the story

The general problem

Support lines and home screens share a problem: most people want one of a few things, and they wait behind everyone else to get it. A model that understands the request can answer the common cases and decide what each person sees first, as long as someone defines what good looks like before it ships.

Customer supportOnboardingPersonalised home screensNotification strategy

What I did there

At Amazon Ring, the home security company, I shipped a support chatbot built on Amazon Lex and ML-driven personalization inside the Ring app, and worked with ML engineers on evaluation criteria and rollout thresholds.

conversational supportML personalization2% off support call costs

Context: Ring, Amazon Lex

VBETExperimentation in regulated markets

Build the testing habit before you argue about features

Turn B on per market

Event tracking you can trust, on Snowplow. Without it every result gets disputed.

Read the full storyHide the story

The general problem

Most product debates are opinions because nobody can run a clean test. Without event tracking you trust, feature flags and one agreed set of KPIs, every launch is a guess and every result gets disputed. Regulated markets make it harder: each country has its own rules on what you may show and to whom.

A/B testing from zeroFeature flaggingKPI governanceMulti-market products

What I did there

At VBET, an online betting and casino operator, I set up the company's experimentation stack from nothing: A/B tests on GrowthBook, event tracking on Snowplow, feature flags and KPI governance, across four regulated EU markets (Netherlands, Romania, Sweden, Denmark).

4 regulated EU marketsGrowthBookSnowplow20+ people on one product ops framework

Context: GrowthBook, Snowplow

Product operationsin use

Make the path from request to spec fast without removing the people

A client asks for something in their own words.

Read the full storyHide the story

The general problem

Every product team has an inbox of requests in other people's words. Turning one into something engineers can build takes days of clarifying, checking for duplicates and writing. Hand that to a model with no checkpoints and you get confident nonsense. Keep it fully manual and the queue never shrinks.

Client-driven roadmapsPlatform teamsSupport-to-product intakeCompliance-heavy specs

What I did there

At GR8 Tech, a platform provider for online betting and gaming operators, I designed a pipeline of AI agents that takes a raw client request to a build-ready spec. Agents structure, draft, critique and check for duplicates. A person signs at five gates. Changes to the pipeline are scored before they are promoted.

5 human gates5 reviewer personas3 readiness rubricsin use by my team

Context: who GR8 Tech is, how the pipeline works

What I build when nobody is asking

Side projects are where I try a method before I bring it to work. Each one starts from a problem I had myself.

ALTA Banka payouts, SerbiaCrisis informationlive

Turn an official notice into a service people can use, in days

The official list of payout points was a PDF of addresses.

Read the full storyHide the story

The general problem

When an institution fails, the facts people need arrive as a PDF: a list of addresses, a deadline, a rule. Under stress nobody wants a document. They want to know where to go, when, and how long it will take. The same gap opens after a bank closure, an airline collapse, a product recall or a flood.

Regulated noticesService outagesRecalls and refundsAny list that should be a map

What I did there

On 30 October 2026 Serbia's central bank revoked the licence of ALTA Banka. Deposits were insured up to €50,000 and would be paid out through another bank's branches. The official list of payout points was a PDF. I built a public map of every payout point in three languages, with queue reports from people standing in line. It was live before the first payout.

  1. 30 OctLicence revoked
  2. 3 NovBankruptcy opened
  3. 6 NovFirst commit
  4. 8 NovMap live
  5. 13 NovPayouts begin
50+ payout points3 languages4 review roundsfree hosting tier

Context: ALTA Banka, what the closure meant for depositors, the deposit insurer's notice, the map

Hermes: Claude + CodexAgent teamsruns at home

Never trust one agent. Make a second one disagree.

Builder→Critic

    A release candidate goes to a critic that did not write it. Run a round.

    Read the full storyHide the story

    The general problem

    An AI agent will tell you its work is done and correct. Often it is neither. The fix is the one software teams already know: the builder does not review its own work. A second agent with no stake in the result reads the evidence, and a person makes the call on what is left.

    AI-assisted engineeringRelease decisionsAudit trailsSmall teams shipping fast

    What I did there

    Hermes is a small computer at home where my agents work. Claude builds, Codex reviews, both report to me, and nothing public depends on it being online. The release in Fig. 1 went through four review rounds on it in one day before I cleared it.

    167 commits197 test files3 agents

    Context: Claude Code, Codex, a recorded review loop

    AnyLinkPersonal knowledgelive

    Saving a link is easy. Finding it when you need it is the product.

    Paste a link

    Paste any link. That is all you do.

    Read the full storyHide the story

    The general problem

    Everyone saves things: bookmarks, messages to self, forty open tabs. Almost nobody goes back, because a pile sorted by date is useless when you need the five links for one task. Folders and tags only work for people who keep them up, and few do.

    BookmarksRead-later listsResearch collectionsTeam link dumps

    What I did there

    AnyLink takes any link you paste, or a bulk import of browser bookmarks and Telegram saved messages, and reads the page for you: title, image, price, read time. I am building the next part now: collections that assemble themselves around what you are doing.

    bookmark importTelegram importon-device text embeddingsbuilt with Claude

    Context: the app

    reclaimAI PC cleanerDeveloper toolconcept

    Say what is eating the disk before deleting any of it

    Quarantine

      example sizes

      Tap an item to see why it is, or is not, safe to remove.

      Read the full storyHide the story

      The general problem

      PC cleaner apps have a trust problem. They scan, show a scary number and delete things you never got to review. What people want is a plain account: what each big chunk of disk is, who put it there, whether anything still uses it, and what it costs to remove.

      Disk cleanupDeveloper machinesIT self-serviceAny tool that deletes things

      What I did there

      reclaim is a housekeeping tool for Windows PCs, aimed at developers and AI tinkerers. Rules find the known junk. A model only classifies what the rules cannot name and writes the explanations; it never picks or runs an action. Cleanup moves files to quarantine, so it can be undone. It is an early build in Go.

      read-only by defaultrules first, AI secondquarantine, not deleteGo, single binary

      Smaller builds

      • Product ops skillsA public pack of Claude Code skills for product ops work.
      • Study booksAgent-written textbooks I made for myself: system design, C2 English, frontier AI for PMs.
      • Reading engineA Telegram bot that writes book summaries.
      • Marketplace watcherWatches Telegram listings for things I want to buy and pings me.
      • Games digestA weekly Telegram post of free and new games.
      • AQI trayThe air quality number in the Windows tray.
      • This siteClaude and Codex built it, Gemini criticised it, I decided.

      Dan Demenskyi

      Senior Product Manager, GR8 Tech, Belgrade
      See LinkedInEmail