Superintelligent Agents for Well Drilling: Permits and Site Notes

An AI agent can help a well drilling company assemble permit packages and site notes today by gathering the job facts, checking them against the permitting authority's current checklist, and drafting the packet for a licensed person to review and submit. The most useful work is not the model itself but the job memory: a structured record for each well that holds the site facts, sources, open questions and change history, and that the agent reads and updates under human control. Companies that build this record now create the foundation a more capable system could later use, without giving it authority it has not earned.

Key takeaways

• An agent can assemble and check a permit packet, but a licensed person decides what is submitted and who signs.
• Site notes captured as structured fields are far more useful to an agent than scattered phone photos and crew texts.
• Each job needs its own memory: a stable identifier, parcel reference, measured facts, observations and open items.
• Permissions should start narrow: read access to job records, write access only to a draft folder, and no submission rights.
• Text copied from emails, field notes and third-party documents is data to be checked, never instructions to follow.

What belongs in a water well permit package?

Requirements differ by county, state, province and municipality, so the current form from the permitting authority is always the reference. In general, a packet gathers the owner and property identification, the proposed well location relative to the site plan, setback distances from known features such as septic components, property lines and existing wells, the intended use of the water, the driller's license details, and the planned construction method. Many jurisdictions also require a completion report or driller's log after the work is done, which means the packet process should connect to the field record from the start.

The first operational task is to turn those requirements into a versioned checklist for each jurisdiction you work in. Store the checklist as a document with a date and an owner, and link each job to the version that applied when the packet was prepared. Otherwise the knowledge lives in whoever handled the last permit, and it leaves when that person does.

Where the agent fits and where it stops

An agent is well suited to the repetitive middle of the job. It can pull the owner's details from the intake form, match them to the parcel record the client provided, notice that a setback measurement is missing, draft a cover letter, and produce an index of attachments. It should not decide whether a location meets a setback rule, sign a statement on behalf of a driller, or contact an authority or landowner without a person approving that message. The NIST AI Risk Management Framework is useful here because it asks organizations to define who is accountable for each output, measure how the system performs, and keep people able to intervene.

A simple decision guide helps staff agree on the boundaries before anything is configured:

• The agent may draft cover letters, field summaries, packet indexes and missing-item lists.
• The agent may check completeness against the current checklist and consistency between the site sketch and the intake form.
• The agent may flag a possible conflict, such as a proposed location near a septic field, but a licensed person resolves it.
• The agent may not submit a packet, sign anything, alter a certified measurement, or message an authority or landowner without explicit staff approval.

How do you turn site notes into job memory?

Most drilling companies already capture site information, but it often sits in phone photos, crew group messages, paper daybooks and a spreadsheet nobody updates. Job memory means organizing the same facts into one consistent record per job. The goal is not a perfect database. The goal is that a person or an agent can answer the question what do we know about this site, and where did each fact come from?

1. Create one job record per well with a stable identifier, the owner, the parcel reference, the assigned crew and the jurisdiction checklist version. 2. Separate measured facts, such as coordinates, distances, depth to water and casing details, from observations, such as ground conditions, access problems and client remarks. 3. Attach a source to every measured value: the photo, form or log it came from, the person who recorded it and the time it was recorded. 4. Record open questions as items with an owner and a due date, so the agent can list them instead of guessing at them. 5. Log every change to the record, whether made by a crew member, a staff member or the agent, with a short reason. 6. Review the record before any packet leaves the office, and treat the reviewed version as the one that counts.

A similar pattern appears in engineering firms that keep project memory, where the value comes from linking each decision to the document that supports it. For drilling, the same discipline lets a later, more capable system answer from the job's own history rather than from a general guess.

An illustrative scenario: a residential well packet

The following is an illustrative scenario, not a report of a real client. A two-crew drilling company receives a request for a new residential well on a rural parcel. The intake form lists the owner and the parcel number, and the job record already includes a site sketch from a prior visit. The sketch shows a septic field close to the proposed well location. The agent reads the job record, flags the proximity as a possible setback question, drafts the packet with the sketch attached, and produces a list of three missing items: a signed owner authorization, a revised sketch with dimensions, and confirmation of the current application form version. It sends that list to the office coordinator through the internal queue.

The licensed driller visits the site, confirms the distances, and moves the proposed location. The coordinator updates the job record with the new measurement and its source. The agent then regenerates the packet index and marks the draft as ready for review. Nothing was submitted by the agent. The value was that the question surfaced early, while the office still had time to resolve it, and that the reasoning was recorded for the next reviewer. For a related pattern built around reusable templates, see parametric septic design notes an AI agent can fill.

How do you control permissions, untrusted text and review?

Access should follow least privilege. OWASP's authorization guidance stresses that each action should be checked against what the actor is allowed to do, rather than assuming that a connected tool can do everything its account permits. In practice, the agent should have read access to job records, write access only to a draft folder, and no credentials for regulator portals. Portal submission should remain a human action with its own logged approval. A parallel discipline appears in security firms that keep post orders and incident logs in one agent memory, where access to records is split by role.

Second, text from outside the company is untrusted. A field note pasted from a client email, a scanned third-party report or a supplier message can contain sentences written to change how an agent behaves. OWASP's prompt injection prevention guidance treats external content as data, keeps tool actions behind explicit checks, and avoids letting free text trigger sensitive operations. Your drafting workflow should handle these inputs the same way a careful clerk would handle an unknown envelope.

Third, evaluate on real past work. Assemble a set of previous packets, including a few that were returned for missing items, and check whether the agent catches the same gaps. Anthropic's engineering guidance on context engineering makes a related point: the context an agent receives should be curated and relevant, not an undifferentiated pile of documents. Keep logs of each tool call and each draft version so reviewers can see what the agent saw and what it proposed.

How a managed setup runs, and where to start

Be Human designs and runs this kind of setup as a managed service. A first engagement defines one useful role, such as a packet assembler for a named set of jurisdictions, along with the memory and tools it needs, the approval boundaries, and an observable success criterion, for example how often packets return to the drafter for missing items. Managed operations can then include monitoring, recurring evaluations when a jurisdiction changes its form, permission reviews, incident response when a source system changes, and controlled improvements to the drafting logic. The company keeps its identity, its records and its permissions under its own control throughout.

For most drilling companies, the right first step is small: one jurisdiction, one packet type, and one job record format that the crew can fill in without extra effort. Choose the task where missing information costs the most time, and make the record good enough that the agent's output is easy to check. The free Be Human AI diagnostic can help you identify the first task in your permit and site work worth handing to an agent.

Frequently asked questions

Can an AI agent submit well permit applications for us? No, and it should not be set up to do so in a first deployment. The agent can assemble the packet, check it against the current checklist and list what is missing, but submission, signatures and any certified statements belong to a licensed person. Keeping submission as a logged human action also makes accountability clear if an authority asks questions later.

Do we need to replace our current drilling or field software to use an agent? Usually not. The agent works with the records you can export or connect, and the first improvement is often a consistent job record format rather than new software. Where a connection is not practical, a staff member can paste or upload the relevant fields into the job record, provided the source of each value is noted.

Is site data safe to give an AI agent? It depends on how the system is configured, what data is included, and what your contracts and local data protection rules require. Share only the fields the packet needs, keep credentials narrow, log access, and review the terms of any model provider you use. Customer and landowner information deserves the same care you would give it in any other office system.

How do we know the agent is producing reliable packets? You check it the same way you check a new crew member: against known cases and with a reviewer who signs off. Build a set of past packets, including ones that had gaps, run the agent on them, and compare its flags with what the office found. Repeat the evaluation when checklists change, and keep the logs so each error can be traced to the input that caused it.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.