Skip to main content
Gezora.ai

See the delay before it reaches the next contractor

A six layer agent platform that reads the daily update every project manager already writes, holds one live model of your whole program, and forecasts which other projects a slip will reach while there is still time to act.

Inside the workflow

From one daily update to a decision on the executive desk

Step 1: A project manager sends the daily update

What actually happened on site today?

Update intake

Layer one meets the project manager on the channel they already use

  1. Project managerTrench work slipped. We finish ten days later than the plan.
  2. Intake agentWhich approval is holding it, the road closure or the tie in permit?
  3. Project managerBoth are open. The chambers are the binding one.
  4. Intake agentLogged against the trunk sewer task, with your wording kept beside it.

Daily update schema

The small set of fields every channel has to fill

Progress
Where the work stands against the plan
Blockers
What is stopping it, in the words used on site
Approvals
Which permits are open, and which one binds
Task reference
Mapped to a real task, not free text
Raw submission
Retained beside the structured extraction

Step 2: The update is checked against the baseline

Is this project slipping, or is it noise?

Reported against baseline

What layer two settles before anything downstream runs

CriteriaApproved baselineReported today
Finish dateThe date signed offTen days later
ProgressOn the planned curveBehind it
Open approvalsNone assumedTwo open, one binding
Project statusOn programSlipping

Single project state

Settled at project level before the graph is touched

  1. Baseline loaded, done
  2. Update received, done
  3. Reconciled, in progress
  4. Variance flagged, waiting

Step 3: The change is written to the master graph

Where does this update actually live?

What the write touches

The graph is the substrate every layer reads, and it is not a language model

  • Task record

    The real finish date set against the planned one

    Updated
  • Dependency edges

    Every declared link out of the changed task

    Walked
  • Update log

    The raw wording and the extraction, both kept

    Stored
  • Graph version

    Stamped so the change can be replayed later

    Versioned

A write only lands when

The four conditions that keep the model honest

  • The task the update names already exists
  • The dependency was declared, not inferred
  • The raw submission is stored beside the extraction
  • The version is stamped before the next layer reads it

Step 4: The impact engine walks the dependency chain

Whose work does this reach?

Forward pass

A deterministic critical path walk outward from the changed task

  1. first hop

    Sewer work to road paving, done

    Float absorbs part of the slip, but not all of it

  2. second hop

    Paving to the next paving task, in progress

    No float left, so the delay passes straight through

  3. third hop

    Paving to the corridor handover, waiting

    An approved milestone is now inside the chain

  4. boundary

    The chain leaves the project, waiting

    Work owned by other contractors is now affected

Reach of one slip

Counted by the walk, not estimated

Projects the chain reaches
FourProjects the chain reaches
Approved milestone in its path
OneApproved milestone in its path
Float left on the binding hop
NoneFloat left on the binding hop

Step 5: Materiality decides who hears about it

Does this belong on the executive desk or in the project view?

Materiality score

Float, criticality, breadth, and cost, weighed against a gate your office sets

  • Float left on the chain

    92 of 100

    Nothing remains to absorb the slip

  • Criticality of what it reaches

    84 of 100

    An approved milestone sits downstream

  • Breadth across the program

    78 of 100

    Four projects, three separate organizations

  • Cost exposed by the delay

    61 of 100

    Day rate on the work the chain blocks

Who owns the gate

The engine scores, your controller decides what clears it

4/5
  • Scored inputs4
  • Threshold you set1

Step 6: A forecast is attached before anyone is told

How long is this delay likely to run?

How the forecast is built

Layer five conditions the slip on what has happened before

  • Pattern match

    Comparable cases already seen on the program

    Automated
  • Language signals

    Wording that has run ahead of slippage before

    Automated
  • Confidence and basis

    Reported with the number, never after it

    Automated
  • Scenario runs

    Labelled as simulation and read by your team

    Needs a person

What the flag now carries

Read together, never one without the others

  • Likely duration

    A central estimate and a pessimistic one

    Forecast
  • Confidence

    How far the history actually supports it

    Reported
  • Basis

    The past cases the estimate was drawn from

    Shown

Step 7: The decision queue is written in plain language

What does the executive have to act on today?

Decision queue

Ranked by materiality, not by who raised it loudest

Needs a decision today

  • Corridor handover at risk

    Four projects, one approved milestone

  • Import clearance still open

    Two sites waiting on the same permit

Watching

  • Design sign off running long

    Float is still absorbing it

Closed with a decision

  • Power connection resequenced

    Option and reasoning both recorded

What each item carries

Assembled by layer six before it reaches the queue

Root cause
The update the chain started from
Who it touches
Every project the walk reached
Options
Three, each one costed
Recommendation
One, with the reasoning shown

Step 8: The decision is recorded and the chain stays inspectable

Can anyone check how this conclusion was reached?

Ask the model directly

Answered by walking the graph, not by summarizing a status report

  1. Chief executiveWhat is blocking the pump station handover?
  2. OrchestratorOne chain reaches it. A tie in task is waiting on a permit that has been open six days.
  3. Chief executiveAnd if the permit clears this week?
  4. OrchestratorThe handover moves back inside its float. Here is the traversal, so you can check every hop.

Audit trail

Retained, and editable by nobody

  1. source

    The daily update, done

    Raw wording and the structured extraction

  2. rule

    The gate it was scored against, done

    The threshold in force on that day

  3. version

    The agent version that ran, done

    Logged with the output it produced

  4. decision

    What was chosen, and why, in progress

    Written back against the record

Illustration of how Master Project Intelligence System runs, with sample records rather than live account data.

What it does

One model of the program, instead of twelve status reports

Master Project Intelligence System takes the daily update every project manager already writes and turns it into one live model of the whole program. Tasks, milestones, approvals, and the dependencies between them sit in a single graph, so a slip reported on one site is followed automatically into every other project it can reach, and the people it lands on are told at the same time as the program office.

Your managers keep reporting and your controller keeps owning the plan. What stops is hearing about a cascading delay in a meeting, weeks after the update that caused it.

Who it is for

  • Program offices running many contractors against one master schedule
  • Executives who need a ranked decision queue, not another dashboard
  • Controllers curating a dependency graph that has to stay honest
  • Assurance teams that must trace an escalation back to its source

How it works

Six layers, and the two controls that hold them to account

Each layer has one narrow job and reaches the others only through the shared model, which is what makes any single layer replaceable and every escalation traceable.

  1. Phase 1, Update intake agent

    Layer one, intake

    • Takes the update by chat, form, or voice note
    • Normalizes it into the daily update schema
    • Asks a targeted question rather than rejecting the submission
  2. Phase 2, Project agent

    Layer two, reconciliation

    • Loads the approved baseline for that project
    • Compares what was reported against what was planned
    • Flags slippage that stays inside one project
  3. Phase 3, Master data and graph

    Layer three, the substrate

    • Writes tasks, dates, and declared dependencies
    • Keeps the raw update beside the structured extraction
    • Runs as data engineering, not as a language model
  4. Phase 4, Cross impact engine

    Layer four, propagation

    • Walks forward from every task the update touched
    • Separates what float absorbs from what passes through
    • Scores materiality against a gate your office sets
  5. Phase 5, Predictive agent

    Layer five, early warning

    • Conditions the slip on comparable cases already seen
    • Reads the language that has run ahead of delay before
    • Reports confidence and basis with every number
  6. Phase 6, Orchestrator

    Layer six, briefing

    • Ranks what cleared the gate by materiality
    • Writes the root cause in plain language
    • Costs three options and recommends one
  7. Phase 7, Identity and access control

    Across every layer, scoping

    • Scopes the query itself, not just the screen
    • Runs every agent action under a named identity
    • Keeps commercial detail from crossing between contractors
  8. Phase 8, Audit and model registry

    Across every layer, traceability

    • Versions every agent prompt and every rule
    • Logs which version produced which output
    • Traces any flag back to the update that caused it

FAQ about Master Project Intelligence System

Straight answers on scope, timelines, and what running Master Project Intelligence System asks of your team.

Get started

Stop paying people to do what an agent can

Tell us what you want to automate. We will map the workflow, deploy the right agents, and train your team to run them.

  • Every agent is trained on your own workflows, never a generic template
  • Most deployments are live within two to four weeks
  • SOC 2 compliant, with a complete audit trail on every deployment
Free demo