The platforms are all shipping the same thing, and it is not the features
Every major construction platform has shipped this year, and the release notes read the way release notes always do: a better editor here, a sync indicator there. Underneath them is a change that matters considerably more, and almost nobody is selling it as a headline. The platforms are opening their doors to software that acts, rather than software that reads.
What actually shipped?
A fair amount, across four platforms serving quite different readers.
| Platform | Recent changes | Who it is really for |
|---|---|---|
| Procore | Submittals sync across collaborating companies, a rebuilt Emails editor, an iOS inspections sync header, adoption reporting, and AI resource recommendations on the planning Gantt from 15 September | The main contractor's project team |
| Autodesk Construction Cloud | Autodesk Assistant, automated drawing extraction, a reworked Handover package, closed RFIs shared across accounts, and Secure Service Accounts governing third-party app access | The design and information managers |
| Trimble Viewpoint Field View | A 3D model viewer that lets forms, checklists and snags be pinned to a location in the model, plus bulk user administration in the R2 release | The people walking the job |
| Simpro | Fast Cash, an accounts receivable agent that decides when to chase, a Defect Management module, and appointment-level notifications | The subcontractor's office |
Read the four together and the pattern is obvious. Each is putting AI inside the workflow it already owns, and each is getting better at the slice of the project it can see. None of them is getting better at the seam between them, because the seam is not theirs.
The individual features are genuinely good, and the Procore product releases, Trimble's Field View pages and Autodesk's September construction releases are worth ten minutes each if you pay for them. Do not mistake that for the important news.
Why does an API opening to agents matter more than any feature?
Because it changes what you can build on top of something you already own.
In March 2026 Procore announced a class of APIs built for AI and agent use: deep search across PDFs, images and video, and, in their own words, agents that take action. Pricing is consumption based. At the same time the Marketplace moved to a reviewed model, where new partners go through a check on strategic fit, technical feasibility and security, while custom integrations outside the Marketplace stay open to customers.
Take the two halves together and the message is not subtle. The platform is prepared to let software act inside it, and it wants to know who is doing that and on what terms. That is the right instinct, and it is the same instinct a main contractor should have about anything touching a live project.
What it means practically is that the interesting work moved. Two years ago, getting more out of Procore meant waiting for Procore to build it. Today it means asking what you would do with a door into your own data, and the answer is usually not a new platform.
What is an API, actually?
Worth saying plainly, because it is the word doing most of the work in this article.
An API is a door in a piece of software that other software is allowed to use. Your quantity surveyor opens Procore and reads a register on screen. A program asks the same system for the same register through its public API and gets it back as data, with no person, no screen and no copying out. Same information, same permissions, different consumer.
That is the whole idea. Everything else is detail: the door is guarded, it checks who you are, it limits how often you can knock, and it is documented so somebody can build against it without guessing. Procore, Autodesk and the rest all have one. It is why 500 integrations exist without Procore writing them.
The reason it matters to a contractor rather than a developer is that it changes the shape of the buy decision. If the systems you pay for have doors, the question stops being which platform does everything, and becomes what small thing would join the ones I have. We wrote the longer version of that in can you tailor-make Procore or Asite, and the build-or-buy framing in one platform or build your own.
So what do none of them cover?
Three things, and they are the same three on almost every project we look at.
The conversation the decision happened in. An instruction to proceed, a sequence change agreed on a Friday, an approval given against a photograph of a marked-up drawing. That exchange is binding whether or not anybody files it, and it is the most contemporaneous account of the job that exists. It lives on personal phones, and no platform on the list above has any claim on it.
The people without a seat. Every one of these systems is licensed per user, and in practice licensed to the main contractor's own staff. The groundworks foreman, the cladding subcontractor two tiers down, the supplier's driver and the client's facilities manager are central to the work and peripheral to the licence count. Per-seat pricing is not incidental here. It is the mechanism that guarantees the most operationally involved people sit outside the system of record.
The join. Information starts life in one system and is needed in three. The drawing revision lives with the design team, the instruction lives in the contractor's project tool, the labour that carried it out lives in the subcontractor's job system, and the evidence that it was done lives in a form on somebody's phone. Nobody is paid to make those four agree.
Agentic APIs make the first two worse before they make them better, and that is not a criticism of them. An agent that can search everything in Procore is genuinely useful and will be confidently wrong about anything that never reached Procore. The quality of the answer is set by the quality of the record, and this is exactly the ground covered in MCP and the connected construction office.
Where does AI Metric come in?
We are not trying to sell you a fifth platform. We work on the seam.
In practice that is three kinds of job. Joining systems you already pay for, so the information stops being retyped, which is the work described in choosing between n8n, Make, Zapier or custom. Capturing the traffic that never reaches any of them, so the decision taken in a chat lands in a dated record with the sender, the time and the original photograph attached. And deciding, honestly, which of those is worth doing on your projects, because sometimes the answer is that your platform already does it and nobody has turned it on.
The reason we build this way is that it survives. A platform migration is a two-year project and a thin layer over open APIs is not. The record you own outlasts whichever system you were on when it was created, which is the only property that matters when somebody asks you to prove what happened in 2024.
What are people asking us?
What is an API, in plain terms?
A door in a piece of software that another piece of software is allowed to use. A person opens Procore and reads a drawing register on screen. A program asks Procore's API for the same register and gets it back as data, without a person, a screen or any copying out. That is all an API is: the same information your staff already have access to, made available to something other than a pair of eyes. It is how the platforms you pay for can be made to talk to each other.
Do we need a bespoke platform?
Almost never, and it is usually the most expensive answer to the wrong question. You already pay for systems that do the heavy lifting. What is missing is rarely another platform; it is the joins between the ones you have, and the work that falls in the gaps between them. Building a bespoke replacement means rebuilding scheduling, documents and cost control that somebody else maintains for you. Building a thin layer that joins them is weeks, not years.
What has actually changed this year?
The platforms began opening to software that acts, not just software that reads. Procore announced a class of APIs built for AI and agent use in March 2026, including deep search across drawings, photographs and video, and agents that take action, with the Marketplace moving to a reviewed model at the same time. That is a different proposition from an integration that copies a field from one system to another.
Is an integration the same as a record?
No, and conflating the two is where projects come unstuck. An integration moves data between systems so people do not retype it. A record is a dated, attributed account of what was decided and by whom, which survives the software, the contract and the people. Procore's APIs power over 500 integrations, and none of that makes the decision taken in a group chat at seven in the morning part of any system at all.
Which platform should a UK contractor be on?
The one your clients and supply chain already use, in most cases, because the cost of being the odd one out is higher than any feature difference. The more useful question is what you do about the work that sits outside whichever you pick: the subcontractors without a seat, the decisions taken on the phone, and the information that has to be assembled at handover from four places at once.
Where should we start if we pay for several of these?
Write down the three things your team retypes most often, and where each piece of information starts life. That list is usually short, boring and expensive, and it is the shape of the integration work worth doing. It also tells you the one thing no platform on your list is capturing, which is normally where the real money is.
What should you do before the next release cycle?
The platforms will ship again in ninety days and the feature lists will look much the same. The question worth answering in the meantime is not which of them is best. It is what your business does about the work that sits between them.
If you pay for two or more of these and your people still retype things between them, get in touch and we will look at the joins properly. That is most of what our consultancy work is.