Ask MiroFish a question like “how will our users take a 20% price increase?” and, some minutes later, you get back a structured prediction report. Between those two moments sits a pipeline of five distinct stages, and understanding them changes how well you use the tool. This is the full walkthrough — what each stage consumes, what it produces, and where your choices matter.
Stage 1: the seed
Everything begins with what you feed in. At minimum that’s the question itself, written in plain language. Optionally — and this is where runs go from generic to sharp — you attach seed documents: PDF, Markdown, or plain text describing the situation. Announcement drafts, forum threads, stakeholder lists, past incident timelines.
The seed determines the simulation’s entire universe. MiroFish cannot know your community’s inside jokes or your competitor’s pricing unless the seed carries them. A simulation is never smarter than its seed; it is only more thorough with it. That single fact explains most of the difference between a bland run and a revealing one.
If you want the deeper treatment of what makes seed material work, we’ve written a whole piece on knowledge graph seeding.
Stage 2: the knowledge graph
Next, MiroFish reads the seed and extracts structure from it: the people and organizations mentioned, the relationships between them, and the pressures acting on each — who wants what, who answers to whom, who has history with whom. These become nodes and edges in a knowledge graph.
Think of the graph as the scenario’s cast list and wiring diagram at once. It’s not a summary of your documents; it’s an inventory of actors. A supplier mentioned once in a footnote becomes a node that can later act. This stage is also where thin seeds show their cost: few named actors in, few agents out.
Stage 3: the multi-agent simulation
Here is the part that makes MiroFish a simulation tool rather than a summarizer. Each node in the graph is instantiated as an autonomous AI agent with a persona assembled from what the graph knows: role, incentives, relationships, tone. The whole cast is then placed on a simulated social surface — think of it as a synthetic feed — and your scenario’s trigger event is injected.
Then the rounds begin. Agents read what other agents post. They reply, argue, amplify, ignore, and update their positions. A skeptical agent who sees three allies speak up gets bolder; an enthusiastic one surrounded by pushback hedges. None of this is scripted — the group behavior emerges from many small, individually plausible decisions, round after round.
This is the property that no single-pass answer can replicate, and it’s worth understanding on its own; see multi-agent social simulation for the full mechanics. You can also just watch it happen: there’s a recorded end-to-end run on Bilibili that shows the rounds unfolding in real time.
Stage 4: the prediction report
When the configured rounds complete, MiroFish condenses the whole run into a prediction report. A typical report contains an executive summary — the most likely outcome, stated plainly — followed by risk signals the simulation surfaced, the distinct narrative paths the crowd’s conversation took, and follow-up questions the run itself suggests asking.
The report is a synthesis, not a transcript. Hundreds of agent interactions get distilled into the handful of findings a decision-maker actually needs. How to read one critically — which sections to trust most, which to interrogate — is covered in reading a prediction report.
One framing note we repeat everywhere on this journal: the report is exploratory decision support. It shows you reactions you hadn’t considered and the pathways between them. It does not guarantee the future, and the tool never claims to.
Stage 5: the follow-up chat
The run doesn’t end at the report. The simulated world — graph, agents, full interaction history — stays available, and you can question it in an open-ended chat. Ask “what if we had announced on a Friday?”, “which agent turned the tone?”, or “show me the moment the objection went mainstream.” Answers come grounded in the specific simulation you just ran, not in a model’s general instincts.
In practice, experienced users spend as much time here as on the report. The report tells you what happened; the chat lets you ask why, and rehearse variations without rebuilding the world from scratch.
Where runs go wrong, stage by stage
Knowing the pipeline also tells you where to debug a disappointing run, because each failure has a stage-shaped signature.
A report that feels generic — like it could describe any company — is a stage 1 problem: the seed lacked named actors, so the graph filled itself with defaults. A report that gets your situation right but misses an obvious player (the competitor who always comments, the regulator who always notices) is stage 2: the actor never made it into the graph, usually because no seed document mentioned them. If the dynamics feel flat — everyone reacts once and nothing develops — that’s stage 3 territory, typically a scenario trigger too mild to provoke interaction. And if the run seems rich but the report feels thin, don’t re-run at all: that’s what stage 5 is for. The detail is still there in the simulated world; go ask for it.
The habit to build: when a run disappoints, name the stage before changing anything. Nine times out of ten the fix is a better seed, not a different question — and it costs five minutes, not another full run.
The pipeline as a whole
Seed → graph → simulation → report → chat. Each stage’s output is the next stage’s input, which means quality propagates: a well-chosen seed makes a richer graph, which makes more believable agents, which make a report worth interrogating.
The entire system is open source — you can read exactly how each stage is implemented in the MiroFish GitHub repository — and the hosted product runs at mirofish.us, the main MiroFish site. If you’d rather start doing than reading, the practical companion piece is getting started with MiroFish.