Workflows
as data.
Anvil is the workflow engine at the center of everything Foundry builds. It defines any workflow as a state machine — roles, transitions, review gates, hooks, and artifacts — all declared in plain YAML, none of it hardcoded. One engine drives software development, agent quality 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 phase transition requires its artifact. Reviewers cannot be skipped. Anvil enforces this for every track Foundry runs internally and for every engineering team Foundry deploys it for.
Agent quality measurement
Discover → design quality criteria → measure → analyze → hypothesize → experiment → decide. The measurement loop that Temper runs is an Anvil workflow. Quality criteria, grading policies, and experiment approvals are all declared states with required artifacts and explicit transitions.
Customer business operations
When Foundry embeds with a customer, it encodes their specific workflows into Anvil definitions — financial review processes, care coordination steps, estimation approval chains. 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. A measurement campaign can trigger an experiment track. 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, test-driven development across every track. When Foundry builds a custom tool for a customer, that tool's operational workflows — the review queues, approval chains, and exception-handling steps — are Anvil definitions running invisibly underneath. The full picture is on the 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 →