Factory AI Coding: Agents, Tools & Development Workflows

• A cloud coding agent can take a task, work in an isolated environment with the repository checked out, and return a pull request.

• A coding assistant completes code inside your editor, while a coding agent runs a whole task in its own environment.

• GitHub Copilot cloud agent caps each session at 59 minutes, one branch, one repository, and one pull request.

• Review capacity, not agent count, sets the practical ceiling on how many coding agents a team can run.

• BAND connects coding agents from different vendors through a shared room, mention-based routing, and delivery tracking.

Factory AI coding carries two meanings, and search results mix them.

The first is a company. Factory was founded in 2023 and builds autonomous coding agents called Droids for enterprise engineering teams; in April 2026, it raised $150 million at a $1.5 billion valuation in a round led by Khosla Ventures (TechCrunch). Its Factory 2.0 post applies "software factory" to an interconnected, agent-native system spanning the lifecycle and names three requirements: model independence, sovereign intelligence, and continual learning.

The second meaning is the pattern the phrase now describes generally. Work arrives as a task, an agent runs it through the loop, and a human reviews the output. Major AI coding vendors now ship versions of this pattern.

A common cloud-agent workflow follows five steps:

1. It receives a task: an issue, a prompt, or an assigned ticket.

2. It gets an isolated environment with your repository checked out at a chosen branch.

3. It runs terminal commands in a loop, editing code and running checks.

4. It validates its own work against whatever the repository can check.

5. It returns a diff, and usually opens a pull request.

Codex Cloud documents that loop as numbered steps. Copilot cloud agent describes the same arc: research the repository, plan, change code on a branch, open a pull request.

The execution environment

Cursor's Cloud Agents each run on an isolated cloud VM with the repository cloned, dependencies installed, and secrets injected. Codex uses a container behind an HTTP proxy, with agent-phase internet access off by default. Copilot's environment is ephemeral and runs on GitHub Actions.

How the agent verifies its own work

The agent runs your tests, your linters, your build, and Codex reads AGENTS.md to find the project's lint and test commands.

That loop is also the ceiling. An agent’s verification is only as strong as the checks and environments it can access. A service with thin tests and weak runtime checks gives it less evidence that a change is actually correct.

What separates the two categories is how much you hand over.

GitHub draws the same line in its docs: with an assistant in the IDE, the developer still creates the branch, writes the commit message, pushes, and opens the pull request. A factory coding agent absorbs those steps. That is the purchase, and the last row of the table is the price.

One agent is a tooling decision. Running factory AI coding agents side by side is a coordination problem, whether or not anyone planned for it.

Split work to minimize conflicting edits, or give agents isolated branches/worktrees with a deliberate merge strategy. Copilot cloud agent allows one branch and one pull request per task and cannot change multiple repositories in one run. Hence, a migration across four services becomes four agents and four pull requests landing in an order somebody decides.

Then one agent's output becomes another's input, and in most teams that handoff is a person copying text between two windows.

Vendors have shipped answers inside their own products. Devin's CLI spawns subagents that share tools and codebase context with the parent but run in their own conversation chain and, by default, cannot spawn subagents of their own. Cursor runs as many cloud agents in parallel as you want. Both stop at the vendor boundary: a Devin subagent cannot hand a plan to a Copilot agent. That is the coordination problem in multi-agent coding, and improving any single agent does not touch it.

Take a framework upgrade: React 18 to React 19 across a front-end monorepo. Follow one unit of work through five stages and watch where it changes hands.

1. Plan. An agent catalogs the deprecated APIs still in use and writes a phased plan.

2. Implement. A second agent takes phase one, so it needs the plan and needs to know which phase is its own.

3. Test. The agent watches snapshot tests break on the new renderer and judges which failures are real.

4. Review. A reviewer reads the diff against the plan, which works only if the plan traveled with the work.

5. Pull request. The change reaches your normal CI path.

Modern coding agents can automate many of those stages. Teams lose time at the four handoffs between them, because each is a place where context, ownership, and the reason behind a decision can quietly fail to travel.

Five things have to exist before you run more than one agent, and all are cheaper to decide now than to retrofit.

1. An isolated environment per agent, so two agents cannot corrupt each other's working tree.

2. A verification gate the team trusts, since an agent's self-check is bounded by what the repo can test.

3. A durable record of what each agent did, retrievable after the session ends.

4. A named owner per unit of work, so each in-flight task has exactly one agent responsible for it.

These capabilities matter more as teams run multiple agents, especially across vendors. No coding-agent vendor solves this alone, because it lives between them. Our guide to the agent collaboration platform covers that layer.

When a planner built on one tool hands a spec to a reviewer built on another, the handoff is a person copying text between two windows. Teams need a shared place where agents exchange work, and the exchange is recorded. BAND is that layer, sitting beneath the coding agents rather than competing with them.

Requirement five maps to framework adapters: Claude Agent SDK, Codex, GitHub Copilot, and OpenCode, alongside LangGraph, CrewAI, and others. Requirement four maps to mention-based routing, where an agent processes a message only when addressed, and the rest of the room stays quiet. Requirement three maps to the message record: text, tool calls, results, and errors are persisted, and each message carries a per-recipient delivery status moving through delivered, processing, and processed or failed. That is how you tell a crashed agent from a slow one.

The documented setup is concrete. BAND for coding agents runs a Claude Code planner and a Codex reviewer in one Docker workspace on the same repository. The planner writes plan.md and mentions the reviewer, which reads the source files, writes review.md, and posts findings as Critical, Risk, Gap, or Suggestion.

Three limits, stated plainly. BAND does not write code and is not a coding agent; it is the layer the agents talk through. It doesn't replace your repository, pull-request system, or CI, which remain the source of truth. And BAND Desktop, BAND's coding-agent coordination surface, requires Claude Code today, while BAND underneath stays framework-agnostic.

The agent is the easy part now. Every vendor has one; they run the same five steps, and they improve on a schedule you do not control. The machinery around the agent is what you buy or build. Book a demo to walk through that on your repositories.