A document agent for a drilling firm: 168 regulatory documents and a second contract

This is the least glamorous system we run, and the one we point to most often. It generates regulatory paperwork for boreholes. As of August 2026 it has produced 168 documents and holds 349 boreholes in its database, and the client has since commissioned a second system on the same server. We do not name the firm, because the consent to do so is still pending, so what follows is described as far as they let us.

The job by hand

A hydrogeology engineering firm drills and documents wells. Every well project ends in a regulatory document set: the same documents every time, in the format the regulator expects, filled with this project's site data. Before the system, an engineer produced that set by opening the last similar project, changing the site data, checking that nothing from the previous project had survived the copy, and repeating that for each document in the set. Hours per project, done by a person hired to be an engineer.

Nobody at the firm thought of this as a problem to solve. It was how the documents got made. It only became a project because somebody added up the hours.

What we built

An authenticated web application the engineers use directly. They submit the project data, and the system drafts the full document set in the firm's own templates, in the firm's own format. Generation takes minutes rather than seconds, so it runs as a background job with a status the engineer can poll, rather than a page that hangs. The engineer then reads the output and corrects it where the site needs judgement, which is the part of the job that should have had their attention all along.

Under the hood it is Python, a language model for the drafting, and LibreOffice on the server for producing files that open in the client's Word exactly like their originals. It is deployed on the client's own server, with one-command deploy scripts and monitoring, and the repository is theirs. If we vanished tomorrow, any Python developer could pick it up from the repository and the scripts in a morning. That is the standard our handover checklist aims at, and on this build it was cheap to reach.

The part that took the time

The language model was the quick bit. Given the structure of a document and the site data, drafting the prose is the kind of thing these models do well, and getting acceptable drafts took days.

The part that dragged on was the file. The regulator does not read a web page. They receive a document, and the firm's reviewers open it in Word, and it has to look like theirs: their headers, their tables, their numbering, their fonts, in the order the regulator expects. A draft that reads correctly and looks wrong is a draft the engineer has to reformat by hand, which puts the copy-paste job back. So a good deal of the work was rendering on the server and comparing the output against the firm's originals until nobody at the firm could tell which was which.

Nobody at the client cares that there is a model in there. They care that the document looks like theirs and that they did not have to type it. That is true of most of the work we do, and it is the reason we scope a build by the output a person will hold, rather than by the model that produces it.

What it does in numbers

Measure	As of August 2026
Regulatory documents generated	168
Boreholes on file in the client database	349
Engineer time per document set	Hours of drafting, now minutes of review
Incidents that woke anybody up	None of them were the model. See below.

We keep the numbers conservative and we do not claim an hours-saved figure we cannot show the working for. The client knows their own before and after. The one figure we would defend anywhere is the second contract.

Why a second contract came

A few months after the document system went live, the same firm asked for something unrelated to documents. Their warehouse stock lived in an ERP nobody wanted to query, so finding out what was in the warehouse meant asking the one person who knew, and waiting if that person was on site. We built a second agent that answers stock questions in plain language from the ERP data, behind its own access-controlled portal, running on the same server beside the first system.

The second build was scoped in a fraction of the time, because the server, the deploy scripts, the access model and the working relationship already existed. The second system for a client is always the cheap one, which is an argument for making the first one solid rather than impressive. It is also the reason we track repeat work as the result that matters, ahead of any number we could put on a slide.

What broke, and what did not

Almost every problem on this system has been a point failure of the ordinary kind: a credential, a dependency, an input that arrived in a shape nobody had seen. None of it has been the model, which matches what we see across the six systems we run and is the pattern behind why AI automations die in production. The system has monitoring that reaches a person, a deploy that is one line and a rollback that is the same line pointed at the previous version, and that is most of why it has stayed boring.

If you run an engineering firm

The shape to look for is a document set that is the same every time and is currently assembled by an expert. Regulatory filings, inspection reports, method statements, compliance packs. If a qualified person spends hours per job on a document whose structure never changes, that is the job. What it costs to have built is on the pricing page, and the document work we quote as a single build is described at what we automate. If you want the same thing done for your own document set, describe it in two paragraphs and we will tell you whether it is one build or two.