Your Autonomous Coding Engine
Your coding agent isn't unreliable.
The process around it is.
Most teams fix the model. Arcwright fixes the process: the harness that prepares it, the loop that validates it, and the graph that controls every step.
Harness
Context Injection
You've been burned enough times to have a theory. You upgraded the model, refined the prompt, tried a different tool — and the output is still inconsistent. Not always wrong. Just unpredictable in a way you can't systematically fix.
The root cause isn't model quality. It's context quality. When you ask an agent to implement a feature, it has no idea how your project is structured, what decisions were made last sprint, which patterns are intentional, or what "done" actually means in your codebase. It's operating with a fraction of the context it needs — and filling the gap with plausible-sounding guesses.
Context injection is the practice of engineering exactly what gets assembled before the model is ever invoked. Not ad-hoc clipboard dumps — a structured, reproducible pipeline that gathers the right architectural specs, recent decisions, relevant file summaries, and task-specific constraints into a context package built specifically for the task at hand. The model stays the same. The output reliability changes dramatically.
Capability Map 9 implemented · 3 roadmap
| Feature | Description | Status |
|---|---|---|
| Context Injection | Structured context assembly from story specs, FR/NFR/architecture refs — not an ad-hoc clipboard dump | Implemented |
| Code-Based Retrieval | Regex-driven reference extraction; no model call to find context, model fires once with evidence already assembled | Implemented |
| Filesystem Sandbox | Path validation enforces project-root boundary; blocks traversal and symlink escapes | Implemented |
| Decision Provenance | Structured trace of every agent decision, written to disk and embedded in PRs | Implemented |
| Durable Run State | Persistent run and story status across the full pipeline | Implemented |
| Budget Tracking | Token count and estimated cost tracked per invocation and per run | Implemented |
| Error Taxonomy | Classifies transient, platform, and local runtime errors for actionable guidance | Implemented |
| Git Worktree Isolation | Each story runs in an isolated worktree; atomic create/delete; no cross-story contamination | Implemented |
| Model Role Selection | Separate model configs for GENERATE (worker) and REVIEW roles | Implemented |
| Context Compaction | Managing context continuity across very long or multi-session runs | Roadmap |
| Cross-Run Memory | Lessons from one epic compound into the next; state that survives between runs | Roadmap |
| Explicit Tool Contracts | Defined, documented tool schemas the agent can call beyond the filesystem | Roadmap |
Loop
Deterministic Orchestration
Getting context right is necessary — but it's not sufficient. You can feed an agent perfect specifications, full architectural context, and a crystal-clear task description, and it will still occasionally produce output that drifts. Not because the model failed. Because non-determinism is a feature, not a bug. The same input can yield structurally different output on consecutive runs.
Deterministic orchestration is the practice of wrapping a predictable execution envelope around an inherently unpredictable process. Think of it the way a compiler pipeline works: parse, analyze, transform, emit. Each stage has a defined input contract and an expected output shape. The compiler doesn't care how creative the source code is — the pipeline enforces structure at every handoff. Agent orchestration works the same way. You define stage gates — entry conditions, expected outputs, validation checkpoints — so that each step produces what the next step requires.
This is the part most teams skip. They invest in better prompts, richer context, more capable models — and then let the agent run in an open loop with no structural constraints on execution. The result is output that's impressive when it works and baffling when it doesn't, with no systematic way to diagnose the difference. Deterministic orchestration gives you that diagnostic surface: when a stage gate fails, you know exactly where the process broke and what the agent was supposed to produce at that point.
Loop
Adversarial Review
Stage gates tell you where things broke. But that's still reactive — you discover failures after they happen. Deterministic orchestration gives you structure; it doesn't give you confidence that the output inside that structure is actually correct. What if the system actively tried to break its own output at every stage gate, before that output became the next stage's input? That's adversarial review.
Adversarial review means every agent output passes through a critic that's specifically designed to find problems. Not a generic "check for errors" pass — a structured review that knows the project's architecture, the task's constraints, and the specific ways AI agents tend to fail on this type of change. Think of it as a code review run by someone who has seen every way this specific type of change can go wrong: the reviewer isn't checking for obvious mistakes, they're probing for the subtle ones.
Most AI workflows trust agent output by default and only discover problems when something breaks in production — or worse, when a human notices drift three sprints later. Adversarial review inverts that assumption: output is untrusted until it passes structured validation. The cost is an extra review cycle. The payoff is catching the kinds of subtle failures that erode trust over time — and building a workflow where failure handling was a first-class concern before success paths were ever defined.
Capability Map 10 implemented · 6 roadmap
| Feature | Description | Status |
|---|---|---|
| Stage-Gated Pipeline | 6-node execution envelope with defined input/output contracts at every handoff | Implemented |
| V6 Invariant Checks | Deterministic rule-based: file existence, naming conventions, syntax, YAML schema — no model opinion | Implemented |
| V3 Reflexion | LLM evaluates each acceptance criterion; returns PASS/FAIL with rationale and suggested fix | Implemented |
| Quality Gate | Ruff auto-fix → ruff check → mypy strict → pytest; supports Python and Node.js | Implemented |
| Bounded Retries | Retry count tracked in state; escalation when maximum reached — loop on evidence, not confidence | Implemented |
| Budget-Aware Stopping | Enforces invocation count and cost ceilings before agent is invoked each cycle | Implemented |
| Feedback Injection | Per-AC failure descriptions and suggested fixes injected into the retry prompt | Implemented |
| Lifecycle State Machine | Formal validated transitions: queued → preflight → running → validating → success / escalated | Implemented |
| Halt and Resume | Epic dispatch halted mid-run; resumes from the last incomplete story without re-running prior work | Implemented |
| PR as Evidence Gate | Pull request opened per story; merge conditional on CI pass and human review | Implemented |
| Dual Independent Reviewers | Two fresh review sessions with no shared context; disagreement flags rulebook ambiguity | Roadmap |
| Evolving Rulebook | Reviewer catches automatically propagate to future runs without manual code changes | Roadmap |
| Cross-Run Pattern Analysis | Aggregate failures across runs to surface error categories — one bad rule, not forty instances | Roadmap |
| Event-Driven Triggers | Webhook, schedule, or CI-failure-initiated dispatch beyond manual CLI | Roadmap |
| Daemon / Batch Serialization | Workers queue requests; one daemon owns expensive operations to prevent redundant rebuilds | Roadmap |
| Improvement Loops | Analyze traces across runs; modify instructions; verify improvement before promoting | Roadmap |
Graph
Decision Provenance
Adversarial review catches problems before they compound. But catching a problem is only useful if you understand why it happened. When a reviewer flags drift — when the agent's output doesn't match the specification — the question isn't just "what went wrong?" It's "what context led to this decision?" Without that trace, you're debugging in the dark, and the same class of failure will reappear next sprint.
Decision provenance is a complete trace of every agent decision: what context was assembled, what the agent produced, what the reviewer found, and what happened next. Not a log file you grep through after an incident — a structured, queryable record that's generated as a natural byproduct of the orchestration pipeline. Every stage gate produces a provenance entry. Every adversarial review finding links back to the context that informed it. When you ask "why did the agent restructure this module?", the provenance tells you exactly which architectural spec was in context, which constraint was binding, and what alternatives the agent considered.
This is the artifact that changes the conversation. Most AI-assisted development produces output and a prayer — you hope the code is correct, you hope it matches the architecture, you hope it doesn't introduce subtle regressions. Decision provenance replaces hope with evidence. When you run an autonomous dispatch and review the results at 7 AM, you're not guessing what happened. You're reading a complete narrative of every decision, backed by the context that informed it. It's the difference between "the tests pass" and "I know exactly why this code looks the way it does."
Capability Map 7 implemented · 4 roadmap
| Feature | Description | Status |
|---|---|---|
| LangGraph StateGraph | Explicit graph with 6 named nodes and conditional edges — not an implicit while-loop or scripts dressed as a graph | Implemented |
| Typed State Schema | StoryState and ProjectState are Pydantic models; all fields typed, documented, and validated | Implemented |
| Conditional Routing | route_budget_check (ok / exceeded) and route_validation (success / retry / escalated) | Implemented |
| Bounded Retry Cycle | validate → preflight loop with retry count enforced by the router — inspectable and stoppable | Implemented |
| Sequential Epic Execution | Ordered story list; merge outcome from each story informs continuation | Implemented |
| Human Gate via Halt / Resume | Operator halts at any story boundary; resumes exactly from that point | Implemented |
| PR Review as Human Gate | PR opened per story; merge requires CI pass and human approval before code lands in main | Implemented |
| Parallel Fan-Out | Multiple stories in an epic executing simultaneously with results joined before continuation | Roadmap |
| Multi-Specialist Agents | Different model personas for different node roles — architect reviewer vs. implementation agent | Roadmap |
| LangGraph Checkpointing | LangGraph native persistence for mid-graph checkpoint and resume | Roadmap |
| Event-Driven Graph Triggers | Graph execution initiated by external events — commit hook, CI failure, schedule | Roadmap |
The Result
Autonomous Dispatch
Decision provenance gives you evidence instead of hope. Every agent decision is traceable, every review finding linked to the context that produced it. But traceability is a means, not the end. The real question is: what does it unlock? When you have reliable context injection, deterministic orchestration, adversarial review, and full decision provenance — when every part of the pipeline is trustworthy — what becomes possible that wasn't before?
Autonomous dispatch. You queue a batch of implementation tasks at the end of your day — feature scaffolds, test generation, migration scripts, documentation updates. The orchestration pipeline runs each task through the same structured process: context assembly, agent execution, adversarial review, provenance logging. By morning, you don't have a pile of unreviewed AI output to sift through. You have a set of completed tasks, each with a full provenance trail showing exactly what happened, what was reviewed, and what passed. The ones that cleared every gate are ready for your final review. The ones that didn't have clear explanations of where the process stalled and why.
This isn't a promise about future AI capabilities. The models are already capable enough. The gap has always been reliability — the confidence that when you wake up, the output will be useful rather than a mess that takes longer to fix than it would have taken to write from scratch. Arcwright closes that gap by making every step of the process transparent, validated, and auditable. Context injection ensures the agent has what it needs. Orchestration ensures the process is structured. Adversarial review ensures the output is trustworthy. Provenance ensures you can verify all of it. Autonomous dispatch is what happens when you stop fighting the tools and start engineering the process.
Follow the Build
Arcwright is in active development — Alpha 0.1 coming soon. Follow Ed on LinkedIn for build updates, architecture decisions, and early access.
Follow Ed on LinkedIn