Choose a bounded workflow
Agents can help with tasks such as implementation, test generation and incident investigation. Start with a workflow where the team can define an acceptable result and recognise a failure.
An FDE works with engineers and users to decide what the agent may do, what it may propose and which actions need human approval. Those boundaries should reflect the consequences of an error.
Connect the context the agent needs
Useful context may include code, architecture, APIs, requirements, tests, incidents and documentation. Access to more material is not automatically better. The information needs to be relevant, current and authorised.
The FDE maps these sources, sets access boundaries and agrees how updates will reach the agent. Testing should check whether the agent uses that context correctly and responds appropriately when information is missing.
Build controls into the workflow
Decide which models and tools are approved, what data they can access and where activity is recorded. Add review and evaluation at the points where they can prevent an unsafe or incorrect action.
Drafting documentation and changing a production system carry different risks. Use stricter permissions and approval requirements for actions with greater consequences, and make it possible to stop or reverse the workflow when needed.
Measure the result after human review
Track how long it takes to reach an accepted change, alongside defect rates, security findings, review effort and cost. Include the time people spend checking and correcting the agent’s output.
Use those results to decide whether to expand, revise or stop the pilot. The aim is a delivery practice the team can operate and improve, with evidence that the agent is helping.
