Multi-Agentic Memecoin Generation System

Agent team debating, selecting and deploying a memecoin concept

Screens from the running system

Consensus round in the terminal: the agent compares candidate concepts, explains its selection, drafts the launch post and restates the result in the required format.
Execution stage: the designer agent returns a validated token image URL and the deployer calls deploy_token with the agreed name, ticker and description; the Solscan transaction link is printed below.
Earlier in the same run, with agents proposing candidate token concepts.
Reasoning steps streaming to the console as the agents work toward a decision.

01 Problem What was actually hard

Launching a token is not one task, it is six: come up with candidate concepts, argue them down to one, justify the choice, produce artwork, write copy that reads like a person wrote it, and execute the on-chain deployment. A single prompt handles none of these well, because each step needs a different objective and each step's output is the next step's input. The design problem was making a group of agents converge — reach an actual decision and hand a structured, machine-readable result to the next stage — rather than generating text at each other indefinitely.

02 Data Sourcing and preparation

The system does not train a model; it constrains one. The work was in the contract between stages: an explicit output schema (final name, ticker, description, launch post) that the consensus round must fill exactly, and validation on the way out of every stage — the image URL is checked before the deployer is allowed to use it, the ticker is checked for shape before it reaches the chain. Prompt scaffolding gives each agent a named role and a numbered task list, so its reasoning is inspectable in the transcript instead of hidden.

03 Models Evaluated, kept, cut

6 evaluated 5 kept 1 cut

Kept 5

Role-scoped LLM agents (ideation, critic, designer, deployer)
Distinct system prompt and objective per role; the critic is what forces convergence
Structured consensus round
Final round must emit an exact template — this is what makes the handoff machine-readable
DALL·E token imagery
Designer agent commissions the coin art and returns a URL the deployer can validate
X (Twitter) API
Launch post published from the copy the agents agreed on
pump.fun deployment
`deploy_token(...)` closes the loop; the transaction hash comes back into the transcript

Cut 1

Single-prompt generation
One model asked to do all six jobs produced plausible copy and unusable structured output

04 Architecture How it fits together

The run is a staged conversation. Ideation agents propose candidate concepts; a comparison round scores them against how they would land with the target community; a consensus round picks one and is required to restate it in a fixed format — final name, final ticker, final description, final launch post. That structured block is the interface to execution: a designer agent is handed the concept and returns a generated token image, the URL is validated, and the deployer agent calls `deploy_token(token_image_url, name, ticker, description, post_text)`. The resulting transaction is echoed back into the transcript as a Solscan link, so a run is auditable end to end from prompt to on-chain artefact.

05 Production Deployment and operation

Operated as a terminal application with the full agent transcript streamed to the console — deliberately, because the interesting failure mode is not a crash but a bad decision, and you can only see that in the reasoning. Each stage is separately re-runnable, so a rejected concept does not force a restart from the first prompt.

06 Deep dive The long version, in full

Problem

A token launch is a pipeline of judgement calls, not a single generation. Concepts have to be proposed, compared, and cut; the surviving one has to be justified; artwork has to exist before deployment can reference it; the launch copy has to read like a person wrote it; and the deployment itself has to receive clean, typed arguments.

Handing all of that to one prompt fails in a specific way. The prose comes back fine. The structure does not. The deployer needs a ticker, a name, a description and an image URL as separate, validated fields — and a single free-form completion will not reliably produce them, because nothing in the objective forces it to.

Approach

Split the work by role, and make the last conversational stage produce a machine-readable artefact.

Ideation agents propose candidates independently, so the first round is genuinely divergent rather than the model agreeing with its own opening idea.
A comparison round scores the candidates explicitly — the transcript shows the reasoning, so a bad selection is diagnosable after the fact.
A consensus round is constrained to restate the winner in an exact template. This is the seam between conversation and execution.
A designer agent takes the agreed concept and produces the token image, returning a URL that is validated before anything downstream is allowed to use it.
A deployer agent calls the deployment function with typed arguments and reports the resulting transaction.

What showing the reasoning buys you

The whole run streams to the terminal, including each agent’s numbered reasoning steps. That is not decoration. In an agent system the expensive failure is not an exception — it is a confidently wrong decision several stages upstream that only becomes visible when the on-chain artefact is wrong. Rendering the intermediate reasoning makes that inspectable, and makes each stage independently re-runnable rather than forcing a restart from the first prompt.

Stack

Models & inference What does the thinking
- Multi-agent orchestration
- LLM tool / function calling
- DALL·E image generation
Runtime & services What holds the connection open
- Python (asyncio)
Interfaces & integrations What people and other systems touch
- X (Twitter) API
- Solana (pump.fun deployment)
- Solscan (transaction verification)

Papers & models

Published work this was built on. Every link verified live.