One platform. Many apps.Built for Agentic AI.
How the 3PM platform is built: independent construction apps, each with its own database, sharing a common set of entities through scoped access rather than replication, with a governed interface for AI agents.
Agentic AI, built for construction
From the apps on site to the models that reason about the work. One connected platform.
Four layers, one platform
3PM brings agentic AI to construction through four connected layers: the apps your teams use, a shared source of truth, the AI models themselves, and one governed way in.
Application layer
Independent construction apps, each with its own database and MCP connector.
Shared data layer
The 3PM Lattice: one authoritative view of clients, projects and sites, referenced not copied.
AI Agent Layer
Frontier and specialised LLMs, plus 3PM agent programs (IoT Hub, Extract, Forms, Flow) that connect your telematics, machines and sensors and feed the data layer.
3PM Access Layer
One governed way in. Every request authenticated, scoped, routed and audited.
Why 3PM has Agentic AI in Construction sorted.
We solve the three hardest problems in construction so AI agents can act with context, security and the right access, across every project, every role, every time.
1. Data across the model
One connected construction graph
3PM unifies data from every party and app into one lattice, so AI agents see the full picture, not fragments.
2. Security to act on
Trust, verified and enforced
Every agent request is authenticated, scope-checked and policy-enforced, so AI can act, safely.
3. Roles & Permissions
Access that matches how construction works
Each role only sees its section of the project, with the right tools and data to get the job done.
Agentic AI that can act.
Context it can trust. Access it can use. Outcomes you can rely on.
The platform, layer by layer
One identity across many apps, each with its own database. Every app connects the same way: it authenticates through 3PM Auth, then uses its own MCP connector to publish the shared records it owns to the Lattice and subscribe to changes from the others. Data is shared through scopes, never replicated.
Select any component to see its role and its access boundaries.
Identity
One global ID for every client, project, site and worker, resolving to the same entity in every app.
Relationships
Which worker is assigned to which site, and which invoice belongs to which project, held as traversable edges.
Shared fields
A small set of stable fields required by more than one app, such as a name, a status or an address.
Governance
Field ownership, change history and access rights, recorded as part of the graph rather than per app.
Agentic AI model
The loop an agent runs, every time
Every turn of the loop is authenticated and scoped. The agent never sees more than the person or system that invoked it.
Frontier & specialised models
Select a model to see where 3PM uses it. Model routing, fallback, guardrails, and cost & performance optimisation.
Headless agents whose users are other agents. They work the other way up the stack, feeding the shared data layer with records the rest of the platform can reason about.
Every request passes the same controls
Exposed as three channels
Who connects
Partners and AI agents connect through these channels, never around them.
The result is that each app can be developed and deployed on its own release cycle while sharing a consistent view of core data across the platform.
The agents that work for the data, not the user
Inside the AI layer, 3PM runs its own agent programs. They do not answer questions from people. Their job is to take what construction actually produces, telemetry from EROAD, Teletrac Navman, blackhawk.io and the machines themselves, the documents, and the answers that exist only on site, and turn all of it into records the rest of the platform can reason about.
Where AI in construction actually fails
Not at the model. At the last mile of data. Telematics and sensor providers each publish their own schema, units and identifiers. Half the record of a project exists only as documents. The rest exists only in someone's head until somebody is asked. Point a frontier model at that and it produces confident answers from partial evidence, which is worse than no answer at all.
So we built the last mile as agents, not scripts
IoT Hub, Extract, Forms and Flow are 3PM's own agent programs. They sit in the AI layer and work for the data layer. They are headless: their users are other agents, not people. They reason about ambiguous input rather than failing on it, they call each other over agent to agent, they expose their capabilities as MCP tools, and everything they write lands on the Lattice as a governed, attributable record.
Four programs, one job: keep the graph true
Worked example · select a program
Where was the plant, what did it do, and against which job?
Takes inTelematics providers, machine OEM feeds, GNSS and machine control, tool tags, sensors and site gateways
Every provider, on its own terms
IoT Hub connects to each telematics and sensor provider the way that provider expects: its API, its webhook, its message format, its update frequency. Adding a new provider is a connector, not a platform change.
- Vendor APIs, webhooks and streaming feeds
- Backfill and replay when a feed drops
- Raw payloads retained for provenance
Three providers, three shapes, same excavator
eroad {"devId":"8827341","ts":1721790041,"lat":-36.848,"lon":174.763,"spd":0,"eng_hr":4412.6}teletrac <Unit Serial="EX320-77812" LocalTime="09:14:01 NZST" Odo="18422 mi" Fuel="7.2 gal/h"/>
blackhawk node=BR-114,temp=13.4,rh=71,batt=88,rssi=-97,seq=41182
Writes to the Lattice
Callable by other agents as MCP tools
Select a stage to step through it. Raw feeds and original documents stay in the systems that produced them. Only the resolved meaning reaches the Lattice, with the provenance of every value retained.
What is already connected
Your telematics, your machines, your sensors. One graph.
A construction business does not get to choose one telematics provider. It inherits whatever was fitted to the trucks, whatever the machine came with from the factory, whatever the hire company put on the excavator, and whatever the site gateway is talking to this month. IoT Hub connects to each of them and hands the rest of the platform one answer.
Select any provider to see what 3PM takes from it. Logos are shown to identify the systems 3PM connects to. All marks belong to their owners.
The problem, in one machine
Four providers describe the same excavator four different ways
Independent of who made it
The connector is per provider. The meaning is per device.
Whatever brand is on the box, a tracker answers where, a controller answers how hard it worked, and a sensor answers what the conditions were. IoT Hub publishes the answer, not the device.
Not on the list? A new provider is a connector, not a platform change. If it has an API, a webhook, an MQTT topic or a nightly file, IoT Hub can take it, and nothing above the AI layer needs to know it was added.
MCP is how an agent reaches a tool
Each program publishes its capabilities as MCP tools, so any agent, ours or yours, can call them through the Access Layer with its own scopes applied. An agent asking for plant utilisation never needs to know which telematics provider the data came from.
Agent to agent is how they reach each other
The programs delegate between themselves. Flow asks IoT Hub to confirm a plant window, Extract asks Forms to collect the signature a docket is missing, and each returns a structured result rather than prose. Every hop is authenticated, scoped and logged, so a chain of agents is as auditable as a single request.
Competitors add an assistant on top of their data. 3PM runs agents underneath it.
By the time a user-facing agent is asked a question, IoT Hub, Extract, Forms and Flow have already done the work that makes the answer possible.
3PM Ecosystem Technology White Paper
PDF · 15 sections · about 35 minutes · version 1.0
The long-form version of this page. Architecture and the reasoning behind it, the Lattice entity set and write rules, the scope model, the MCP request lifecycle, the four agent programs and their tool surface, a request traced end to end, and a section on where the architecture is weaker.
- Why integration by copying and one big schema both fail
- The Lattice: entities, identity resolution, provenance, write rules
- 3PM Auth: field-level scope, workspaces, agent identity
- The access layer and the MCP request lifecycle
- IoT Hub, Extract, Forms and Flow, and agent to agent
- Limits and honest failure modes
Evaluate it against your requirements
Review the applications, or arrange a technical discussion covering integration, data residency and the agent permission model.