-
-
Loging
-
Operation
-
Operation
-
Operation
-
AI analysis
Inspiration Agricultural drone operations depend on much more than the aircraft itself. A single job may require batteries, generators, charging stations, RTK equipment, support assets, maintenance plans, and current operational readings.
In the field, this information is often spread across spreadsheets, messaging apps, paper notes, and the operator’s memory. That makes it easy to overlook an assigned resource, discover overdue maintenance too late, or mobilize equipment that requires attention before the operation begins.
AgroPilot Pro was created to centralize the operational, technical, commercial, and maintenance workflows of agricultural drone teams. For OpenAI Build Week, we wanted to go one step further: transform the information already stored in the platform into a clear, preventive, and actionable readiness assessment.
What it does
AgroPilot Intelligence evaluates whether the resources assigned to an agricultural drone operation are ready for the planned date.
When creating an operation, the user assigns the drone, batteries, generator, and support assets, then selects “Save and Evaluate Readiness.” The operation is saved first, ensuring that an external service failure never deletes the user’s work.
A deterministic engine then evaluates:
Whether required resources were assigned and successfully loaded. The current operational state of each asset. Available usage readings. Existing maintenance plans and records. Whether maintenance is overdue, approaching, or scheduled before, during, or after the operation. Whether enough reliable information exists to complete the assessment.
The engine produces one protected classification:
Prepared Review Recommended Priority Attention Insufficient Data Not Evaluable
GPT-5.6 then receives the controlled findings and turns them into a concise explanation for the operator. The result identifies what requires attention, which asset is affected, which date matters, how that date relates to the planned operation, and what action should be considered.
GPT-5.6 does not decide whether the operation is prepared. It cannot change the deterministic classification or invent new evidence.
What existed before Build Week
AgroPilot Pro already existed as a functional Android platform for agricultural drone operations. Before Build Week, it included workflows for:
Clients, farms, fields, and crops. Quotations and invoices. Agricultural operations and technical parameters. Drones, batteries, generators, and support assets. Preventive and corrective maintenance. Maintenance alerts and Android notifications. Operational and commercial reports. Payments, receivables, costs, and profitability. PDF, PNG, XLSX, and text exports.
The pre-Build Week baseline contained 337 passing Flutter tests.
What we built during Build Week
During Build Week, we added the complete AgroPilot Intelligence operational-readiness workflow:
A deterministic readiness engine written in Dart. A minimized and traceable operational context. Protected classification rules. Maintenance-to-operation temporal analysis. A secure Firebase callable backend. OpenAI Responses API integration with GPT-5.6. Structured Outputs with strict validation. Persistent assessments and evaluation history. Input hashing and idempotent reuse. A local fallback when AI is unavailable. A complete mobile interface for creating, evaluating, reviewing, and updating assessments. Clear explanations, important dates, affected assets, and recommended actions. A “How this result was obtained” section explaining the roles of deterministic rules and AI.
The final validation reached 438 passing Flutter tests and 18 passing backend tests.
How we built it
The Android application is built with Flutter and Dart. Firebase provides authentication, Firestore persistence, and a second-generation Cloud Function running on Node.js 22.
The evaluation flow is:
Flutter loads the operation and its assigned resources. Each data source preserves whether it was loaded, empty, unavailable, failed, or not required. A context assembler creates a minimized operational snapshot. The deterministic Dart engine calculates the classification and evidence. The deterministic result becomes available immediately in the interface. A Firebase callable validates authentication and company ownership. The backend sends only the required structured context to the OpenAI Responses API. GPT-5.6 returns a validated Structured Output. The backend verifies that the narrative preserves the deterministic classification. The completed assessment is stored and returned to the application.
The OpenAI API key never exists inside the Flutter application. It remains protected in Google Secret Manager.
The backend validates the authenticated user, active company, operation ownership, input hash, schema version, and model response before accepting the result.
The exact resolved GPT-5.6 model is retained for internal auditability, while the user interface displays only GPT-5.6. We also completed an authenticated end-to-end validation using GPT-5.6 Sol.
Safety, privacy, and reliability
We intentionally designed GPT-5.6 as an assistant rather than an operational authority.
The model cannot:
Authorize a flight. Change the readiness classification. Replace an equipment inspection. Invent maintenance evidence. Mark missing information as verified. Recommend pesticide mixtures or application doses.
The context sent to OpenAI excludes unnecessary sensitive information such as client identities, serial numbers, financial values, quotations, invoices, and profitability data.
Every evaluation includes a disclaimer explaining that it supports decision-making but does not replace technical inspection, operator checklists, or the responsible person’s final decision.
An inputHash represents the relevant evaluation context. Repeating an assessment without changing the data reuses the stored result instead of creating a duplicate OpenAI request. When the context changes, a new assessment is created while previous evaluations remain preserved.
When GPT-5.6 is unavailable, AgroPilot Pro still displays the deterministic classification, findings, limitations, and a local summary. The interface never labels fallback content as GPT-5.6 output.
How we used Codex
Codex served as our engineering collaborator throughout Build Week.
It inspected the existing repository before implementation, helped structure the work into controlled macro-blocks, generated and refined code, expanded automated test coverage, reviewed diffs, and supported validation across Flutter and Firebase Functions.
Codex also helped diagnose several important technical issues, including:
Structured Outputs schema restrictions. Idempotent persistence behavior. Backend authorization and validation paths. Responsive interface overflows. Internal status codes leaking into user-facing text. Flutter reconstruction problems caused by reused single-subscription streams. The transition between deterministic results, GPT-5.6 loading, successful AI output, and local fallback.
Product scope, safety boundaries, architecture decisions, field terminology, and final validation remained under human control.
Challenges we ran into
The largest challenge was integrating generative AI without allowing it to become the source of operational truth.
We solved this by separating responsibilities: deterministic rules own the classification, while GPT-5.6 explains only verified findings.
Structured Outputs also required careful schema design. Some initially valid-looking JSON Schema features were unsupported by the API, so we simplified the schema while preserving strict backend validation.
Another challenge was making a technically complex assessment understandable in a few seconds. Early versions exposed internal codes and technical metadata. We redesigned the interface around practical questions:
What requires attention? Which asset is affected? What date matters? Does it occur before, during, or after the operation? What should the operator review? Accomplishments that we are proud of Integrated GPT-5.6 into a real agricultural operations platform rather than an isolated prototype. Preserved deterministic control over operational classifications. Completed an authenticated GPT-5.6 end-to-end evaluation. Implemented secure multi-company authorization. Added persistent and idempotent AI assessments. Created a useful fallback that remains available without AI. Increased the Flutter suite from 337 to 438 passing tests. Completed 18 backend tests. Generated a working Android APK. Kept sensitive operational and commercial data out of the AI context. Built a mobile workflow designed around real field decisions. What we learned
The most valuable role for AI in operational software is not replacing rules or professional judgment. It is making complex, verified information easier to understand and act upon.
We also learned that a strong AI feature depends heavily on the systems around the model: structured data, deterministic calculations, security boundaries, validation, persistence, failure handling, and clear user experience.
GPT-5.6 became significantly more useful when it was given a narrow responsibility and reliable evidence.
What’s next
Our next planned intelligence capability is AgroPilot Mix Intelligence, an evidence-based assistant for evaluating agricultural product-mixing risks.
It would consider product labels, active ingredients, formulation types, water quality, order of incorporation, physical compatibility, and jar-test requirements. As with operational readiness, AI would explain documented evidence rather than freely declaring a mixture safe.
Longer-term plans include agronomic follow-up after applications, treatment comparisons, crop-response timelines, advanced operational analytics, Web and Windows versions, and integrations with weather stations, GIS platforms, sensors, and drone telemetry.
Our broader vision is to transform every agricultural drone operation into reusable operational knowledge—helping teams become safer, more prepared, and more efficient with every job.
Log in or sign up for Devpost to join the conversation.