Compete Mode and Character Agents: Two AI Teams, One Issue, Different PRs

One AI agent solves your ticket. Two AI teams compete for it. Which one would you ship?

In our last Forge post we introduced Simple Container’s multi-agent platform that transforms a GitHub issue into a PR through a pipeline of PM → Architect → Developer → QA → Reviewer.

Today, we share what changed when we stopped treating those five agents as interchangeable parts and started treating them as characters — with distinct personalities, measurable growth, and memory that survives across runs.

Characters, not roles

Each Forge agent now has:

A persona that persists across runs. “Alex, mid-level architect, picks boring patterns” produces different designs from “Falcon, over-engineering consultant, wants Kafka for a 100-visit page” — even on the same brief.
A 10-stat RPG character sheet (Coding, Debugging, Systems Thinking, Communication, Speed, Quality, Creativity, Attention to Detail, Technical Breadth, Strategic Thinking). Operators allocate one stat point per level above 1, the same way you’d build out a tabletop character.
Auto-derived performance metrics computed from real turn outcomes — speed, frugality, reliability, experience. The character sheet is what an operator wants the character to be; the performance bars are what the character has actually proven on past work.
XP and levels. Every finished turn earns XP; level milestones unlock more stat points, additional tools, and larger memory caps.
Per-character memory that accumulates across runs. A character that ran ten issues remembers the lessons from each one and brings them into the next conversation. If a character once recommended a complex stack and got a “this is overkill” comment back, the next run sees that lesson in their system prompt.

Compete mode

A team in Forge is just a list of characters bound to roles. Drop two team IDs on the same issue:

forge-teams: alpha-team-id, beta-team-id

…and Forge fans out two parallel pipelines — each on its own branch, each opening its own PR. Same brief, different teams, side by side.

We ran a Mars Real Estate landing page brief through two newly-built teams:

Alpha Team — Serg (non-technical PM, broker instincts) → Falcon (over-engineering architect) → Daizy (faithful junior dev).
Beta Team — John (energetic novice PM) → Aleksander (hedging product-leaning architect) → Dan (frontend-first junior).

Same brief. Different teams. Different PRs.

Falcon’s architecture document proposed “this design scales horizontally to 10M daily visitors” — for a fictional landing page. That’s not a model failure. That’s a character doing exactly what their persona says: over-engineering with confidence.

What it unlocks

Diverse solutions side-by-side, not one model’s first guess. The most senior and the most enthusiastic team don’t always agree. Now you can see both, on the same issue, and pick.
Auditable team composition — assign characters to problems based on their stats and history, not on which prompt-template you happened to clone first.
Continuous improvement loops — characters that succeed on one issue carry that win into the next. The system gets smarter not because the model upgraded, but because the cast did.

What’s next

Memory-driven agent selection. Auto-assign a character to a new issue based on their prior wins on similar work.
Character marketplace. Share, fork, and remix characters across organizations.
Cross-team learning. Let a senior character’s accumulated memory become a teaching corpus for a junior on the same team.

Forge is no longer just a multi-agent pipeline. It’s a small team of distinct AI characters that grow with your codebase.

If you’re building anything that uses LLM agents at scale and you’ve felt the “every agent sounds the same” problem — let’s talk .