Follow one inspection task

What does one agent task look like, from request to confirmed result? Follow a utility agent that checks vegetation risk on a power line circuit. The task has an owner and a boundary. The agent gathers evidence and fills the gaps. It proposes one allowed action, and a separate service checks it. Then it confirms what really happened, and stops.

1. Give the task an owner and a boundary

The request reads: "Investigate possible vegetation risk on this circuit and prepare inspection requests." Record the circuit, the deadline, the allowed systems and the person responsible. The task permits an inspection request, not equipment switching or tree removal. Switching equipment is safety actuation, one of the deterministic zones, so it stays out of reach. What kind of agent this is follows from the four questions: its role, its permissions, its autonomy and its impact.

2. Gather evidence

Read asset coordinates, image dates, previous inspections and current work orders. Keep the original image reference and the date of each observation. A location match is only a possible link until it is checked against the asset record. Each source keeps its trail, as in the data-to-memory pipeline.

3. Resolve the missing information

If the imagery is too coarse or too old, seek better observations or propose a field inspection. If a work order already exists, link the finding to it. A repeated investigation should ask a specific question each time. It should not collect data without a rule for when to stop.

4. Request the permitted action

The model proposes a structured inspection request. The work-order service checks permissions, required fields, duplicates and any review requirement. The agent cannot grant itself more authority by changing its prompt. These checks sit outside the model, as set out in enforcement outside the model. The request carries the identity of the person who asked, through the delegation chain.

5. Confirm and report

Read the accepted work-order identifier and status. A successful API request is not proof that a field inspection happened. Report what was created, what still needs review, and what evidence supports the priority. An audit trail the agent cannot change supports any later investigation.

When to stop

Stop when any of these happens: an inspection request is confirmed, a duplicate is resolved, or the evidence is insufficient. Also stop when the time or cost limit is reached, or when a responsible person must decide. Keep enough state to resume without repeating a completed action.

Apply the design

Explore vegetation inspection, the integration fabric layer (R03) and the systems of record layer (R04).

Evidence and limits

This is a proposed design, not a deployed agent. The repeated investigation follows the reason-and-act pattern described in ReAct (2022). The specific operational design here is a proposal.

Next step

Name what kind of agent did that work with the four questions.

Explore this topic

• ReAct: reasoning and acting with language models. Accessed 17 September 2026.