Agent Team
A software agent workflow for planning, implementation, and review. Its example separates a successful run, a retry, and a blocked result, with the default automatic merge policy stated beside the steps.
- Contribution
- I build the orchestration and review workflow around the participating agents.
- Maturity
- Implemented
Interactive simulation · sample data
Primary demonstration
Portfolio simulation screenshot: a fictional successful run reaches Delivery through the represented default legacy automatic merge path. Merge and queue enforcement, sandboxing, and anomaly termination are off; hard caps are unset. The website performs no repository operation.
Sample run · deterministic simulation
Fictional repository, task, review, QA, draft PR, and CI artifacts.
Public example checked 2026-09-12. Portfolio simulation screenshot: a fictional successful run reaches Delivery through the represented default legacy automatic merge path. Merge and queue enforcement, sandboxing, and anomaly termination are off; hard caps are unset. The website performs no repository operation.
Role: orchestration and review workflow. Maturity: Implemented. The browser does not run agents, contact providers, change a repository, or merge code.
Passes review · 1 of 5
Task
Text-based sample evidence
- Role
- Coordinator
- Decision
- Accept a bounded fictional change and define its checks.
Task: keep a retry banner visible after the next successful check.
- 01Task
- 02Implementation
- 03Reviews
- 04QA
- 05Delivery
Default configuration: merge enforcement off; queue enforcement off; sandboxing off; anomaly termination off; hard caps unset.
This server-rendered reference stays available if the interactive controls cannot load. The complete Passes review, QA retry, and Security block walkthroughs remain below it.
Interactive controls load when this example comes into view.
If the interactive example stops responding, Reload this example.
Problem and workflow
The problem
A coding task can appear to move cleanly from assignment to merge while hiding the decisions that mattered. The implementation may have happened in an isolated workspace, reviewers may have received different prompt contexts, and QA may have needed another attempt. A security finding may also stop the work before a pull request exists. Without those boundaries, a green terminal label says little about why the task continued, retried, or stopped. This example keeps the five stages stable while exposing the role, decision, and sample artifact at each point.
The workflow
Choose one of three fictional runs, then inspect Task, Implementation, Reviews, QA, and Delivery. The stage names stay fixed across scenarios, while reachability and evidence change. Passes review and QA retry both end on the inspected default legacy automatic merge path with merge-policy enforcement disabled. Security block ends in Reviews because a separate security review rejects unsafe path handling. Selecting a later stage only changes the sample view; it does not execute an agent, open a pull request, run CI, or touch a repository.
01Passes review
- 01Task accepts a bounded fictional retry-banner change and defines the checks that will decide it.
- 02Implementation makes one focused change in an isolated sample workspace.
- 03Reviews shows correctness and security reviews with separate, isolated prompt contexts. Both sample reviews pass without claiming provider or model diversity.
- 04QA passes the two fictional assertions on its first attempt.
- 05Delivery shows a fictional draft PR, green sample CI, and “Sample run complete · automatic merge.” Merge-policy enforcement is disabled, so this follows the inspected legacy path. The website performs no merge.
02QA retry
- 01Task requires the first failed assertion to remain inspectable after a later pass.
- 02Implementation adds the initial attempt summary in an isolated sample workspace.
- 03Separate correctness and security review contexts both pass the fictional change into QA.
- 04QA attempt 1 fails because the prior failure marker disappears. A debugger changes replacement to append the next result, and attempt 2 passes. Both attempts remain visible.
- 05Delivery shows a fictional draft PR and green sample CI before the legacy automatic merge label. Merge-policy enforcement remains disabled, and no repository operation occurs.
03Security block
- 01Task asks for a fictional branch label in a sample archive filename.
- 02Implementation constructs the filename in an isolated sample workspace.
- 03Correctness review passes the requested display behavior. In a separate prompt context, security review finds that parent-directory segments are not rejected and blocks the run.
- 04The terminal label is “Blocked by review.” This stop is a review decision before PR, not an enabled merge gate.
- 05QA and Delivery remain visible as Not reached. Direct selection, keyboard activation, and Next cannot bypass the blocked Reviews stage.
Engineering and evidence
Decision 01
The same stage labels must explain successful, retried, and blocked work.
- Choice
- Use one five-stage view with scenario-specific reachability and evidence, backed by a strict fixture rather than a generic workflow interpreter.
- Consequence
- Visitors can compare the runs directly, and the blocked scenario keeps QA and Delivery visible without making them selectable.
Decision 02
A later success can make an earlier failure disappear from a simple status panel.
- Choice
- Keep QA attempts as immutable fixture history and render both the failed assertion and the debugger change beside the passing retry.
- Consequence
- The completed sample still explains why it retried and what changed between attempts.
Decision 03
A merge label can overstate the controls that made the decision.
- Choice
- Place the inspected defaults beside each terminal decision and describe automatic merge as the legacy path with merge-policy enforcement disabled.
- Consequence
- The sample does not imply an enforced queue, sandbox, anomaly stop, hard cap, or universal human approval.
Contribution and credits
I build the orchestration and review workflow around the participating agents.
- My contribution is the orchestration and review workflow around the participating agents.
- The examples are purpose-written fictional runs. They are not production logs, real pull requests, or captured repository pipelines.
Current limits
- Merge enforcement, queue enforcement, sandboxing, and anomaly termination are off in the represented default configuration. Hard caps are unset.
- The separate review contexts do not establish different providers or models. The browser performs no model calls, subprocesses, repository actions, approvals, or network requests for the demo.
- Budget termination, staged rollback, and operator-confirmation outcomes remain follow-on examples.
About this example
Deterministic portfolio simulation with purpose-written fictional task, review, QA, pull-request, and CI artifacts, checked September 12, 2026. The overview image shows the local portfolio UI, not a captured repository pipeline. The fixture contains no production identifiers or replay data. “Implemented” describes the source-backed capability; it does not claim that the displayed defaults provide active isolation or that a deployment was verified.
Checked September 12, 2026
Evidence details
Portfolio simulation screenshot: a fictional successful run reaches Delivery through the represented default legacy automatic merge path. Merge and queue enforcement, sandboxing, and anomaly termination are off; hard caps are unset. The website performs no repository operation.
illustrative