Autonomy starts with a well-defined task
An issue report is often the beginning of a conversation rather than a specification. “Search is broken” might mean the wrong results, an unclear interface or a missing data source. Giving that sentence directly to a coding agent leaves too much of the product decision to the executor.
A more useful starting point is a bounded work package: the problem, relevant context, permitted changes, acceptance criteria and the evidence needed for review. The team agrees what success means before execution begins. That distinction matters to the person requesting the change as much as it does to the developer.
Keep the workflow independent of the agent
The development agent should be replaceable. The surrounding system owns the task, its authorisation, its progress and the evidence of its outcome. Changing an AI service, repository host or project-management tool should not require changing those responsibilities.
At a high level, a control layer checks the task and places approved work in a queue. A worker receives only the context and access needed for that run, prepares an isolated workspace, implements the change and runs local checks. Passing work can then become a change proposal for independent validation and review.
The first useful milestone is a reviewable change with evidence. A successful agent run is not the same as an accepted change, and neither automatically authorises a production release.
The agent executes. The workflow stays accountable.
An authorised task reaches an isolated worker. Local checks, independent validation and review lead to a separate release decision, with evidence and status retained.
High-level workflow illustration. Explore horizontally on smaller screens.
Make the work package explicit
A task needs enough context to be executed without repeated clarification, while retaining a clear route back to a person when the work no longer fits the agreed boundaries. A missing dependency or ambiguous acceptance criterion should become a visible blocker rather than an invitation to improvise.
- An objective and examples of the expected behaviour.
- The relevant application, repository and working instructions.
- Changes that are permitted, and operations that are restricted.
- Dependencies, acceptance criteria and the checks that establish them.
- Time and resource limits, a cancellation path and a named review responsibility.
- The expected handover: changed files, validation evidence and a change proposal.
A stakeholder example: fixing property search
Consider an illustrative property-services application. A coordinator reports that entering a postcode does not reliably narrow the property list. The product owner confirms the intended behaviour: postcode filtering should work alongside the existing search and pagination, without changing what each user is allowed to see.
The resulting task is deliberately small. An execution worker may change the search behaviour and relevant tests, but it cannot change the database structure or release to production. It works with fictional records that cover representative postcodes, empty results and multiple pages.
When the checks pass, the technical reviewer receives a change proposal and test results. The coordinator or product owner receives a clear explanation of what changed and representative examples to review in a test environment. Release remains a separate step. This is an example of the workflow, not a claim about a particular client incident.
One task. A clear handover for every role.
A fictional property-search issue moves from confirmed scope to implementation, independent checks, reviewer evidence and stakeholder feedback. Acceptance does not itself authorise a release.
High-level workflow illustration. Explore horizontally on smaller screens.
Follow the transaction from request to decision
The useful transaction is the full handover: request, authorisation, execution, evidence, review and status update. Each stage should refer to the same work item and the exact version of the proposed change. A board that says “done” should not be disconnected from the code and checks behind it.
The requester needs to know whether the work is queued, running, blocked or ready for review. The developer needs the technical evidence and any unresolved assumptions. The person approving a release needs to know which reviewed version is being released and what remains outside its scope.
Task creation, queue acknowledgement and completion updates can all be retried. The workflow should recognise repeated delivery so that a retry does not silently create another execution or another change proposal. A stalled worker needs a recovery path, and cancellation needs to stop further work rather than merely change a dashboard label.
Validation needs its own authority
An agent’s account of its work is useful context, but it is not independent proof. Local checks give fast feedback; a separate validation pipeline checks the proposed version again before the change is treated as ready for review. Tests should cover the intended behaviour and the surrounding workflow that must keep working.
Failures can return to the worker for a limited number of remediation attempts. If the limit is reached, or the fix would cross a permission boundary, the task stops with its evidence and a clear reason for escalation. Repeating the same unsuccessful loop indefinitely is not useful autonomy.
Production changes, destructive operations, sensitive data access and risky migrations should remain separately authorised. Permissions written in a task document need to be enforced by workspace isolation, credentials and release controls. They are not a substitute for those controls.
A limit to the loop. A clear next decision.
Failed checks return for bounded remediation only while the task remains within scope. Otherwise the run stops with evidence for a person to review.
High-level workflow illustration. Explore horizontally on smaller screens.
What stakeholders should be able to see
- Requester: the agreed problem, current state, blockers and the next review action.
- Product owner: acceptance criteria, scope decisions and a preview of the proposed behaviour.
- Technical reviewer: the versioned change, validation results and remaining risks.
- Release owner: an explicit approval boundary, a checked build and a rollback plan.
- Operations: bounded execution, cancelled or failed runs, and recoverable handovers.
How we are applying the approach at JAS
We are applying these principles to the development workflows we use ourselves. The work brings project context, structured tasks, execution tracking and review evidence into a more connected handover between planning and implementation.
Our internal development is building towards a provider-independent workflow in which the orchestration retains responsibility for permissions and state, while an execution agent performs a defined piece of work. Reviewed project context and clear work packages are part of that direction; broader unattended execution is developed and evaluated in stages.
We distinguish what a worker has produced from what the team has accepted. We are not presenting this as an already proven, fully autonomous production-release system. Human accountability and controlled releases remain part of the working model.
Start with one connected delivery
The first pilot should take one well-understood task from intake to a reviewable change and a reliable status update. Establish that path before adding more agents, a visual workflow designer or a larger planning framework. A single controlled worker can be a useful starting point.
Measure accepted changes rather than activity alone: whether the acceptance criteria hold, whether a valid change proposal reaches review, how often a person has to rescue a run, and whether the evidence is complete enough to reproduce the result. Track execution time and cost alongside quality. Proposed targets only become credible once the pilot has produced measured results.
Planning and execution can also mature at different speeds. Keep the definition and division of work supervised initially; extend autonomy only where the evidence supports it. The aim is a shorter path to a useful, accountable change, with the next person always able to understand what happened.