Artificer Crucible — in development
AI coding agents can generate code. Artificer Crucible is the turnkey harness being built to refine that raw output into software your team can trust — structured context and specs, verification gates, human approval boundaries, and a record that makes every run accountable.
Why the harness matters
The model proposes. The harness determines what is permitted, verified, recorded, and ultimately allowed to ship. Most agent failures are not model failures; they are harness failures — defects in the context, specs, verification, and guardrails surrounding the model.
Agents need the right context, specs that preserve intent, and reusable skills that guide them toward a team's real patterns. They need verification gates, approval boundaries, observability, cost controls, and feedback loops that turn mistakes into a stronger harness over time. That surrounding system is the harness — and without it, teams get plausible code, context drift, weak verification, and work that is hard to trust after the fact.
Artificer Crucible is being built to be that surrounding system, delivered as one product: the managed path from intent to verified change, so teams do not have to assemble and maintain the orchestration stack themselves.
Its Initiative-Driven Development foundation is designed for work that outgrows a single prompt or coding session: research that grounds decisions before any code is written, plans and specs that preserve intent across larger initiatives, and a human in the loop from the first step.
Product, not platform
Frameworks give teams building blocks. Artificer Crucible is being built to run the governed process around them — strong defaults for brownfield software work, adapted to the prompts, skills, standards, and workflows your team already trusts — so adopting agents does not become another internal platform project.
Turnkey does not mean generic. It means your team does not have to build and maintain the harness itself.
Plenty of tools will generate more software, faster. A crucible exists to prove it.
The structure agents need, adapted to the way your team delivers software.
What we're building
Intent → Plan → Approval → Change → Verification → Evidence
This loop is the vision the harness is being built to run — a human in the loop, every step legible.
A meaningful unit of work — an IDD task or the team’s own delivery unit — enters the harness and is broken into inspectable pieces, not handed off as one opaque prompt.
Research comes before code — Investigations that compare options and record decisions, Research Supplements that capture expensive context — then a plan proposed against the specs and ADRs the harness already holds, with a human gate from this first step, not just at code review.
A person reviews and approves at the boundaries the team defines. Work cannot cross a configured approval boundary without human consent.
The approved plan is implemented and driven through the verification gates configured for the codebase — in the appropriate execution environment — ending in a reviewable change.
Every step is legible in real time and after the fact — cost, model, tools, and actions recorded against the unit of work it belongs to.
The product vision
Artificer Crucible is in development. The five foundations below describe what we're building — not shipped features. Together they turn the harness around the model into one coherent system: a crucible for agent work.
Adopt agents without building the orchestration stack yourself.
The whole harness — context, verification, approvals, observability — is being built as one managed product rather than assembled as bespoke internal tooling.
Readiness for the codebase you actually have.
Most codebases are not ready for agents. The on-ramp we're building turns a brownfield codebase into one the harness can work in reliably — and where a team already has strong conventions, it preserves and encodes them rather than replacing them.
Verification should run where the code and data are allowed to run.
Artificer Crucible is being designed to support different execution boundaries across the development lifecycle — analysis, builds, tests, and hands-on review each in an appropriate environment. Not one prescribed topology, but a verification path that fits the codebase's security and operational constraints.
Agent work needs a durable structure when it spans more than one prompt, session, or pull request.
Initiative-Driven Development is that structure — the reference operating model behind Artificer Crucible's defaults and the approach we use ourselves: work decomposed into initiatives, milestones, phases, and tasks; specs and ADRs that preserve intent; verification gates before code lands; and human-approval boundaries where judgment matters. It gives the product a strong default structure without making that structure a mandate.
That structure is being built to start before any code is written: Investigations that compare options and record decisions, Research Supplements that capture expensive context once, and human approval gates from planning onward.
Every review, failure, and successful pattern should strengthen the next run.
IDD treats the harness's feedback sensors — agent instructions, linters, static-analysis policies, tests, CI, and PR-review gates — as deliverables that evolve, not one-time setup. The aim is a living harness: review feedback becomes better guidance, failed checks become stronger guardrails, repeated fixes become reusable skills, and successful patterns become golden paths — explicit and inspectable, never an opaque learning loop.
One place to answer "what is happening with this initiative right now?"
Two layers, both tied to meaningful units of work. Agent observability is being built to make every run inspectable in real time and after the fact; project observability rolls that up into a live dashboard for leads and project managers by tying work back to delivery systems such as GitHub and Jira.
The cost and value of agent work, treated as a first-class dimension.
As agent usage scales, token spend stops being an experimental line item and becomes an operating cost. Agent Economics is being built to make that cost legible at the level of meaningful units of work — IDD tasks and phases, or the team's own delivery structure — and it is about optimization, not only limits.
Built into the workflow
These controls are being designed to make observability and economics operational — tying budgets, approvals, telemetry, and forensic records to the units of work teams actually manage.
Cost and time caps designed to attach to each meaningful unit of work — enforced where the team reviews and approves, not one opaque account-wide ceiling.
Enforcement built to escalate: a soft stop with a warning as a unit of work nears its budget, then a hard kill switch that halts the run before spend runs away.
Agent behavior designed to be reviewable evidence — exactly which tools and actions were invoked, and when, for post-incident and security review.
No black box: token spend, model selection, tool calls, and turns designed to stream in real time as work unfolds — and to replay after the fact.
Human approval built in as a boundary, not an afterthought — work cannot cross an approval point your team has configured without consent.
Agentic PR review, static analysis, linters, and CI gates wired per project as evolving deliverables — designed to catch mistakes early and to tighten as the team refines them.
Bring us the codebase or workflow your team does not yet trust agents to handle. Artificer Crucible is in development — register your interest in the pilot and help shape it around the realities of production software work. The goal is not unattended code generation. It is accountable software delivery.
