Every civil engineer who has done site development work knows the utility research step. It comes early, before design can meaningfully start, and it’s not hard. That’s what makes it expensive. It’s a long sequence of lookups, each straightforward, that have to happen in order, for every project, every time.
I run Calichi Design Group, a civil firm with offices in Oakland, Portland, Hood River, and Haiku. We do utility research on most projects. A few years ago I stopped having licensed engineers do the lookup and draft work and built an agent to do it instead. Here’s the honest version of what the workflow actually is.
What existing utility research actually involves
Start with the site. You have a project address. You need to know who serves it for every utility type: electric, gas, telecommunications, cable, water, sewer, storm drain, and recycled water if the jurisdiction has it. You also need the fire protection district (for fire flow requirements and hydrant coordination), the encroachment permit authority (whoever issues permits for work in the right-of-way fronting the site), the drainage district, the state DOT, and the railroad operator if rail is within 500 feet of the parcel.
That’s the jurisdictional stack. It’s the same set of questions on every project. The specific entities at each layer change by state and parcel. The state DOT for a California project is Caltrans. For Oregon it’s ODOT. For Illinois it’s IDOT. For Texas it’s TxDOT. For Iowa it’s Iowa DOT. They have different encroachment permit offices, different contacts, and different submission packages.
Once you have the stack, the next step is provider research. For each entity on the list, you need to know their specific process. Not just "send them an email." Utility coordination has distinct request sub-types that route to different people inside each organization. Franchise utilities route different request types to completely different inboxes, and sending to the wrong one means your request disappears without an error message.
The primary deliverable for civil design is facility maps: overhead and underground facility records that show the designer where existing infrastructure is. That’s a different request from a records request for as-builts, which is different from a will-serve letter confirming the utility can serve the proposed development. Some providers handle joint trench coordination through a separate channel, and encroachment permits through yet another.
The practical consequence is this: a project touching four franchise utilities may require eight or ten separate outreach packages, each going to a different contact at a different address, each needing a different set of attachments. For one of those utilities, the will-serve request routes to one inbox for a commercial project and a different inbox for a residential or mixed-use project. For another, the gas delineation map request goes to a different address than the electric map request. Sending to the wrong place doesn’t produce a rejection. You just don’t hear back.
Beyond the franchise utilities, you check for roadway moratoriums. Most cities and counties publish lists of streets under a post-paving moratorium, typically three to seven years, where cutting the pavement triggers a trenchless requirement. If the project street is on that list, the designer needs to know before the civil plans are drawn. You also check for water and sewer connection moratoriums and any known capacity constraints at the serving utility.
For a site with a state route frontage, you research the relevant DOT district office and its encroachment package process. For a site near rail, you identify the operator: Class I (Union Pacific, BNSF, CSX, Norfolk Southern, CN, CP) or a regional short line. Then you find the real-estate or engineering contact for that corridor.
None of that is engineering. It’s information retrieval, process lookup, and draft writing, done with enough precision that the wrong inbox doesn’t cost you two weeks of waiting for a response that isn’t coming.
What it used to take us
At Calichi, utility research (public records, service territory, will-serve coordination) ran three to four hours per project. That’s our own production-measured number, not a projection.
The frustrating part wasn’t the ambiguous cases. The frustrating part was that most of the time came from the parts that don’t vary: who serves this parcel, what process do they use, which inbox do I send this to, which form do they want attached. Same shape every time, and the engineer doing it had to look it all up from scratch because no one had written down the last project’s contacts in a findable way.
How the agent does it now
The engineer emails the project address. From there:
- It extracts street, city, county, state, and ZIP from the address. If county or ZIP are missing, it resolves them from the city via public lookups. It resolves the APN via the county assessor portal if one wasn’t provided.
- It builds the full jurisdictional stack for the parcel: every utility type, fire district, state DOT, encroachment authority, and railroad operator, identified for the project’s actual state. Not assumed from a California pattern.
- For each entity in the stack, it checks a process cache for known provider information. Cache entries older than 90 days are re-verified against the provider’s live website before the agent uses them, so outdated inboxes don’t ship.
- For providers not in the cache, it runs full discovery: state PUC or PSC franchise maps, EIA Form 861 data for electric utilities, city and county billing records, and the provider’s own published service territory maps. Every identified provider gets a source URL in the deliverable.
- It researches each provider’s specific process for every applicable request sub-type: map requests (facility maps for design reference, the primary deliverable), records requests (as-builts), will-serve letters, joint trench intent, and encroachment permits. Sub-types that go to different inboxes get separate deliverables.
- It checks for roadway cut moratoriums on every street fronting or adjacent to the project, water and sewer connection moratoriums, and any known capacity constraints at the serving utility.
- It searches prior project history for existing contact names at each provider in the territory, and attempts to identify a specific human at each utility handling new-service coordination in the project area.
The output package the engineer receives includes:
- Ready-to-send email files (.eml, RFC 5322 compliant) for each provider and request sub-type, with the right inbox in the To field and the requester’s name and email address in the From field. Reply routing is set so utility responses come back into the firm for tracking.
- Printable letter drafts (.docx) for providers that accept letter submissions.
- Records request packages for providers that use web forms, portals, or mailed submissions, with step-by-step instructions and pre-filled data tables so the requester copies rather than re-types.
- A master research report with the full jurisdictional stack, provider contact cards, per-provider process summaries, moratorium and capacity flags, and a references appendix with source URLs and verification dates.
- A tariff and connection charge document (separate from the research report, for the developer or feasibility team), with provider charge data compiled in real data tables, not bullet lists.
- A coordination matrix with six tabs: provider tracking, contact log, will-serve tracker, records request tracker, moratoriums and flags, and a source audit trail. Live formulas track status and elapsed time since each outreach.
At Calichi, that three-to-four-hour task comes back in about 30 minutes of engineer time, almost all of it review rather than production. That is our own measured result.
The QC gate
The package does not reach the engineer until it passes a pre-delivery quality check. That check confirms:
- Every required file is present: the research report, the charge document, the coordination matrix, at least one letter per provider that accepts letter submissions, and at least one records-request package. Neither the letter drafts folder nor the packages folder can be empty.
- DOCX files carry the CDG logo in the header. A report with no logo in the header fails.
- The coordination matrix has at least 20 live formulas across at least six tabs. A static spreadsheet with no formulas fails.
- Every email file has complete RFC 5322 headers: Date, Message-ID, MIME-Version, Content-Type, From, To, Subject. Missing headers means the file can’t be opened correctly by the engineer’s email client.
- No placeholder text remains in any file. Project name, address, provider name, and APN must be substituted with real project data, not left as template variables.
The gate runs up to three attempts. If it fails all three, the agent flags the failure rather than delivering a broken package.
What stays human
The engineer owns the judgment calls that email can’t answer. Reading a will-serve letter when it arrives and understanding what the utility’s conditions mean for the project schedule. Deciding whether a moratorium flag changes the design approach or just needs a note on the drawings. Knowing that a particular district is slow to respond by email and needs a phone call. The relationship with the agencies is the engineer’s throughout.
Every outgoing draft carries the engineer’s name and email address in the From field. Nothing sends automatically. The engineer opens each draft, reviews it, attaches any additional materials, and sends from their own Outlook. The coordination matrix tracks what’s been sent and flags elapsed time since each outreach. The engineer drives the follow-up. The agent does the production pattern-work. The engineer does the coordination.
Every deliverable is for the engineer’s review before anything goes out. The licensed engineer owns every piece of this workflow. The agent handles the part that didn’t need them.
Where it applies
Utility research is the first step on any project with new or extended utility service: new development, infill redevelopment, public improvement projects, any site where the designer needs to know what’s in the ground before locating a new main or planning a service connection.
The nationwide angle is the key point. California’s franchise pattern doesn’t map onto Iowa or South Dakota. The utility commission is different, the state DOT encroachment process is different, the local water district structure is different. An agent that assumes California for every project is wrong the moment the project lands in Illinois or Texas. This one resolves from the address. The jurisdictional stack is assembled for the actual state and county, and the provider research runs against that state’s actual public utility commission, not a default.
We run it everywhere we practice.
What this means for your firm
I’m not going to tell you this will save your firm three hours per project. That’s what we measured at Calichi, on our projects, with our workflow. Your number depends on how you currently track provider contacts, whether you have a written process for this, and how many states your work crosses.
The honest way to find it is to map the workflow on your actual projects, not to accept a projection from someone who hasn’t looked at your specifics. That’s what the first step of how I deploy this is for. The AI Readiness Audit maps where the highest-value automation sits across your divisions, by looking at what your engineers actually do, how often, and what shape it takes, so the picture comes from your real work rather than from a generic benchmark.
I built this inside my own firm before offering it to anyone. Utility research was one of the earlier agents, because the pattern was clear: the same research on every project, going to different inboxes, in different states, with enough variation in provider process that no junior person could do it reliably without close guidance. That’s exactly the shape of work an agent handles well and an engineer shouldn’t have to own.