We've opened a public demo stand at pto.eirlab.ru. It's an AI agent holding a post in the company — as-built documentation engineer: it works through construction documents, checks completeness, prepares certificates and asks questions wherever the data falls short. The agent isn't experimental — it has been handed over to our client and runs on real sites. The stand carries a simplified version of it, plus a recording of a real working day you can open without signing up.
What a post means for an AI agent
We build employee-agents, not chatbots. The difference is simple: a chatbot answers questions, while an employee runs a stretch of work — it has a post, a zone of responsibility, a boundary it does not cross, and a human who reviews its output and answers for it. We laid that frame out in detail in a separate article — «Seeing an AI Agent as an Employee».
The trouble with a frame like that is it reads convincingly but can’t be verified on the page. So we opened the stand: on it you can see how the structure holds up on a real task — where the agent acts on its own, where it stops, and why it doesn’t fill blanks with guesses.
The stand: pto.eirlab.ru — a finished example of the agent's work is open, no sign-in needed.
Access: to try it yourself, there's a request form on the stand.
Why we picked this particular job for an agent
As-built documentation is the paperwork a contractor uses to prove the work was done and checked: hidden-works inspection certificates, registers, quality documents for materials. Once a cable run is sealed inside a wall, nobody can look at it again — all that remains is the certificate.
We chose the task not on “where would AI be interesting to apply”, but against four criteria. They double as a checklist for any company wondering where to put an agent.
| Criterion | Why it matters |
|---|---|
| The flow repeats | Setting the agent up pays off, rather than a one-off run |
| The form is rigid | There’s an unambiguous standard of “correct”; the output is checkable |
| Errors are expensive and visible | There’s a reason to invest, and mistakes get caught rather than missed |
| Human review is fast | The engineer verifies the output in minutes instead of redoing it |
As-built documentation meets all four. The same forms, month after month. The certificate template is approved; “roughly like this” doesn’t pass. The construction-control inspector sends an incomplete package back for rework — the site stalls, payment slips. And an engineer can verify a finished certificate quickly, provided it’s clear where every fact came from.
If only two of the four hold, it’s too early for an agent. That’s probably the single most practical takeaway we can pass on.
What the agent does, and what it never does
A post is defined less by what the employee can do than by where their boundary runs. For our agent it’s set explicitly.
| Does on its own | Refers to a human | Never does |
|---|---|---|
| Reads incoming documents and identifies their type | Anything absent from the documents: party details, work dates, certificate numbers | Doesn’t sign the certificate |
| Checks the set against the volume contents and finds discrepancies | Disputed and ambiguous situations | Doesn’t invent missing data |
| Pulls out the facts the form needs, tagged with their source | The finished draft — for review and approval | Doesn’t pass the unverified off as confirmed |
| Assembles the certificate and issues the finished document |
The right-hand column matters more than the left. An agent that can fill in forms is a feature. An agent that knows what it has no right to do is a post.
What it looks like on a real run
The stand carries a recording of actual work, not a staged demo. The plot in brief.
The engineer sets a task: work through the document set for the video surveillance system. The agent reads the filed documents and starts by comparing them against the volume contents: the contents list six documents, and not all of them are in the folder — four are missing. The agent names which ones and asks whether they should be filed.
The engineer replies: the missing parts will come later, carry on with what’s there; the certificate number is such-and-such, the date such-and-such; the remaining details aren’t confirmed yet.
Then comes the episode the stand is worth opening for. The engineer gave the certificate number and date in passing, while answering a question about something else entirely. Formally the data has been received; it could be quietly dropped into the form and nobody would notice. The agent doesn’t do that: it distinguishes “the human answered my question” from “the human mentioned something along the way”. It does carry the values into the draft, but flags them as unconfirmed and asks for direct confirmation.
That is the boundary in action. Not a rule in a specification, but behaviour you can watch in the correspondence.
The working day in numbers. The certificate form has seventeen fields: the agent filled five from the documents, took two from the engineer’s words and flagged them as awaiting confirmation, and left ten empty. For every empty field it formulated a question and explained why it can’t close it alone — nine questions in total, each tied to its own clause of the form.
Ten blanks out of seventeen looks like a weak result until you consider the alternative. A model that writes a plausible registration number in place of a missing one is more dangerous than an empty field: the engineer sees an empty field immediately, a plausible lie not necessarily. And a list of nine questions is a ready checklist: exactly what has to be produced for the certificate to close. Previously the engineer compiled that list by hand, cross-checking the set against the form.
How the demo stand differs from the working version
The stand is weaker than the agent running at the client’s. We say so plainly, so nobody builds expectations on the demo.
| Demo stand | Working version | |
|---|---|---|
| Model | Text-only, no multimodality | Frontier models with image handling |
| Documents | Only what reads as text | Scans, stamps, signatures, drawings |
| Tools | One scenario end to end | Full set of tools and access |
| Data | Anonymised: organisations, object and address changed | The client’s real data |
| Limits | Caps on volume and running time | Production load |
The multimodality row is the substantial one. As-built documentation consists of scans where the picture is what matters: a stamp, a signature, a drawing. The demo stand doesn’t see them; it works only with extracted text. The working agent does see them.
What is genuine on the stand is the agent’s working logic: how it reasons, what it treats as grounding, where it stops and what questions it asks. Which is exactly what the stand is open for. It’s also the answer to why we’d put a deliberately weaker version in the shop window: if the structure works, it shows even on a simple model. If an agent only holds together on the strongest model available, it isn’t a post — it’s a trick.
What to do with this
We’re not showing a model — anyone can spin up a model today. We’re showing a way to put AI to work so that the output can actually be accepted.
The difference between “AI that can handle documents” and a working agent lies in boring things: a narrow zone of responsibility, a per-project memory, the right to ask instead of guess, an obligation to name the source of every fact, and a living human who reviews and signs. Those are what decide whether the tool ends up in real work or stays a nice video.
Run your own flow past the four criteria in the table above. If it meets all of them, you can create the same kind of post for it, and we know how. If it doesn’t, better to admit that before a rollout than after.
And to see what it looks like up close, open the stand.