← Projects

Niulai Squad · End-to-End Product

Four-Agent Decision & Publishing System

A four-Agent Web3 interaction system: watch on-chain market events become a replayable character story in a read-only public demo.

Four Agent characters in the shared decision scene
Select a capture to open the original image.
Open live read-only demo ↗View public repository ↗

The case in 30 seconds

Problem
Turn market events into a replayable four-Agent story while keeping facts, dialogue and real actions separate.
My role
Define the product, voting and permission rules; review failures and approve releases.
Result
A read-only public demo backed by separately controlled execution and publishing.
Evidence
779/779 tests at the accepted 29 August 2026 baseline, plus controlled real-action acceptance checks.

Product walkthrough

Watch an event become a shared story.

The public demo is read-only. Viewing the story does not authorize trades or publishing.

  1. 01

    Follow an event

    Public market evidence enters one recorded timeline.

  2. 02

    Watch four reactions

    Four characters respond in distinct voices to the same recorded state.

  3. 03

    Replay the story

    Follow the recorded result and dialogue without controlling real actions.

Controlled multi-Agent systemFour roles · separated authority 01 · In-game decision layer Four Agent characters in the shared decision scene Four roles vote before the shared result. 02 · Agent dialogue window Chinese dialogue from four Agents reacting to a recorded event Distinct voices react to one recorded state.

How to read these captures

The game scene shows the four roles together. The dialogue window shows their different reactions to the same recorded event; it is not four independent authorizations to act.

Votes are fixed before model dialogue. Execution and publishing still require their own permission checks.

Select either screenshot to open it at full size.

One public observer described the conversation interface as live and interactive. This is an informal observation, not a customer testimonial or formal user research. Open public post ↗

The product problem

Market monitoring can surface metrics, but it does not naturally create an entertaining, replayable story—and adding models can easily blur facts, opinions, decisions and external permissions. I designed the product so every sourced candidate, vote, lifecycle result, role reaction and channel record remains addressable from one event history.

The central product decision was to separate random choice from model expression, and public presentation from money and publishing authority. I remain responsible for the product direction, architecture boundaries, strategy revisions, failure review, release decisions and full-flow acceptance.

Three product decisions

  1. 01

    One shared timeline

    Keep evidence, votes, results and dialogue addressable from the same event history.

  2. 02

    Decide before dialogue

    Freeze the four votes before models narrate the outcome.

  3. 03

    Separate viewing from authority

    Keep the public demo read-only; execution and publishing require separate server-side gates.

Four roles

Lark

Read-only discovery

Finds public GMGN hotspot candidates and records provenance, freshness and evidence labels. It can nominate a Case; it cannot decide or execute alone.

Niulai

Vote · gated execution

Votes with the other three Agents. In the show it records paper outcomes; a separate server-side worker may consume an eligible decision only after every execution gate passes.

Niulai Mama

Controlled X publishing

Turns canonical lifecycle events and validated room dialogue into X content. Lifecycle and editorial publishing use narrow, idempotent workers with explicit activation and stop boundaries.

Baola

Controlled Square publishing

Builds Binance Square posts from the same lifecycle evidence. A standing entry/exit publisher is enabled, while its first natural lifecycle-event UAT remains explicitly pending.

Decision & control map

One timeline, with every authority boundary visible.

The system keeps evidence, decision, expression and external action separate. A model can narrate a frozen outcome, but it cannot invent the evidence or rewrite the decision.

  1. 01
    Read-only signalsPublic sources with provenance and freshness
  2. 02
    Canonical timelineOne addressable history for each Case
  3. 03
    Eligibility & evidenceRules decide whether a round may open
  4. 04
    Four frozen votesIndependent random choices recorded before dialogue
  5. 05
    Business decision3-of-4 or 4-of-4 becomes the fixed result
  6. 06
    Permission gateServer-only checks isolate external authority
  7. 07
    Act or stopExecute, publish or fail closed
  8. 08
    Audit & recoveryReceipts, lifecycle events and correction evidence return to the timeline

Failure becomes evidence

Recovery without rewriting history.

An unexpected asset-unit projection exposed a gap between a receipt and its interpretation. Instead of patching the displayed result, I used the incident to tighten the product rule and re-accept the affected scope.

  1. ObservedUnexpected projection
  2. TracedReceipt interpretation
  3. BoundedTighter evidence rule
  4. ProtectedRegression coverage
  5. Re-runControlled lifecycle
  6. AcceptedScoped re-acceptance

What is already evidenced

  1. 01

    Decision and expression are separated

    Models speak only after the four random votes are frozen. A model timeout, fallback or weak line cannot alter candidate eligibility, the vote or execution authority.

  2. 02

    Controlled real lifecycles were validated

    The frozen baseline records three funded route UATs, real TP, SL and time-exit outcomes, one confirmed-revert recovery path, and zero-exposure closure checks.

  3. 03

    The technical baseline is frozen and deployed

    The Owner-accepted 29 August 2026 baseline recorded 779/779 automated tests, full validation and a verified responsive read-only deployment.

  4. 04

    Publishing has its own control plane

    Real X entry/exit posts were validated. Later evidence adds a bounded X editorial cadence and a standing Square lifecycle service without granting general social-account authority.

  5. 05

    Failures become product evidence

    A real asset-unit projection error was traced to receipt interpretation, corrected with stricter evidence rules and regression tests, then re-accepted without rewriting unsupported history.

External signal

Early public reactions.

Contribution

What I owned

  • Product purpose, four-Agent structure and single-timeline architecture
  • Voting, strategy revisions and permission boundaries
  • Go / no-go decisions for real actions and public release
  • Failure review, iterative full-flow UAT and milestone acceptance

What Agents accelerated

  • Substantial implementation, tests and evidence records
  • Provider adapters, isolated workers and regression checks
  • Incident diagnosis and recovery-path implementation
  • Deployment and operating tasks inside explicit project rules

Status and boundary

The accepted technical baseline is preserved; the product remains in active operation and development.

Post-baseline work has added a controlled project-token lifecycle, a bounded X editorial cadence and standing Square lifecycle publishing. These are separately evidenced increments, not a claim of unrestricted autonomy.

The public website is a read-only view and never receives the protected signer. I do not claim long-term unattended reliability, formal SLA, verified user adoption, revenue or business impact; unified cost and stable-window operating metrics remain incomplete.

The project is an unofficial fan-parody work and does not claim an official relationship, cooperation, sponsorship or endorsement. Public portfolio material excludes credentials, private infrastructure, raw provider responses and sensitive transaction data.

Compare another product shape

See the completed core-playability game case.

FightGame shows how the same product-direction and acceptance role applies to a branching multiplayer product.

View FightGameAll projects