External work with agents
Launch development with an external agent, follow its activity, answer its blockers, review and accept or return its results, and authorize correction work.
- Availability: Experimental
- Evidence: Read from source
- How-to guide
Before you start
- The release must read Approved scope: see Review and planning.
- The project needs a development agent trigger. Only the person who operates the installation can configure it, under Infrastructure. Without it the release shows "Launching needs a development agent trigger. The owner configures it under Infrastructure."
- Every release this one waits for must have all its results accepted.
- You need the permission Take decisions.
Launch development
- Open Planned releases and find the release with Approved scope.
- In Development branch, keep the suggested name or write another. "A working branch. The main branch cannot be used." A branch named
mainormasteris refused with "Check the required fields and their formats." - Choose Launch development.
Expected outcome: "Saved.", the release reads In development, and the panel Code and agent activity appears with an External agent dispatch entry in the state Queued.
What you did is request work. Whether an agent actually started is a separate fact:
| Dispatch state | Meaning |
|---|---|
| Queued | Waiting for the dispatcher, which runs only while the operator has enabled it |
| Dispatching | Being sent to the provider now |
| External session created | The provider confirmed a session. Open external session leads to it |
| Failed | The provider refused. The reason is shown with its code |
| Needs attention | The outcome is unknown. See an uncertain dispatch |
| Superseded | Closed by a person, or no longer wanted |
If launching answers "A planned release this one depends on is not finished yet.", accept the results of the earlier release first.
Follow the work
Under Code and agent activity two kinds of record stay visibly apart, because neither proves the other:
- "GitHub · observed commit": commits Delegate read from the branch. Choose Fetch GitHub commits to read them again.
- "MCP · agent report · {actor}": what the agent itself reported.
With neither, the panel says "No commits or agent reports observed yet."
Each requirement of the release moves through these states under Requirements:
| State | Meaning |
|---|---|
| Approved scope | In an approved release; no agent has claimed it |
| In development | An agent claimed it |
| Blocked · answer needed | The agent asked something and stopped |
| Waiting for the agent to resume | A person answered; the agent has not confirmed it continues |
| Result to review | The agent submitted a result |
| Result accepted | A person accepted it |
| Delivered in a version | It is part of a version |
Answer a blocker
A blocked requirement shows Agent question with the question as the agent wrote it, and it appears in Needs my attention as Agent blocked · decision needed.
- Write your Decision.
- Choose Answer and request continuation.
Expected outcome: "Answered by {actor}", and the state Waiting for the agent to resume. The hint says exactly what happens next: "Your answer queues a continuation. The work resumes only when the assigned agent confirms it." Your answer does not restart the agent by itself, and the state does not return to In development until the agent confirms.
Review a result
A requirement in Result to review shows Agent result: "Reported by {actor}", the agent's summary, Review code proposal (a link to a pull request in the project's repository; anything else is refused when the agent submits it), the revision, and Reported test evidence.
The test evidence is what the agent reported. It is not a verification by Delegate. Open the pull request and judge it yourself.
| Decision | Control | What it does |
|---|---|---|
| Accept | Accept result | The requirement reads Result accepted. When every requirement of the release is accepted, the release reads Results accepted · ready for a version |
| Return | What needs to change?, then Return result to the agent | "The result goes back with your reason. Work resumes only when the assigned agent confirms it." The returned result stays readable under "1 returned result" |
Accepting a result is not a deployment. The next step is a version.
Authorize correction work
An accepted result can be reopened in two situations only, and the form explains which one applies:
- "This result was accepted and is not in a version yet. Correction work returns the requirement to the approved scope of its planned release."
- "Version {name} failed its test. Correction work returns this requirement to the approved scope of its planned release; the rejected version and its review stay unchanged."
Write What has to change and choose Authorize correction work. "The accepted result is kept as evidence. The assigned agent is asked to work on this requirement again." Past corrections stay under "1 authorized correction".
While the newest version with the requirement is still being delivered, or its test was accepted, correction is refused: "The newest version with this requirement is still being delivered, or its test was accepted. Correct a rejected version, or plan a new release."
An uncertain dispatch
A dispatch reads Needs attention when Delegate sent a request to the provider and does not know whether a session started: the connection broke, the provider answered unreadably, or the process stopped halfway. It appears in Needs my attention as Agent dispatch with unknown outcome, and the error line reads "The dispatch outcome is unknown. Check the provider before anything is sent again."
- Open the provider's own account and look for the session.
- In Delegate, open Resolve this dispatch: "The provider may or may not have started a session. Nothing is sent again automatically. Check the provider, then record what you found."
- Under What did you find?, choose one:
- A session was created · record its link, and paste the External session link ("Required when a session was created.").
- No session exists · queue a new dispatch. You are accepting that, if you were wrong, a duplicate session may exist.
- No session exists · no new dispatch is needed.
- Write What did you check? and choose Record resolution.
Expected outcome: "Resolved by {actor}: {outcome}." Delegate records what you found; it cannot confirm it. If the provider reports back afterwards, the entry adds "A dispatcher reported back after this was resolved (…). Kept as evidence; the resolution stands."
If queueing a new dispatch answers "This action is not available in the current state. Refresh the page.", the work it described is no longer wanted, for example because the agent already resumed and its result was accepted. Choose the closing option instead.
Limits
Next action
When a release reads Results accepted · ready for a version, continue with Versions and delivery status.
Related: Work status vocabulary · Delegate recovery · Review and planning