Most of a project controls day is spent getting ready to decide. The letter has to be found and read. The schedule has to be updated and re-run. The register has to be reconciled with the model. The clause has to be looked up. By the time the facts are in one place the meeting is over, and the decision slides to next week. The work that makes a decision possible is slow, repetitive and exact, which is to say it is the kind of work software has always been better at than people, once it can read.
It can read now. The question is how to organise it, and the answer we believe in is the oldest organisation there is: a shift of workers, each with one job, each with a tool belt, each reporting to a boss. In the current vocabulary, agents. This post is about what that shift looks like on a capital project, hour by hour, what it is allowed to do, what it is not, and what is left for the people in the morning. It is written for planners, cost engineers and contract managers who have heard the word agent a hundred times and have not yet seen one do their job.
What an agent is, in plain words
An agent is a language model with a narrow job, a set of tools it is allowed to use, and a place it must report to. That is the whole definition. The model supplies reading and writing: it can take a letter and say what it is about, take a question and say which tool answers it, take a result and put it into a sentence. The tools supply facts: a schedule engine computes float, a matcher finds the activity a letter refers to, a register lookup returns a probability. The reporting place supplies discipline: nothing the agent does is real until it has been written to the record as a proposal, and a proposal is not a change.
The narrowness is deliberate. The Reader's job is to read every document that arrives and say what it is about and what it touches. Its tools are the document store and the matcher that links a letter to a clause, an activity, a cost line. It cannot change a date. The Scheduler's job is to re-run the critical path when anything moves and say what changed. Its tool is the schedule engine. It cannot accept a progress update. The Risk agent proposes register entries. The Contracts agent watches deadlines and drafts notices. The Site agent matches evidence from the field to the model. Five jobs, five tool belts, no authority. A general-purpose assistant that can do all of this at once is a worse design, not a better one, because a worker who can do anything is a worker nobody can audit.
| Agent | Reads | Tools it may call | May propose | May never |
|---|---|---|---|---|
| Reader | letters, emails, meeting transcripts, reports | document store, matcher | a link from a document to an activity, clause or cost line | change any date, quantity or status |
| Scheduler | the live schedule and every revision | critical path engine, float calculator, revision diff | a scenario, a list of what changed and why | write to the live schedule or a baseline |
| Risk | the register, its history, the Reader's links | register lookup, schedule risk simulation | a new or changed risk with its evidence | accept or close a risk |
| Contracts | the contract, its clauses and dates | clause index, deadline calendar, notice templates | a draft notice, a deadline warning | send anything to anyone |
| Site | daily reports, photographs, the IFC model | object matcher, progress rules | a progress update, or a held update with a question | mark work complete on the record |
Notice what is absent from the table. No agent negotiates. No agent attends a meeting. No agent decides. The shift exists to make the morning shorter, not to replace the people who own the morning.
One night at Northgate Terminal, hour by hour
Northgate Terminal is a fictional EPC project: four storage tanks and a marine berth, a schedule of about twelve hundred activities at revision 13, a contract with delay damages, and a mechanical completion milestone called M4 that the client cares about more than any other date. Here is one night on it, as the record would keep it.
19:40. A letter from Valvex, the valve supplier, lands in the procurement mailbox. The Reader opens it within the minute. It is a delivery notice: the V-12 gate valves will ship in week 41, not week 39. The Reader files the letter as SUP-0877, finds the purchase order it refers to, finds the clause on delivery in the supply contract, and finds the activity that installs those valves on the hook-up to tank T-102. It writes three links and one sentence: “SUP-0877 moves the V-12 delivery by two weeks and concerns A-1205, clause 14.2 and milestone M4.” The sentence is the model's. The three links are the matcher's, each with a confidence score, and the one that scored lowest, the activity, is flagged for a person to confirm.
23:10. The Scheduler wakes because something it watches has changed: a document is now linked to an activity with a new date. It copies the live schedule into a scenario, moves the delivery constraint on A-1205 by ten working days, and runs the critical path. The engine returns what engines return: the hook-up had eight days of float; it now has minus six; the path through the valves is now critical to M4; M4's early finish moves from 9 November to 23 November. The Scheduler writes the diff, every activity whose dates moved, and a sentence: “If the valves arrive in week 41, M4 slips fourteen days unless the hook-up sequence changes.” It does not touch the live schedule. Revision 13 is exactly what it was at 19:00.
23:12. The Risk agent reads the Scheduler's note and the Reader's links. It looks up the register: there is no entry for late valves on this package. It looks at the register's history: Valvex has slipped on two previous orders on this project, both by one to three weeks. It drafts a register entry, R-0231, with a probability taken from that history rather than from a guess, a schedule impact taken from the Scheduler's scenario rather than from a rule of thumb, and an owner, M. Chen, taken from the package's ownership table. It marks the entry as proposed. Nothing in the register has changed.
02:30. The Contracts agent runs its nightly deadline sweep. Clause 8.4 of the main contract requires the contractor to notify the client within fourteen days of becoming aware of an event that may delay a milestone. The Reader's link from SUP-0877 to M4 means the contractor became aware at 19:40 tonight. The agent computes the deadline, 6 November, puts it on the deadline calendar, and drafts a notice from the template: the event, the affected milestone, the clause, the likely effect, with every figure pulled from the Scheduler's scenario. The draft is dated, addressed and unsent. It will stay unsent until a person decides to send it, or decides not to.
05:50. The Site agent processes the day's evidence from the field: 214 photographs and two daily reports. It matches each photograph to the model by location and tag, and each report line to an activity. Two pours reported as complete yesterday on the T-103 foundation are not visible in any photograph of that area, and the photographs that do exist show formwork still in place. The agent does not reject the report. It holds the two lines with a question for the section engineer and lets the other forty-one lines through as proposed updates.
07:00. The brief. Three proposals wait for a person. A risk to accept or reject, addressed to M. Chen. A notice to send or hold, addressed to the contract manager, with a deadline nine days out. Two progress claims to confirm or correct, addressed to the section engineer. The schedule shows the valve slip as a scenario beside revision 13, not as the plan. Every item carries its sources. The planner's morning starts at the decision, not three hours before it.
The boss is the record, and the record has rules
What keeps a shift of agents from becoming a shift of confident liars is the same discipline that governs how Verian answers a question in a review. It can be written as five rules, and every one of them is enforced by the platform rather than by the model's good manners.
- Figures by tools, sentences by the model. Every number an agent reports was computed by an engine from the record: the float by the critical path engine, the probability by the register lookup, the deadline by the calendar. The model never produces a figure; it only puts a computed figure into a sentence, and the sentence carries the figure's source.
- Proposals, not actions. An agent writes to one place: the proposal queue. A proposal becomes real only when a person with the right authority approves it, and the approval is logged with a name, a time and the proposal as it stood when approved.
- With the access of the person it reports to. The brief that reaches the section engineer contains the section engineer's items. The one that reaches the project director contains the director's. No agent can show anyone more than that person may see.
- Say so when you cannot. An agent that cannot match a letter to an activity says that the match failed, and the item goes to a person as a question. It does not pick the likeliest activity and move on.
- Sandboxes and locks. Every scenario is a copy. Baselines are locked. The live schedule changes only when a person promotes a scenario, and the promotion is itself a logged approval.
Two of these rules deserve a closer look, because they are where other designs go wrong.
The first is the figure rule. A language model asked for the float on an activity will give a number. It will give one whether or not it has read the schedule, because producing plausible text is what it is for. On a night shift with nobody watching, that habit is fatal. So the platform does not let the model answer a figure question. It lets the model decide which tool to call, calls the tool, and lets the model write the result into a sentence. If the tool fails, the sentence says the tool failed. The planner reading the brief at 07:00 can click any number and see the engine run that produced it.
The second is the proposal rule. It is tempting to let a well-tested agent make small changes directly: accept a progress update that matches the photographs, close a risk whose trigger date has passed. Each of those is reasonable on its own. Together they are a project that changes overnight in ways nobody signed for, and the first time one of them is wrong, every other change loses its credibility too. A queue of proposals with a name on each approval is slower by one click per item, and it is the difference between a record people trust and a record people check.
The machine works the night shift. The person still signs the morning.
How it fails, and what catches it
Any design that claims to be safe should say how it breaks. Here are the four failures we plan for.
The wrong link. The Reader ties SUP-0877 to the wrong activity: a different valve package on a different tank. The Scheduler then runs a scenario that is true for the wrong path. What catches it: the matcher's confidence score was low, so the link was flagged, and the brief shows the flagged link beside the scenario. The planner sees that the scenario is built on a questioned link before reading its result. The scenario is a copy, so nothing on the live schedule depended on it.
The stale source. The Risk agent takes its probability from a register history that was never cleaned, and two of the three past slips were data-entry duplicates. What catches it: the proposal shows its evidence, three past orders with dates and references, and M. Chen, who owns the package, recognises the duplicates. The risk is accepted with a corrected probability, and the correction is logged. The register history is now better than it was.
The over-eager notice. The Contracts agent drafts a delay notice for an event that the project director intends to absorb without claiming. What catches it: the draft was never sent. The director reads it in the brief, holds it, and records why. The deadline stays on the calendar in case the position changes before 6 November.
The missing photograph. The Site agent holds two pours because no photograph shows them, when in fact the photographs were taken but failed to upload. What catches it: a held update is a question, not a rejection. The section engineer answers it with the photographs, the pours are confirmed, and the hold is cleared. Had the agent been allowed to reject the claim, the daily report would have been wrong for a day and nobody would have known why.
The pattern is the same in all four. The agent can be wrong. The design makes being wrong cheap, visible and reversible, by making every output a proposal with its evidence attached and by leaving the final step to the person who will answer for it.
What changes for each person in the morning
The planner. L. Ferreira used to open the day by chasing the delivery letter, re-keying its date, re-running the schedule, and writing a note to the risk manager. Now the scenario is waiting, with the path lit and the diff listed. The day is spent on the question only a planner can answer: is there a hook-up sequence that protects M4 without a second crew, and is it worth the overtime if not. The scenario machinery that ran overnight is the same machinery used to try three answers before lunch.
The cost engineer. The valve slip has a cost: the crew that stands down, the crane that stays, the damages that start if M4 passes. Before, those numbers were assembled by hand a week after the letter. Now the Scheduler's scenario carries its resource profile, and the forecast for the affected cost lines is already recomputed as a scenario beside the current forecast. The cost engineer checks the assumptions, not the arithmetic.
The contract manager. The clause 8.4 deadline was the kind of thing that was missed: not because anyone was careless, but because becoming aware of a delay at 19:40 on a Tuesday does not announce itself as a contractual event. Now the deadline is on the calendar the moment the letter is linked, with a draft ready. The contract manager's job becomes the judgement, whether and how to notify, rather than the discovery.
The project director. S. Okafor opens one brief instead of six emails. The brief says what happened, what it touches, what is proposed and who it is waiting for. The review that afternoon is shorter, because the question that used to end it with an action item, what does the valve slip do to M4, has an answer with its sources before the meeting starts.
- Reader: every document read the hour it arrives, linked to what it touches, with its weakest link flagged.
- Scheduler: the critical path re-run on every change, as a scenario, with the difference listed.
- Risk: new entries proposed from the evidence, tied to activities and clauses, owner assigned.
- Contracts: deadlines computed from the moment of awareness, notices drafted in time, never sent on their own.
- Site: progress from photographs and reports matched to the model, held with a question when it does not add up.
What you can do on Monday
You do not need agents to start thinking this way. Three things a controls team can do with what it already has.
- Write down who may change what. For each of schedule, register, contract calendar and progress, name the one role that may change it and the roles that may only propose. If that list does not exist, no automation is safe, and most manual processes are not either.
- Attach sources to figures in the weekly report. Every date and every number gets the revision, the register entry or the letter it came from. It is tedious the first week and it changes the tone of every review after that.
- Keep a proposal queue, even on paper. A list of things someone has suggested and nobody has approved, with the evidence beside each. It is the morning brief before there is anyone to write it overnight.
Where this stands
Verian is a project controls service run on Verian's own AI platform. Today, Verian's team keeps a client's project record current on that platform: documents are read and linked the day they arrive, risks are proposed from the evidence, schedules are re-run and recoveries tried as scenarios, notices are drafted against the contract's deadlines, and progress claims that do not add up are held with a question. The client's people log in, see all of it live with their own access, and make the decisions. Verian's team does not sit in the client's meetings and does not negotiate on the client's behalf.
Organising those abilities as a coordinated night shift with one morning brief per person, the five lanes above running unattended and meeting at 07:00, is the direction we are building in. The pieces are the ones already on the platform; the work is in the coordination and in the rules that let it run without anyone watching. This is the first of two posts on what that future looks like. The second is about what happens when the project can also rehearse every decision a thousand times before breakfast.