I use AI for a lot of things.
Exploring ideas. Comparing architectures. Thinking through product decisions. Debugging something at 2 AM when I probably should have been sleeping.
And honestly, it's extremely useful.
But there is one thing about working with AI that has always bothered me.
Sometimes it agrees with you a little too easily.
You give it an idea.
It sounds reasonable.
The model explains why it's reasonable.
Then you ask for a little more detail, and it gives you even more reasons why your original idea was probably a good one.
And suddenly you're 20 minutes into the conversation with a beautifully written argument for a decision that might have been wrong from the beginning.
That's the problem I wanted to work on.
So I built Crucible.
Crucible is an adaptive decision-review skill for Claude Code. You give it something that actually matters—a technical architecture, a product decision, a plan, a strategy, a recommendation—and instead of simply helping you defend the idea, it tries to pressure-test it.
The interesting part is that it doesn't just throw a bunch of agents at the problem.
That would be easy.
The difficult question was:
How much reasoning is actually necessary before a decision is stable enough to act on?
That question ended up shaping almost everything in Crucible.
The idea behind Crucible
Imagine I ask:
«Should I use architecture A or architecture B?»
A normal AI answer might compare the two and recommend one.
That's useful.
But what if the recommendation depends on one assumption that hasn't been verified?
Or what if the decision is difficult to reverse?
Or what if there's a failure mode that neither option comparison considered?
Or what if the answer only looks good because the model anchored itself to the first idea I mentioned?
That's where I wanted Crucible to behave differently.
The workflow is basically:
Frame the decision → determine how much scrutiny it deserves → verify important claims → challenge the weak point → check the failure mode → decide whether more reasoning is actually useful → stop.
That last part is surprisingly important.
I didn't want to build a system that thinks longer just because it can.
More reasoning is not automatically better.
Sometimes it is.
Sometimes it is just more text.
So I didn't make "14 agents"
Technically, Crucible contains 14 specialist agent definitions.
That sounds impressive on a landing page.
But that isn't really the interesting part.
The interesting part is that Crucible does not use all 14 agents on every question.
There are three review depths:
QUICK, REVIEW, and DEEP.
A simple, reversible decision should stay simple.
A decision with meaningful uncertainty might get a couple of independent perspectives.
A high-downside or difficult-to-reverse decision can get a deeper review with several different lenses plus targeted verification and adversarial analysis.
The router itself is intentionally small.
It doesn't solve the decision.
It first asks something closer to:
ROUTE: QUICK / REVIEW / DEEP
STAKES: low / medium / high
UNCERTAINTY: low / medium / high
REVERSIBILITY: low / medium / high
EXTERNAL_VERIFICATION: yes / no
MAIN_DECISION_VARIABLE:
WHY_EXTRA_WORK_IS_OR_IS_NOT_JUSTIFIED:
NEXT_MINIMUM_STEP:
That separation matters.
The routing layer shouldn't immediately fall in love with a solution.
Its job is to decide whether the problem deserves more work.
The part I care about most: anti-anchoring
One of the easiest ways for an AI system to become confidently wrong is to anchor too early.
Suppose the first conclusion is:
«"Architecture A is probably better."»
Now imagine five different agents are asked to review that conclusion using the same assumptions and the same evidence.
They might all agree.
That doesn't necessarily mean we've found five independent confirmations.
We might have just created a very sophisticated echo chamber.
So Crucible treats independence as a process problem, not a headcount problem.
Different lenses are supposed to be formed before the leading conclusion becomes an anchor.
That is why one of the principles behind the project is:
More agents ≠ more truth.
Fourteen agents agreeing with the same unverified premise is still one bad premise.
Evidence gets a different treatment too
Another thing I wanted to avoid was treating every sentence in a recommendation as equally important.
They're not.
Some statements are just supporting details.
Others actually determine the decision.
Those are the claims that deserve verification.
Crucible therefore separates decision-critical evidence from everything else and can escalate specific claims for verification rather than launching a giant research process for the entire answer.
That sounds like a small design choice.
It isn't.
It changes how much unnecessary work the system does.
The goal isn't:
«"Research everything."»
The goal is:
«"Find the thing that could change the decision, and verify that."»
That idea shows up repeatedly throughout the project—in the routing rules, evidence gates, verification planning, and quality-control layer.
**Failure-first instead of risk-list-first
**
There's another detail I really liked while building it.
When people review a decision, they often produce a list of risks.
Ten risks.
Fifteen risks.
Maybe twenty, just to be safe.
It looks thorough.
But most of them don't actually matter.
Crucible instead tries to identify the single highest-impact plausible failure mode—the thing most capable of changing the action.
Then it asks what would trigger that failure, what signal we'd see, what mitigation exists, and what risk remains.
This makes a review much more actionable.
A decision isn't improved because you wrote down twenty scary things.
It's improved when you find the one that can actually change what you should do next.
**
And then there's the stopping rule
**
This might be my favorite part of the whole project.
AI systems have a natural tendency to keep going.
More analysis.
Another angle.
Another comparison.
Another caveat.
Another paragraph explaining why the previous paragraph matters.
At some point, more reasoning stops being useful.
So Crucible has explicit stopping rules.
If the recommendation is stable...
If the remaining uncertainty can't change the action...
If the next verification step is redundant...
Or if a staged action can resolve the uncertainty more cheaply...
stop.
I wanted Crucible to treat compute and attention as something worth spending deliberately.
That's why the internal principle is essentially:
«Do another check only when the result could plausibly change the action.»
The architecture is deliberately boring
The project isn't a huge application with a database, API layer, queue system, or separate inference backend.
It's a Claude Code plugin and marketplace package.
The core behavior lives in the skill definition and reference modules.
The specialist agents are separated by responsibility.
The repository also contains the testing, benchmark, validation, and ledger infrastructure around that core.
The project structure looks roughly like this:
crucible/
├── .claude-plugin/
│ ├── plugin.json
│ └── marketplace.json
├── agents/
├── benchmarks/
├── scripts/
├── skills/
│ └── crucible/
│ ├── SKILL.md
│ └── references/
├── tests/
├── README.md
├── LICENSE
├── SECURITY.md
└── CONTRIBUTING.md
The nice thing about this approach is that the reasoning methodology isn't hidden inside some giant application.
You can actually read it.
The routing rules are documented.
The evidence rules are documented.
The adversarial methodology is documented.
The output contract is documented.
The quality gate is documented.
The decision ledger is documented.
That was intentional.
I wanted the system itself to be inspectable.
I also didn't want "benchmarks" to become marketing numbers
This is another thing I was fairly strict about.
It's very easy to create an offline benchmark, get a perfect score, and put "100% accuracy" on a website.
That would be misleading here.
Crucible has routing tests, golden evaluation materials, adversarial cases, stress tests, package validation, and benchmark plumbing.
But an offline benchmark that feeds expected outputs back into a scorer doesn't prove that a live language model will make the right decision.
So the project explicitly distinguishes engineering/regression validation from live model quality.
The README even warns against interpreting the offline score as proof of model accuracy.
I think that's important for a project whose entire purpose is making AI reasoning more trustworthy.
If I'm going to build something about evidence, I should probably apply the same standard to my own claims.
I tested the release locally
For the version I'm releasing as v1.0.0, I didn't just look at the files and call it done.
I ran the bundled standalone test suite against the release package.
The result:
=== 84 passed, 0 failed ===
The routing fixtures also passed completely:
8/8 routing fixtures matched the reference heuristic.
I ran the stress harness with 50 iterations covering normal cases, missing evidence, malformed payloads, timeouts, adapter errors, and contradictions.
The result was:
unexpected_failures: 0
The repository also has CI configured to run the test suite, validator, routing checks, benchmark contracts, golden benchmark contract, stress harness, syntax checks, and additional release checks.
Those numbers don't mean Crucible is magically correct.
They mean the software around the methodology is actually being tested.
And that's the distinction I want to keep.
There's a Decision Ledger too
One feature I almost considered leaving out was the local decision ledger.
Crucible can record a decision, its reasoning, the main risk, the condition that would change the recommendation, and eventually the outcome.
That means a decision doesn't necessarily disappear once the conversation ends.
Over time, you can look back at decisions and compare what you believed would happen with what actually happened.
I like this because it changes decision-making from:
«"I think this is the right choice."»
into something closer to:
«"Here's what I decided, here's why, here's what I was uncertain about, and here's what would have changed my mind."»
That's much more useful six months later.
The ledger is local rather than requiring a hosted database, which was also deliberate.
- What I actually built
So, after all of this, what is Crucible?
It's not a chatbot.
It's not a "14 agents argue with each other" demo.
It's not a majority-vote truth machine.
And it's definitely not a guarantee that an AI will always make the correct decision.
It's a decision-pressure-testing layer for Claude Code.
You can install it from the Claude Code marketplace and run:
/plugin marketplace add smshahbaj/crucible
/plugin install crucible@crucible-marketplace
Then:
/crucible Pressure-test this decision before I commit:
should we choose architecture A or architecture B?
Normal usage doesn't require a separate database or model API key. The optional live evaluation path is separate from normal plugin operation.
Why I built it
I don't think AI needs to become more agreeable.
It already is.
I think it needs to become better at telling us:
"Wait. Before you do that, here's the part of your reasoning I'd actually worry about."
That's the behavior I wanted.
Not endless analysis.
Not fake certainty.
Not a wall of agent output.
Just enough intelligent resistance to catch the thing you might otherwise miss.
That's Crucible.
Verify. Challenge. Decide.
The project is open source under the MIT license.
GitHub: Crucible Repo
Website: Crucible
If you try it, I'd genuinely like to know where it breaks, where it's too cautious, where it's too aggressive, and especially where it changes your mind.
Because if a decision-pressure-testing tool can't survive people trying to pressure-test itself, then I probably built the wrong thing.
Top comments (0)