AI Agents

You work with ACE as a single assistant. You ask ACE for something, and ACE does it. There is no roster of differently-named bots to pick between, and no assignee to choose. Behind that single identity, the work is shared across specialist roles, each focused on one part of the job.

One assistant, many roles

Every request is led by a coordinator that reads what you asked for and decides how to break it down. It hands the pieces to specialists: some plan the work, some build it, and some review the result before it ships.

You never manage these roles as separate identities. In the conversation, everything is attributed to ACE. If you want to see which role handled which part of a job, a card's Technical details view lays the run out for you. That view is there for transparency, not something you have to operate.

Grounded in your system

Agents don't work from generic assumptions. They share the same understanding of your codebase and infrastructure that the Learn Path produces, so they reason about your real system rather than a guess at it. Standing conventions you set for a project apply to every part of the work, which is what keeps the team consistent instead of each part pulling its own way. Improve that shared understanding once, and every agent benefits at the same time.

Shaping how ACE works

ACE is ready to use out of the box, but you can tune it per project. For each role you can adjust:

• Its instructions: how it should approach the work.
• The tools it may use: it can only ever do what you allow.
• Its model: a specific one, or the platform default.

You can also turn a role off, or add a custom role of your own for work that is specific to your project. Configuration lives in the product, and your changes take effect shortly after you save. Turning a role off only stops new work from reaching it: anything already in progress finishes, and the coordinator always runs.

Tools are the permission model

An agent has no abilities beyond the tools on its list, and a tool that belongs to an integration only works once that integration is connected to the project. There is no separate permission system to keep in sync.

Bounded by design

Agents are capable but deliberately limited, so they stay inside the Software Factory human-on-the-loop model. Three limits do the work:

1. Scoped abilities. An agent can only use the tools you have given it.
2. Sandboxed work. Code is written in an isolated cloud sandbox, never your real repository, until a human approves shipping.
3. Mandatory human gates. An agent cannot finish a feature, merge, deploy, spend, or delete without an explicit human decision.

Agents also never handle your credentials directly. When a task needs one, the platform supplies it for that single action, and the agent only ever sees the result.

So the team does the engineering, and a person stays in control of everything that is hard to undo.

Where to go next

🏭Software Factory AIThe on-the-loop model and the human gates the agents live inside.🧭Learn PathHow the shared understanding that grounds every agent is built.🗂️The Development BoardWhere a run pauses at a checkpoint for your decision.