Before submitting
Area
Not sure
Problem or use case
Today a task is typically handled by a single agent from start to finish. While this works well for many cases, different stages of the software development lifecycle often require different responsibilities (planning, implementation, review, testing, documentation).
Currently there is no way to define a reusable workflow where each stage can have its own behavior, provider, prompt, or rules.
Proposed solution
Instead of treating every task as a single agent session, introduce the concept of configurable development pipelines.
A pipeline would represent the software development lifecycle and consist of a sequence of configurable stages (for example: Planning → Implementation → Self Review → Independent Review → Testing → Documentation).
Each stage could define:
-
The provider or model to use.
-
A dedicated system prompt.
-
Project rules specific to that stage.
-
Stage-specific execution settings.
When a stage completes, its output would be passed to the next stage automatically. This would allow projects to encode their engineering workflow directly into T3 Code while keeping every task consistent and reproducible.
The intention is not simply to chain multiple models together, but to separate responsibilities across the development lifecycle and allow each phase to be configured independently.
Why this matters
This would make development workflows reproducible across tasks and repositories, while allowing teams to encode their engineering process directly into T3 Code.
It would also make it easier to specialize each stage of the workflow without relying on a single agent configuration for every responsibility.
Smallest useful scope
Support a simple two-stage pipeline:
Implementation → Independent Review
Each stage should be able to configure its own provider and system prompt.
Alternatives considered
Project Rules partially address this problem, but they appear to customize the behavior of a single agent rather than defining a multi-stage development workflow.
If there is already a recommended way to achieve this with existing features, I'd be happy to learn about it.
Risks or tradeoffs
This feature would introduce additional complexity to both the UI and task execution model. Care should also be taken to avoid turning pipelines into a generic workflow engine.
Another consideration is the overlap with existing features such as Project Rules. If similar behavior can already be achieved today, it would be useful to understand the intended direction before introducing a new abstraction.
Examples or references
Example pipeline:
Planning
Provider: Claude
Prompt: Generate an implementation plan.
Implementation
Provider: Codex
Prompt: Implement the approved plan.
Independent Review
Provider: Gemini
Prompt: Review the implementation, identify bugs, edge cases, and suggest improvements.
Testing
Provider: Claude
Prompt: Generate missing unit and integration tests.
This is only an example. The value is not in using multiple models, but in allowing each stage of the development lifecycle to be configured independently.
Contribution
Before submitting
Area
Not sure
Problem or use case
Today a task is typically handled by a single agent from start to finish. While this works well for many cases, different stages of the software development lifecycle often require different responsibilities (planning, implementation, review, testing, documentation).
Currently there is no way to define a reusable workflow where each stage can have its own behavior, provider, prompt, or rules.
Proposed solution
Instead of treating every task as a single agent session, introduce the concept of configurable development pipelines.
A pipeline would represent the software development lifecycle and consist of a sequence of configurable stages (for example: Planning → Implementation → Self Review → Independent Review → Testing → Documentation).
Each stage could define:
The provider or model to use.
A dedicated system prompt.
Project rules specific to that stage.
Stage-specific execution settings.
When a stage completes, its output would be passed to the next stage automatically. This would allow projects to encode their engineering workflow directly into T3 Code while keeping every task consistent and reproducible.
The intention is not simply to chain multiple models together, but to separate responsibilities across the development lifecycle and allow each phase to be configured independently.
Why this matters
This would make development workflows reproducible across tasks and repositories, while allowing teams to encode their engineering process directly into T3 Code.
It would also make it easier to specialize each stage of the workflow without relying on a single agent configuration for every responsibility.
Smallest useful scope
Support a simple two-stage pipeline:
Implementation → Independent Review
Each stage should be able to configure its own provider and system prompt.
Alternatives considered
Project Rules partially address this problem, but they appear to customize the behavior of a single agent rather than defining a multi-stage development workflow.
If there is already a recommended way to achieve this with existing features, I'd be happy to learn about it.
Risks or tradeoffs
This feature would introduce additional complexity to both the UI and task execution model. Care should also be taken to avoid turning pipelines into a generic workflow engine.
Another consideration is the overlap with existing features such as Project Rules. If similar behavior can already be achieved today, it would be useful to understand the intended direction before introducing a new abstraction.
Examples or references
Example pipeline:
This is only an example. The value is not in using multiple models, but in allowing each stage of the development lifecycle to be configured independently.
Contribution