Superintelligent Agents for Excavators: Dig Tickets and Crew Schedules

An AI agent can help an excavation contractor today in two places: reading incoming locate tickets and checking them against planned digs, and keeping crew schedules consistent with ticket validity, equipment and operator availability. The agent works from records you already keep, such as utility notices, the job calendar and the dispatch board, and it prepares drafts and alerts for a dispatcher or superintendent to approve. A managed setup is worth a call when those records span several people and systems, and someone needs to keep the agent accurate after the first few weeks.

Key takeaways

• Start with one role: locate ticket intake and expiry checks, before attempting full dispatch automation.
• Give the agent read access to ticket notices, the job calendar and crew records, and write access only to drafts.
• Treat a ticket as valid for a dig only when its location, dates and work type match the planned work.
• Keep locate submissions, dispatch changes and crew reassignments with a named person.
• Judge success with one observable check: every planned excavation has a matching, unexpired ticket on the day it starts.

What an excavation contractor can hand to an agent today

Excavation work runs on a chain of records that already exists in most companies: utility notifications, a job list, a crew calendar, equipment logs and the notes a foreman writes at the end of the day. An agent is useful where that chain is slow to read and easy to get wrong. That is mostly the reading and matching, not the digging itself. Locate tickets are a strong first candidate because they arrive as structured notices with clear dates, and a mismatch between a ticket and a planned dig is a question a person can answer quickly once someone surfaces it.

Some work should stay with people. Deciding how to dig near a marked utility, judging what the marks mean on the ground, calling a utility owner when a response is unclear, and assigning an operator to a site with a known hazard all depend on judgment and on conditions an agent cannot see. An agent can prepare the information for those decisions. It should not make them.

How locate tickets go wrong on a live job

Most locate problems are not dramatic. They are small mismatches between two records that survive until the morning of the dig. The patterns that cause the most trouble tend to look like this:

• A ticket was filed for the address on the plans, but the crew moved the trench to the adjacent lot during site setup.
• A ticket was valid when the job was booked, then the start moved and the ticket window no longer covers the work.
• Two people filed tickets for the same job, and only one of them was recorded in the job file.
• Markings faded or were partly disturbed after rain, and nobody on site knew who to contact.
• The scope changed from a shallow repair to deeper excavation, and the ticket still describes the old work.

Each of these is a comparison between records that already exist. That comparison is the core task for an agent. Problems that cross from one job into another, such as a ticket that expires during a delayed start, follow the same exception-handling logic described for logistics planning.

The rules the agent checks matter more than the software. Notification requirements and validity windows are set by local rules and by the one-call or utility notification system in your region. Copy those rules from the official source, have the person responsible for compliance confirm them, and do not let the agent or a vendor invent them.

A step-by-step plan for the first ticket agent

A first engagement can stay small. This sequence keeps the scope honest:

• Name one owner on the contractor side who signs off on the match rules and the expiry rules.
• List the sources the agent may read: the notification inbox or portal export, the job calendar and the crew assignment sheet. Leave out anything the first role does not need.
• Write the match fields in plain language: address or site outline, ticket number, work type, planned start, ticket validity period and utilities notified.
• Define the outputs. A morning digest and one draft message to the office for each problem are enough at the start. The agent sends nothing.
• Give every source read-only access, and give the drafts folder as the only place the agent can write.
• Test on past jobs. Ask a dispatcher to label each flag as correct, wrong or missed, and keep that log.
• Run the digest every working day for a fixed period, and review the labels weekly before widening the scope.
• Add crew suggestions only after the ticket checks have been reliable long enough that the owner trusts the flags.

Treat every ticket notice, customer email and field note as untrusted text. A notice can contain wording that looks like an instruction to the agent, and the agent should handle that wording as data, never as a command. The OWASP guidance on prompt injection describes this pattern and the design choices that reduce its impact, such as limiting what actions the agent can trigger without approval.

Crew schedules: where agents help and where they should not decide

Crew scheduling carries many constraints that a board already shows: operators, machines, transport, site access hours, inspection visits and weather. An agent can scan these for conflicts. Typical examples include an operator booked on two sites, an excavator assigned to a job while its trailer is committed elsewhere, a dig on the calendar with no matching ticket, or a site access window that closes before the planned work finishes.

Illustrative scenario: A contractor runs three crews. A trenching job for a water service is moved forward one day after a customer request. The agent notices that the existing ticket covers the original date but not the new one, and that the only certified operator for that machine is assigned to another site on the new date. It writes a digest for the dispatcher listing both problems, a draft request to renew the ticket for the new date, and two alternative operator options taken from the crew sheet. The dispatcher decides which option to use. The agent does not send the renewal or change the assignment.

Field businesses that match crews to dated jobs face similar patterns. The same discipline appears in moving companies, where crew availability and job dates have to agree before a truck is loaded. Equipment availability and return dates, which affect excavator and compactor schedules, follow the logic described for equipment rental.

Where the approval boundaries belong

The agent should hold the least access that the role needs. In practice that means read access to the notice inbox, the job calendar, the crew sheet and the equipment log, and write access only to a drafts folder and the daily digest. The agent should not hold stored credentials that can submit locate requests, change dispatch or message customers. Each permission should be written down with a named owner, and checked again each time a source or tool changes. OWASP's authorization guidance is a useful reference for checking access on every action, not only when the setup is first configured.

A simple boundary list helps the team agree on the rules before the first run:

• The agent may read: the notice inbox, the job calendar, the crew sheet and the equipment log.
• The agent may write: drafts and the daily digest. Nothing is sent.
• A person must approve: any locate request, any ticket renewal submission, any dispatch change and any customer message.
• A person must review monthly: the permission list, the source list and the flag log.

Be Human designs, implements and operates this kind of setup for companies. A first engagement defines one useful role, the memory and tools that role needs, the approval boundaries and an observable success criterion, which for a ticket agent is whether each planned excavation has a matching, unexpired ticket on its start day. Managed operations can then cover monitoring of the flags, recurring evaluations against the dispatcher's labels, maintenance when an inbox or calendar integration changes, permission reviews and incident response if a source or the agent behaves unexpectedly. The NIST AI Risk Management Framework is a helpful reference for mapping these risks and recording who approved what.

When a managed setup is worth a call

Many contractors can run a first version with a shared spreadsheet and one careful office person. A managed setup becomes worth a call when the work has outgrown that arrangement. Typical signs include:

• Tickets arrive through several channels, and the same job appears under different names in each.
• Crews, equipment and subcontractors are scheduled in more than one tool, and nobody owns the join between them.
• Foremen or office staff rotate, and the match rules live in people's heads rather than in a written file.
• The flags are being ignored because they are wrong too often, and someone needs to tune them through evaluation rather than guesswork.
• Permissions have grown over time, and nobody has reviewed what the agent can reach.

Whether this applies is a question about your records and your people more than about any model. If the answer is unclear, start with one role and one success check, and keep every decision with the people who already own it. Take the free Be Human AI diagnostic to find the first task in your operation that is worth handing to an agent.

Frequently asked questions

Can an AI agent file locate requests for us? Not at the start, and it is not necessary to begin there. The agent can read notices, compare them with the job file and prepare a draft request for a person to check and submit. Giving it submission rights is a separate decision that should follow a stable record of flags and a written permission review.

Do we need new scheduling software before we start? Usually not. A first version can read the spreadsheets, calendar exports or board data you already keep, provided the job names, addresses and dates are consistent enough to match. If the records are inconsistent, the first useful work is often cleaning up those fields, which a person should approve even if the agent helps list the mismatches.

What about emails or notices that contain unusual instructions? Ticket notices, customer emails and field notes are untrusted text. Any instruction inside them should be treated as data, not as a command, and the agent should not have tools that let such text trigger actions without approval. The OWASP guidance on prompt injection covers this pattern in more detail.

How do we know the agent is doing its job? Start with one measure: whether each planned excavation has a matching, unexpired ticket on its start day. Compare the agent's flags with the dispatcher's labels each week, and track missed problems as carefully as false alarms. Widen the scope only when that record has been stable for long enough that the owner trusts it.

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