← All case studies Case study · Agent architecture

simagent: intent in, architecture proven

Most teams pick an agent architecture first and hope it holds. simagent turns that around. You write the intent, the lab simulates competing architectures against adversarial scenarios, and it recommends the smallest design that reliably does the job.

Stage Design specification Output Vendor-neutral blueprint Method RepoGenics

recommendation.txt

Recommended Architecture
────────────────────────
Architecture complexity: 2/10
✓ Pre-commit deterministic hook
✓ Coverage analysis skill
✓ PR evaluation skill
✓ CI workflow
✗ Coordinator      unnecessary
✗ Subagents        unnecessary
✗ MCP              unnecessary
✗ Persistent state unnecessary

The target output for a test-coverage intent, as written in the design spec. The workflow is mostly deterministic; AI earns its place only where coverage needs interpreting.

Input: a written intent with goal, inputs, outputs and success criteria

Candidate architectures, from plain code up to coordinator plus workers

Scenario types. Only one of them is the happy path

Internal capabilities, from intent analysis to blueprint generation

The problem

Agent architecture is usually a guess

Does this problem deserve another agent?~~How many agents can we put in here?~~

A team decides it needs “four agents, two skills and three hooks” before anyone has tested whether one skill and a hook would do. Multi-agent systems do beat simpler designs on the right, highly parallel work. They also cost more, run slower, burn more context and are harder to maintain, and nobody measured whether the trade was worth it.

simagent was written to make that decision with evidence, and to make it a permanent step in engineering rather than a one-off debate:

Treat every architecture as a hypothesis, including the one the model proposes first.
Test failure cases on purpose, not just the happy path.
Judge outcomes, so different valid execution paths can all pass.
Add complexity only when simulation proves it is needed.
Stay vendor-neutral across Copilot, Claude, Cursor, Gemini and whatever comes next.

How it was designed

The Repogenic Loop, applied to architecture itself

In RepoGenics, AI makes the guesses, tests pick the winners and the repo remembers. simagent runs the same loop one level up: the thing evolving is the shape of the agent system.

Intent

The selective pressure. Goal, inputs, outputs, success criteria, constraints and expected failure modes, written before any design.

Variation

The Architecture Generator proposes competing candidates instead of trusting the first design it invents.

Selection

Every candidate runs every scenario. The evaluator scores outcomes, cost and burden; the weakest shapes are rejected with reasons.

Inheritance

The proven architecture becomes a blueprint in the repo, and failure clusters feed the next intent, so lessons are not relearned.

Guardrails

Non-bypassable policies become deterministic hooks. The minimum sufficient rule keeps unneeded agents out.

The core idea

An architecture minimizer, not an agent generator

The lab starts at the bottom of the ladder and climbs only when the scenarios demand it. Sometimes the right answer is a single skill. Sometimes it is ordinary deterministic code.

Five candidate architectures as rising steps: deterministic code at complexity 1, single skill at 2, skill plus deterministic hook at 3 (recommended in the worked example), agent plus tools and skills at 6, and coordinator plus parallel workers at 9 — Each step up adds capability and adds cost, latency, context use and maintenance. Simulation has to justify the climb.

Inside the lab

Seven capabilities, one direction of travel

An intent goes in on the left. A proven architecture, its evidence and a generated repository come out on the right. When simulations fail, the Failure Analyst sends revised hypotheses back to the start.

1 · ANALYZE

Intent Analyzer

Captures goal, inputs, outputs, success criteria, constraints, environment and expected failure modes.

2 · HYPOTHESIZE

Architecture Generator

Produces competing candidates, from a single skill to a coordinator with specialized workers.

3 · STRESS

Scenario Generator

Builds realistic and adversarial cases: bad input, tool timeouts, agent loops, context exhaustion, security violations.

4 · SIMULATE

Simulation Runner

Runs every candidate across every scenario in a sandbox with real prompts, mock MCP servers and failure injection.

5 · JUDGE

Evaluator

Scores outcomes, not transcripts: quality, reliability, context and tool efficiency, cost, latency, burden.

6 · EXPLAIN

Failure Analyst

Clusters failures, names root causes and recommends architecture changes, so the lab teaches as well as grades.

7 · GENERATE

Blueprint Generator

Writes the proven design into a runner’s layout. The architecture comes first; the vendor format comes last.

The experiment

Hammer every candidate the same way

Fifteen scenario types in five families. A design that only survives the happy path is not a design you can ship. Runs scale from 20 to 50 to 100 per cell as confidence is needed.

Matrix of five candidate architectures against fifteen scenarios grouped as baseline, intent and input, repository shape, tools, and agent behavior and safety; each cell holds a batch of sandboxed runs — The experiment design: which runs happen. Results fill this grid once the Simulation Runner is built.

The teaching part

A failure report that tells you what to change

Instead of a red FAILED, the analyst explains the cluster. In the spec’s worked example, a large share of failures traced back to one decision: the coordinator handed every worker the whole repository. The fix is an architecture change, and the lab re-runs to prove it.

Before and after: on the left a coordinator sends full repository context to three workers, each exceeding its context budget; on the right a coordinator sends a structured task contract and each worker receives only scoped context such as tests and diff, coverage report, or critical paths — Worked example from the design spec, used to show the analyst’s output format.

“This should be a skill”

The analyst can argue down as well as up: the task has no real decisions, so an agent loop only adds cost.

“This should be a hook”

The rule is a non-bypassable policy, so it belongs in deterministic code, not in a prompt the model may skip.

“These should be parallel”

The sub-tasks are genuinely independent, so parallel workers improve completion time and keep each context clean.

The bigger shift

From methodology to feedback system

Intent → Context → Architecture → Production becomes a loop. Simulation, evaluation and learning are now stages, and each pass feeds a better intent and a better architecture.

Circular lifecycle: Intent, Simulation, Architecture, Context, Execution, Evaluation, Learning, Improved intent and architecture, then back to Intent; Simulation, Evaluation and Learning are highlighted as the stages simagent adds

The deliverable

One proven architecture, any runner

Once a design is proven, the Blueprint Generator writes it in the layout of the team’s tool. Switching runners means regenerating the blueprint, not re-deciding the architecture.

GitHub Copilot

.github/
├── intents/
├── skills/
├── agents/
├── prompts/
├── hooks/
├── workflows/
├── instructions/
└── evals/

Claude Code

.claude/
├── skills/
├── agents/
├── hooks/
└── commands/

Cursor, Gemini and future runners
follow the same pattern.

Grounded in practice

Packaging what frontier labs already do

simagent is not betting on future AI. The pieces are practices Anthropic has described publicly; simagent wraps them around an intent-first decision about architecture.

Simulate before production. Anthropic’s write-up of its multi-agent research system describes testing agents in simulation with the real prompts and tools, and using a tool-testing agent to rewrite tool descriptions after observing failures. It also reports that multi-agent runs used roughly 15× the tokens of a chat. Read the post

Generate scenarios, judge at scale. Bloom, Anthropic’s open-source evaluation framework, generates scenarios, runs rollouts with simulated users and tools, and judges the results. Read about Bloom

The evidence

Where it stands today

Intent and design written	DONEThe repository’s README and intent document define the lifecycle, the minimum sufficient architecture principle and the design goals.
Seven capabilities specified	DONEEach capability has its inputs, outputs and responsibilities written down, from Intent Analyzer to Blueprint Generator.
Scenario taxonomy	DONEFifteen scenario types are named, covering input, repository shape, tool failures and agent behavior.
Worked example	DESIGNEDThe test-coverage intent and its recommended output show the target format. They are a specification, not a measured run.
Simulation Runner and Evaluator	NOT YETThe sandbox, mock MCP servers, failure injection and scoring are the next build. No success rates are claimed until they run.
Blueprint Generator	NOT YETThe target layouts for Copilot and Claude Code are defined; generation is not implemented.

Why it matters

Fewer agents, chosen on purpose

Spend follows evidence

Token cost, latency and maintenance are paid only where the scenarios show a simpler design fails.

Architecture you can defend

Every recommendation comes with the rejected candidates and the failure clusters that ruled them out.

Portable by default

The decision is made once, independent of vendor, and expressed in whichever runner the team uses.

Intent-driven engineeringMinimum sufficient architectureOutcome-based evaluationAdversarial scenariosFailure clusteringMock MCP serversSkillsHooksSubagentsVendor-neutral blueprints

Don’t guess your agent architecture. Simulate it.

Bring an intent. Leave with the smallest architecture that meets it, the evidence behind the choice, and a repository layout your team’s runner understands.

Talk to Repogenic

simagent is at the design-specification stage. The recommendation shown above is the target output from the spec, not a measured result. View the repository