An agent framework helps developers build agent behavior. A software factory helps an engineering organization operate repeatable software production.
They are not rival names for the same category. CrewAI, LangGraph, Microsoft Agent Framework, the OpenAI Agents SDK, AutoGen, and MetaGPT provide libraries or framework patterns for agent applications. Gas City, Factory.ai, and 8090 operate at the factory level. A factory may use framework-built agents inside it, just as a web service may use a database library without becoming a database library.
Getting the category right prevents a bad evaluation. It also makes the architecture easier to assemble.
The AI software factory guide defines the complete production system this page is separating from its component layers.
The six layers people collapse into “agent orchestration”
| Category | Core job | Examples | The question it answers |
|---|---|---|---|
| Agent framework or SDK | Implement an agent’s loop, state, tools, routing, and application behavior | LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK, AutoGen, MetaGPT | How should this agent application work? |
| Coding agent | Read and change a codebase | Claude Code, Codex, Gemini CLI, Cursor | Can an agent perform this engineering task? |
| Agent work manager | Preserve work identity, relationships, readiness, and history | Beads, br, ticket/tk, Knots, Trekker, PaiR | What work exists, and what can a worker claim next? |
| Agent control room | Let an operator see and steer active sessions | Conductor and desktop coordination products | What are the workers doing right now? |
| Reusable agent knowledge | Package skills, prompts, roles, and procedures | gstack, skills, plugins, Gas City packs | What method should workers follow? |
| Software factory | Join work, workers, workflows, repositories, evidence, triggers, and operation into a production system | Gas City, Factory.ai, 8090 | How does the organization repeatedly turn intent into reviewed software? |
Several products span more than one row. The rows still matter because a capability at one layer does not automatically supply the operating model above it.
What an agent framework gives you
Frameworks are for creating agent software. A developer defines state, tools, messages, handoffs, graph nodes, routing rules, persistence, and application-specific side effects. The resulting agent might triage support cases, research a market, reconcile invoices, or write code.
That is a valuable and demanding job. A good framework handles model calls, tool invocation, streaming, retries, checkpoints, observability, human interrupts, and multi-agent patterns without making the developer rebuild every primitive.
When the application is the agent, this is the right layer. The team wants source-level control over its behavior and expects to write application code.
What remains after the agent works
A software factory begins where one agent application’s boundary ends.
The factory needs a durable answer to questions such as:
- Which engineering work exists across repositories?
- Which steps are blocked, ready, assigned, running, or awaiting review?
- Which worker and model should handle each step?
- What happens when a worker crashes or returns incomplete work?
- Which workflow should run for a feature, migration, review, or release?
- How do recurring jobs start from events or schedules?
- Where do the team’s prompts, skills, policies, and operating methods live?
- What can a human inspect without reconstructing a set of chat transcripts?
A team can write all of this with a framework. At that point, it is building a software factory. The distinction is not what is theoretically possible; it is which layer the product already supplies.
Persistence does not erase the category boundary
Many frameworks support durable checkpoints or application memory. That does not make them factories, and factories are not the only durable systems.
A framework checkpoint answers, “How does this application execution resume?” Agent memory answers, “What context should this agent recall?” A work graph answers, “What engineering work exists, how is it related, and what is ready?” A retained factory Run answers, “What happened across workers, steps, artifacts, and decisions?”
Those records can coexist. Treating them as interchangeable usually creates either an overloaded application database or a work tracker full of runtime internals.
How Gas City uses the lower layers
Gas City assumes coding agents are already capable workers. It configures and drives their CLI harnesses rather than reimplementing their reasoning loops. Those coding agents may themselves be built with frameworks or SDKs.
Beads supplies durable agent work. Formulas define workflow shape. Packs distribute agents, workflows, automations, prompts, skills, and support files. Gas City supplies the open orchestration engine that turns those pieces into an operating factory.
This makes composition normal:
- A LangGraph application performs a specialized analysis inside one factory step.
- A CrewAI service gathers and synthesizes research for a bead.
- An OpenAI Agents SDK worker exposes a CLI harness Gas City can drive.
- Beads records why the step exists, what it blocks, and what should happen after it finishes.
The framework and the factory are both doing their own jobs.
When to start with a framework
Start with an agent framework or SDK when:
- you are building an agent application for a domain other than software production;
- the agent’s internal state machine is the product logic;
- you need custom tools, messages, guardrails, or model-call behavior at source level;
- one application team will own and operate the resulting runtime; or
- the existing framework’s deployment platform already matches the operating requirement.
Do not add a factory merely to make the architecture sound larger.
When to start with a software factory
Start with a software factory when:
- the work spans repositories, sessions, or several coding-agent workers;
- implementation, testing, review, and release follow repeatable methods;
- failures and handoffs must preserve work outside the worker session;
- operators need a continuing view of ready, blocked, running, and completed work;
- the factory should improve through reusable configuration rather than longer prompts; or
- the team wants to run the production system rather than write an orchestration application from primitives.
Then compare products inside the factory category. Gas City, Factory.ai, and 8090 have different backbones and operating models, but each is trying to run a software factory.
A practical build-or-adopt test
Write down one real production workflow: for example, dependency upgrade, implementation, multi-agent review, test repair, and final human approval.
If your evaluation begins with node APIs, message schemas, tool decorators, and checkpoint stores, you are selecting framework machinery. If it begins with intake, durable work, worker pools, workflow configuration, repository isolation, evidence, and operations, you are selecting a factory.
Either path can be right. What matters is knowing which system you are choosing to build.
Related articles
- Build an AI software factory: See the complete factory loop and why it extends beyond agent calls.
- Open-source agent orchestration: Examine the control and portability benefits of an open orchestration engine.
- Software Factory reference architecture: Place each category in a concrete system diagram.
- Gas City vs Factory.ai: Compare two products after the category boundary is clear.