Why eforge

Agentic coding made implementation faster. eforge makes implementation asynchronous.

Most AI coding tools still assume the engineer stays in the loop moment by moment. eforge assumes the engineer should define the work, hand it off, and come back to review finished artifacts.

Foreground agents do not change the shape of work enough

A chat agent can be extremely capable and still keep implementation in the foreground. You ask for a change, watch it think, correct it every few minutes, accept edits, rerun tests, and turn the result into a commit. The loop is faster, but it is still a loop you sit inside.

That is useful. It is not the full shape of agentic engineering. If using an agent still means watching the agent, the agent has become a very capable pair programmer. eforge is for the next step: a background engineering loop that can run without constant babysitting.

Planning and building are different jobs

eforge separates the work you should keep from the work that can run asynchronously. You keep the judgment: deciding what should exist, specifying the change, naming constraints, reviewing the result, and steering when tradeoffs appear. eforge takes the implementation loop: operational planning, isolated execution, blind review, retries, conflict handling, merge flow, and validation.

There are two planning layers. You plan the change: goal, context, constraints, and acceptance criteria. eforge plans the build: decomposition, dependency order, agent roles, review cycles, and validation. You return at artifact boundaries, not token boundaries.

Why the product looks this way

Session plans clarify intent before execution starts.

The human-facing planning loop captures scope, architecture, risks, and acceptance criteria before work enters the build pipeline.

Build plans give agents operational structure.

The engine turns intent into concrete plan files, dependencies, and stage assignments instead of handing a vague prompt to one agent.

Worktrees make background work safe.

Delegated plans run in isolated git worktrees so parallel builds do not block your branch or trample each other.

Profiles make runtime choice explicit.

Agent runtimes, providers, models, and effort levels are engineering decisions. eforge keeps them visible and swappable.

Playbooks turn repeated workflows into artifacts.

The second time you perform a recurring workflow, it should become reusable process rather than another bespoke prompt.

Commits are the output.

You review code, history, logs, costs, and build decisions. Chat transcripts are context, not the deliverable.

Built for API economics

eforge is an engine, not a single chat surface. It can run from Pi, Claude Code, or the CLI, but its direction is deliberately Pi-centric: a local, provider-flexible agent environment where cost, context, planning, and execution are visible parts of the engineering system.

As agent execution moves toward explicit API-priced inference, token efficiency, provider choice, and local orchestration matter more. You should be able to choose the runtime, understand the tradeoffs, and route work through the system that gives you the best result for the cost. That is why eforge has profiles, why the engine is separate from any one host, and why Pi is becoming the primary surface.

Bring your own credentials. Use the providers and models that fit the work. Keep the loop durable as the model market changes.

What eforge is not

Who should try it

eforge is for engineers who already think in changes, plans, commits, and review. If you want a chat assistant, use one. If you want to hand off implementation and come back to a reviewable result, try eforge.

Start here

Recommended: Pi extension

Start with the Pi extension if you want the direction eforge is heading: provider-flexible, local, inspectable agent orchestration. Use the Claude Code plugin if Claude Code is already your daily environment. Use the CLI if you want the engine directly.

Read the setup guide · View the source


Built by Mark Schaake.