AI agent workflows for Drone services & aerial survey

Build spec

1 agent — 1 brief-assembly agent. The parallel lookups, the expiry banding (Code + SpEL tool), the blocking-item branch and the pilot sign-off are workflow nodes — deliberately, because the go/no-go must not sit inside a model. · Pattern: Parallel evidence gathering → deterministic expiry banding → assembly agent → pilot-in-command approval

System prompt (paste-ready)

You assemble a PRE-FLIGHT BRIEF for {{operator}}. You do NOT grant, imply or withhold clearance — a pilot-in-command decides that. Inputs: mission {site_coords, datetime, airframe, pilot}, airspace/zone lookup results, permission + airframe + pilot validity records with their computed expiry bands, client site conditions, and the operations manual in your Knowledge collection. Return {checks[{name, status (PASS|FAIL|UNVERIFIED), source, checked_at, note}], blockers[], unverified[], summary}. Mark UNVERIFIED — never PASS — whenever a lookup failed, returned nothing, or returned data older than the manual's freshness rule. Never infer a zone classification, a permission validity or an expiry date that was not returned, and never recompute an expiry band yourself. Never write 'cleared', 'approved to fly' or any equivalent anywhere in your output.

Agent roles & model tiers

• Pre-flight brief assembler — Standard tier with a fallback model — one call per mission, low volume, and faithful citation of regulatory evidence matters far more than the tier saving; the fallback exists so a provider outage never becomes a reason to fly on an unwritten check

  Assemble every check with its source and timestamp, force failed or stale lookups to UNVERIFIED, surface blockers first, and never state or imply clearance.

Guardrails

• The workflow NEVER issues clearance — the go/no-go is the pilot-in-command's decision at the Approval node, and the agent is prompt-forbidden from writing 'cleared' or any equivalent
• A failed, empty or stale lookup becomes UNVERIFIED, never PASS — unverified items are surfaced at the top of the brief and can never be silently dropped
• Expiry bands are computed by the tenant's SpEL formula, not read off by the model; a null or missing date yields UNVERIFIED by construction
• Every check carries its source and a checked_at timestamp, so the brief is auditable after the flight rather than a snapshot of nothing
• Where the operator's own manual is stricter than the baseline regulation, the manual wins — the agent grounds in the scoped Knowledge collection, not in general knowledge
• The signed brief is attached to the mission record with the approver's identity, giving a defensible trail of what was checked and who accepted it

Cost strategy

One standard-tier call per mission and no batch multiplier — volume is bounded by how many flights you actually fly, making this among the cheapest recipes here per run. Do not cheapen it further: the whole value is faithful citation of regulatory evidence, and a hallucinated zone classification is not a cost saving. The Parallel node buys wall-clock speed at zero extra model cost because the lookups are tool calls rather than agent turns, and the expiry arithmetic is a free SpEL evaluation rather than an inference.

Output & delivery

The Parallel node fires the airspace, registry and site-condition lookups at once → the Code node bands every validity date with the operator's SpEL formula → the agent assembles a source-cited brief with blockers and unverified items first → the Condition node keeps anything unverified visible → the pilot-in-command signs off at the Approval node → an Output node files the signed brief against the mission record and pushes it to the crew on Slack, WhatsApp and Email.

Build spec

2 agents — 1 flyability checker (runs once per upcoming mission per watch cycle via the Loop node) + 1 reschedule proposer (runs only for marginal-or-worse missions). The wind banding, the approval and the calendar write are workflow nodes. · Pattern: Map (cheap per-mission check) → Condition filter → proposer on the exceptions only → human approves the client-facing move

System prompt (paste-ready)

(Flyability checker) Assess ONE booked drone mission's weather window. Inputs: mission {site_coords, window_start, window_end, airframe}, the forecast for that site and window, the computed wind band, and the airframe's operating limits from your Knowledge collection. Return strict JSON {verdict (FLYABLE|MARGINAL|NOT_FLYABLE), limiting_factors[{factor (WIND_MEAN|WIND_GUST|VISIBILITY|PRECIP|CLOUD_BASE|LIGHT), forecast_value, limit_value}], confidence_note}. Compare ONLY against the documented limits — never soften a limit, never average a gust away, never override the computed wind band, and never mark FLYABLE on a missing forecast field (return MARGINAL with the gap named). You do not reschedule or contact anyone.

Agent roles & model tiers

• Flyability checker (per mission, per watch cycle) — Economy tier with a fallback model — it runs across every upcoming mission on every cycle, making it by far the highest-volume step here and the dominant cost lever twice over

  Combine the computed wind band with visibility, precipitation, cloud base and light against documented limits, and return FLYABLE / MARGINAL / NOT_FLYABLE with the exact figures. Missing forecast data ⇒ MARGINAL, never FLYABLE.

• Reschedule proposer (exceptions only) — Standard tier — multi-constraint reasoning across forecast, site access hours and crew availability; it only ever runs on missions the Condition node flagged

  Propose ranked alternative windows that clear the documented limits and fit the site's access hours and crew availability, each with the reason it clears. Propose only — never message the client, never write the calendar.

Guardrails

• No client is contacted and no booking is moved until ops approves at the Approval node — the agents propose windows, they never commit one
• Flyability is decided strictly against documented airframe limits, with the wind margin applied by the tenant's SpEL formula; the agent is forbidden from softening a limit, averaging away a gust, or overriding the computed band
• A missing or partial forecast yields MARGINAL, never FLYABLE — the absence of bad news is not treated as good news, and a null gust value is banded MARGINAL by construction
• FLYABLE missions produce no notification at all, so the alerting stays credible instead of becoming background noise the crew learns to ignore
• The mission write-back is keyed to the mission id, so repeated watch cycles cannot create duplicate reschedules

Cost strategy

This runs on a schedule, so per-run cost multiplies by CYCLES as well as by missions — which is exactly why the checker sits on the economy tier with a hard cap and a fallback model. The expensive proposer only runs on missions the Condition node flagged, so a settled week of good weather costs almost nothing. The wind banding is a free SpEL evaluation rather than an inference. If you want more value, widen the watch window before you upgrade the checker's model — earlier warning is worth more than a smarter forecast reader.

Output & delivery

The scheduled watch loops the economy-tier checker over every upcoming mission, with the SpEL wind band computed first → the Condition node lets FLYABLE pass silently and forwards the rest → the standard-tier proposer drafts ranked alternative windows → ops approves at the Approval node → an Output node offers the options to the client on WhatsApp/Email, and on their pick a Tool (MCP) node updates the mission and Slack notifies the crew.

Build spec

3 agents — 1 vision pre-filter (runs once per frame via the Loop node) + 1 expert classifier (flagged frames only) + 1 report writer (once). Loop, Parallel, the asset join, the severity banding and the sign-off are workflow nodes. · Pattern: Two-stage vision funnel: cheap per-frame filter → expert pass on survivors → client-specific banding → report writer → qualified human signs off every finding

System prompt (paste-ready)

(Pre-filter) Look at ONE inspection frame. Your ONLY job is to decide whether it plausibly contains an anomaly worth an expert look. Return strict JSON {candidate (true|false), hint (THERMAL_ANOMALY|SURFACE_DAMAGE|STRUCTURAL|OBSTRUCTION|NONE), frame_ref, unusable (true|false)}. Be deliberately generous: a false positive costs one extra expert call, a false negative loses a real defect — when uncertain, return candidate=true. Do NOT classify the defect, do NOT assign severity, do NOT name an asset. If the frame is unusable (blurred, over-exposed, obscured), return candidate=false with unusable=true so coverage can be reported honestly.

Agent roles & model tiers

• Vision pre-filter (per frame) — Economy tier, vision-capable, with a fallback model and a hard token cap — it runs on EVERY frame, so it alone determines whether the recipe is affordable, and a mid-batch provider outage must not orphan a flight

  Binary candidate/not-candidate per frame, biased toward false positives. No classification, no severity, no asset naming. Flag unusable frames so coverage gaps are reported.

• Expert defect classifier (candidates only) — Premium tier, vision-capable — the hard step, affordable precisely because it only ever sees the small surviving fraction

  Classify each candidate frame against the client's asset taxonomy in the scoped Knowledge collection, with defect type, severity and the visual reasoning. Return UNCERTAIN rather than guessing; never infer a defect from context outside the frame.

• Report writer (once) — Standard tier — synthesis and client-facing writing, one call per inspection

  Group the confirmed findings by the computed priority band and by asset, cite each frame reference and resolved location, and list explicitly the areas the flight did not adequately cover. Never add a finding that is not in the classifier output, and never soften or upgrade a severity.

Guardrails

• No finding reaches the client without the inspection lead confirming, downgrading or rejecting it at the Approval node — a model defect call is never a work order
• The pre-filter is prompt-biased toward false positives: an extra expert call is cheap, a missed defect is not
• The expert classifier may return UNCERTAIN and must not infer a defect from anything outside the frame it was given
• Priority banding comes from the tenant's SpEL rule, so the model never quietly re-prioritises a client's contractual severity mapping
• Unusable frames (blur, over-exposure, obstruction) are tracked and reported as coverage gaps — the report says what was NOT adequately inspected, so silence is never mistaken for a clean bill
• The report writer cannot add findings or shift a severity beyond the classifier output; the report is grouped, not reinterpreted
• Findings are keyed to frame reference and resolved asset id, so a re-processed flight cannot duplicate a defect against an asset

Cost strategy

This is the clearest tiering case in the guide. The pre-filter runs on EVERY frame — thousands per flight — so it must be the cheapest vision-capable model available, hard-capped, with a fallback so a mid-batch outage does not orphan the flight; that one choice sets the cost of the whole recipe. The premium classifier is affordable precisely because it only ever sees the small surviving fraction, and the report writer runs once. Inverting this (premium on every frame) is what makes full-coverage review economically impossible — which is why the manual process quietly became sampling. Parallel batching cuts elapsed time without touching per-frame cost, and the priority banding is a free SpEL evaluation.

Output & delivery

The Loop and Parallel nodes run the economy-tier pre-filter across every frame → surviving candidates go to the premium classifier → a Tool (MCP) node resolves each finding to a real asset via the geotag, flight log and GIS registry → the Code node bands priority with the client's own SpEL rule → the writer drafts the report with an explicit coverage-gap section → the inspection lead signs off each finding at the Approval node → an Output node emails the signed report and a Tool (MCP) node files it against the asset registry with the sign-off recorded.

Build spec

1 agent — 1 capture-assessment agent. The arithmetic (Code nodes + SpEL tool), the completeness gate, the approvals and the processing run (Sub-workflow) are workflow nodes — the numbers are computed, not reasoned. · Pattern: Deterministic Code checks → operator tolerance formula → agent explains against the spec → completeness gate → human approves reflight or deliverable commitment → Sub-workflow processes

System prompt (paste-ready)

You assess whether a completed drone flight supports its CONTRACTED deliverable for {{operator}}. Inputs: the computed capture summary {frames, planned_waypoints, geotagged_pct, mean_overlap, overlap_shortfall_pct, altitude_variance, gcp_count, log_gaps[]} and the job spec from your Knowledge collection {product, target_gsd, coverage_polygon, accuracy_class}. Return {supports_deliverable (true|false|UNCLEAR), gaps[{area_or_metric, computed_value, spec_value, consequence}], reflight_scope (NONE|PARTIAL|FULL), plain_summary}. Use ONLY the computed numbers you were given — never estimate coverage, overlap or GSD yourself, never recompute a shortfall, and never restate a computed figure differently. If a required metric is missing, return UNCLEAR and name it. You do not authorise a reflight, start processing, or promise a delivery date.

Agent roles & model tiers

• Capture-vs-spec assessor — Standard tier with a fallback model — one call per flight, reasoning over a small computed summary rather than over imagery, so it stays cheap without dropping a tier; the fallback matters because this check is time-critical while the crew is still near the site

  Compare the computed capture summary to the contracted spec, name every gap with its computed and required value and the consequence, and scope the reflight. Never recompute or estimate a metric; a missing metric yields UNCLEAR.

Guardrails

• The agent never authorises a reflight, starts processing or promises a date — the Approval node gates both the reflight (crew cost) and the deliverable commitment (client promise)
• All capture metrics are computed deterministically in Code nodes and the tenant's SpEL formulas; the agent may only explain them, never recompute, estimate or restate them differently
• The completeness gate blocks processing on any material gap — a partial capture cannot slide through and become a failed client deliverable two weeks later
• A missing required metric yields the sentinel value and routes to UNCLEAR for a human, rather than being reasoned into a pass
• The processing run is started only once per flight id via the Sub-workflow node, so a re-uploaded flight cannot double-bill a processing job

Cost strategy

Cheap by construction: the expensive work — counting frames, checking geotags, measuring overlap, banding the shortfall — is deterministic Code and SpEL, not model inference, so exactly ONE standard-tier call per flight reads a small computed summary. Resist the temptation to have a model 'look at the imagery' to judge coverage; that inverts this recipe's cost profile for a worse answer. Per-flight cost stays flat as frame counts grow, because it never scales with imagery volume.

Output & delivery

The Code nodes compute the capture metrics and the operator's shortfall band the moment the upload lands → the agent explains them against the contracted spec → the Condition node's completeness gate blocks any material gap → the survey lead approves either the scoped reflight or the deliverable commitment at the Approval node → a Sub-workflow node submits and tracks the processing job → an Output node tells the client the confirmed deliverable and date, or the honest reflight reason and revised date, on Email/WhatsApp with the crew notified on Slack.