Factory vs Dark Factory vs Automations vs Workflow vs Agent

Ask five engineering teams to show you their software factory and you will see five different things. One team opens a scheduled prompt. Another opens a folder of skills checked into their monorepo. A third shows you a deployed workflow that opens pull requests overnight. Each of them is right by their own definition, and the same goes for agent, automation, workflow, and dark factory.

I've watched these terms drift for a while now. Agents, workflows, and automations each have a shape that most people agree on, so they come first. "Factory" still means several different things. A dark factory is a factory whose changes you trust enough to merge without anyone reading them.

Agents

An agent is a program that takes a goal, picks the next step, runs it with a tool, looks at the result, and repeats until the goal is met or it gives up. The model does the reasoning and the tools do the acting. Memory and knowledge carry context from one step to the next. Agentic Software Engineering Terminology covers each part in detail.

Few people argue about this definition anymore. The arguments are about how much autonomy to give an agent.

Workflows

A workflow in the workflow-engine sense (n8n, Zapier, Temporal, Step Functions) is a graph of steps with explicit control flow. The engine runs the nodes in the order you define and branches on conditions you set.

An agent can be one node in that graph. A workflow might fetch a ticket, hand it to one agent to draft a fix, pass the draft to a second agent for review, and send the result to a person or to a merge step. Chain enough of these and you get a network of agents that a workflow coordinates.

With today's foundation models, you can often skip the workflow and let one agent handle the whole task. That pays off when something unexpected happens. A workflow only handles the exceptions someone anticipated and drew a branch for. When a step fails in a way nobody planned for, the workflow stops or carries on with a bad result. An agent notices that the result is wrong, works out why, and tries something else until it gets back on track. If the situation can surprise you, give the whole job to an agent rather than splitting it into fixed steps.

Automations

The products that ship "automations" today all have the same four parts:

• A prompt that tells the agent what to do.
• A trigger, such as a schedule, a webhook, a Slack message, a new pull request, or a failed check.
• Tools and context that decide what the agent can read and change while it runs.
• Guardrails that limit tools, runtime, and spend.

Agent0 Automations work this way. A trigger fires, Agent0 runs your instructions against your Dash0 data and connected tools, and guardrails limit what it may do. Cursor's Automations do the same for coding agents. Scheduled tasks in Claude use a clock as the trigger. Managed agent platforms offer the same thing as a building block. You define the prompt, tools, and triggers through an API, and the platform runs the agent inside your own product.

These products differ in which triggers they support, which tools they reach, and how they bill.

"Automation" used to mean a fixed sequence of steps with no model making decisions, and "agent" meant something that chooses its own path. Product automations run a full agent on every trigger, so when someone says "automation", check which meaning they have in mind.

The distinction I find useful:

• An agent picks its own next step.
• A workflow fixes the order of steps, and some of those steps can be agents.
• An automation runs an agent when a trigger fires.

Factories

A factory is sometimes also called an "AI software factory". I see three readings of the term in practice.

• The factory is a set of skills. The company keeps a shared library of agent skills (prompts, playbooks, conventions, scripts) that everyone loads into their own coding agent. The skills make every session follow the same process. Nothing runs unattended, and people still drive each session.
• The factory is an automation. A scheduled or event-triggered agent does one kind of work on its own, such as fixing flaky tests every night or upgrading dependencies every week. It often loads the same skills the team already uses, so it follows the same process without a person driving it.
• The factory is deployed software. A pipeline runs somewhere and executes a defined workflow from start to finish. It picks up a ticket, plans, implements, tests, and opens a pull request. This is a workflow in the n8n sense, with agents doing the work inside it.

The three readings cost different amounts to run. A skill library needs version control and people who use it. A deployed workflow needs hosting, credentials, observability, retries, and someone on call when it breaks. So when a team tells me they're building a factory, my first question is which of the three they mean.

Dark Factory

Every one of those factories already produces changes without much human effort. Agents write the code, open the pull request, and often fix their own CI failures. So how far do you trust those changes, and will you let them merge without a person reading them?

Your answer decides whether you have a factory or a dark factory. The term comes from manufacturing, where a lights-out factory runs with nobody on the floor. In software, changes go from intent to production without anyone reviewing each diff.

A dark factory is very similar to a factory. The huge difference is validation.

Both use the same agents, skills, and workflows to produce changes. The difference sits between a generated change and the main branch. In a factory, a human reviewer stands there. In a dark factory, a validation system makes that call, and you have evidence that it makes the call correctly.

A better coding agent won't get you there. It writes better changes. A dark factory also needs you to clear pull requests automatically and trust the decision. You build that trust with:

• Evals you control. You write criteria that say what "safe to merge" means in your codebase, and every change gets scored against them.
• Trust you grant step by step. Autonomy starts at zero. You raise it per repository or per path as evidence builds up, and you keep high-risk areas on the human path for as long as you need to.
• A track record. You compare the system's decisions with your reviewers' decisions over time, so you can point to data when you give it more autonomy.

The Six Levels of Agentic Software Engineering lays out this progression. Most teams now sit at Level 3. AI code review runs on every pull request, and a person still approves every merge. Validation becomes the bottleneck on the way to selective auto-merge at Level 3.5. At Level 5, the dark factory, validation decides every merge.

In practice, few organizations will run one model everywhere. Some parts of your software will still be written without a factory, by engineers working with their coding agents. Other parts will come out of a factory with a person reviewing every pull request. And the parts where you have enough evidence, such as routine changes in low-risk services, will run dark. The mix shifts as trust builds, and the high-risk areas may never go dark at all.

We're building AutoMerge to help with the validation part. It scores pull requests against criteria you control and lets you raise its autonomy per repository and per path as its decisions prove out.