Workflows
as data.
Anvil is the workflow engine at the center of everything Foundry builds. Any workflow as a state machine: roles, transitions, review gates, hooks, and artifacts — all declared in data, none hardcoded. One engine drives software development, measurement, and custom business operations.
State machines defined as data.
Anvil represents every workflow as an explicit directed graph: states, allowed transitions, role assignments per state, hooks that fire on entry and exit, and artifact requirements that must be satisfied before a transition completes. Nothing is implicit.
States and transitions
Every workflow is a directed graph. States are named; transitions declare which states can follow which, and under what conditions. Anvil enforces these — an artifact cannot move to a state that has no declared incoming transition from its current one.
Roles per state
Each state belongs to a role: author, reviewer, orchestrator. The engine routes work to the right actor automatically. A reviewer cannot commit to a state that belongs to an author, and vice versa.
Artifacts and hooks
Each state declares which artifacts it requires and which hooks fire on entry and exit. Hooks deliver structured context to the actor about to work. Artifact requirements are checked before a transition is allowed to complete.
One engine for every workflow Foundry runs.
The same state machine primitive that governs a software development track also governs an agent quality measurement campaign, a tax preparation review, and a custom healthcare operations process. Domain changes; the structural guarantees don't.
Software development lifecycle
Propose → spec → plan → implement → review → reflect. Each phase is a state; each transition requires its artifact. Reviewers cannot be skipped.
How Anvil enforces this
Agent quality measurement
Discover → design quality criteria → measure → analyze → hypothesize → experiment → decide. The measurement loop Temper runs is an Anvil workflow.
What's declared vs hardcoded
Customer business operations
When Foundry embeds with a customer, it encodes their specific workflows into Anvil definitions. The customer doesn't interact with Anvil directly; they see the tool Foundry built on top of it.
Cross-workflow composability
Workflows reference each other. A spec-review track can spawn a sub-track for scope negotiation. Anvil's graph model supports parent-child composition without coupling workflow definitions.
Customers see Forge.
Anvil is the engine underneath.
Anvil is not a dashboard. It doesn't have a UI of its own. The layer customers and teams interact with is Forge — the cockpit that renders workflow state visually, surfaces review gates as native UI elements, and lets a supervisor approve or intervene from any device.
Temper uses Anvil to structure its measurement and experiment workflows. Forge uses Anvil to enforce spec-first development across every track. When Foundry builds a custom tool for a customer, that tool's review queues, approval chains, and exception-handling steps are Anvil definitions running underneath. Full picture: platform page.
See how Foundry deploys this for you.
When Foundry works with a business, Anvil is already running. Customers get the enforcement and auditability of a production-grade workflow engine without having to build or operate one themselves.
See how an engagement works →