AI estimation of engineering hours.
A dedicated database and an agentic system to estimate engineering effort for EPC projects, drawing on the MDR and experience from previous projects.

Competitive bids. Engineering effort estimated with care.
In an EPC tender, an inaccurate estimate of engineering hours can undermine the entire project. Underestimating exposes the contractor to uncovered costs; overestimating can make the bid uncompetitive. The MDR — Master Document Register, the register of required deliverables — defines the documentation scope, but translating it into effort requires consideration of complexity, disciplines, checks and revisions. Relevant experience often exists in previous projects, but is difficult to retrieve and compare.
- Agentic AI
- Project database
- Effort estimation
What we designed.
A useful estimate combines organised data, domain knowledge and reasoning about differences between projects. The database retains context; the agentic system helps access it and prepare the assessment. The engineering team reviews scope and assumptions before translating hours into a commercial offer.
Build a database for estimating
We worked on a dedicated database that organises project information and historical records for use in estimating engineering activities associated with the MDR.
Support the team with an agentic system
The AI system supports estimate preparation by connecting the new scope with available historical information. The aim is to give the team a more structured basis for assessing the required hours and the assumptions behind a bid.
Converse with past projects
The same database enables natural-language access: the team can explore precedents, retrieve information and investigate the technical context of previous projects, making accumulated experience reusable.
MDR and project history
Database + agentic system
Engineering hours for review
Behind a total of hoursare many decisions.
Useful AI estimating requires organising the information that explains the work. These are the dimensions to connect, according to the data available.
Four dimensions of an estimate.
What must be produced
The deliverables and activities required by the new project.
- Deliverable types and quantities
- Discipline and engineering phase
- Technical and documentation requirements
What has been done
Precedents to compare with the new request while retaining context.
- Previous project documentation
- Historical scopes and solutions
- Available estimated and actual hours
What is different
Factors that can change effort even when document quantities stay the same.
- Complexity and opportunities for reuse
- Checks and revision cycles
- Interfaces and cross-discipline coordination
Which assumptions apply
Conditions to clarify when turning comparisons into a proposed estimate.
- Included and excluded activities
- Missing information to investigate
- Assumptions for the team to review
From tender scopeto engineering hours.
The new project raises the question. Historical data provides reference points. AI helps the team connect them and build an assessment.
Understand the work behind each deliverable.
The deliverables register is the starting point for understanding scope. Drawings, reports and specifications require different activities: production, checking and coordination.
- Required deliverables
- Disciplines and activities involved
- Requirements and delivery conditions
A defined scope to translate into engineering effort.
Put existing knowledge to work.
Information from previous projects is organised in a dedicated database. Context makes precedents useful: a similar project is not necessarily an equivalent one.
- Previous project information
- Deliverables and technical context
- Estimates and actuals, where available
A body of experience to consult and compare.
From reference points to a reasoned estimate.
The agentic system supports estimating by connecting scope with historical information. The proposal needs to be read alongside its assumptions and reviewed by the team.
- Scope of the new MDR
- Historical project data
- Assumptions and differences to assess
A basis for estimating hours and preparing a bid.
Give project history a conversational interface.
Organised knowledge can be queried in natural language. The team retrieves information about previous projects without having to reconstruct the context from scratch each time.
- Explore previous projects
- Investigate differences and requirements
- Retrieve information for new bids
Company knowledge available to the estimating team.
Data, agents and domain expertise.
Three complementary components: comparable information, analytical support and informed technical review.
A database built around the work
An archive becomes useful when it links deliverables to the project, discipline and available information about the work performed.
- Document context
- Linking deliverables to their project scope makes it possible to interpret a precedent correctly.
- Estimates and actuals
- Where available, estimated and recorded hours need to remain distinct: one describes an expectation, the other the work recorded.
- Comparability
- Differences in phase, content and complexity are part of the assessment: document counts alone do not explain effort.
Agentic support for estimate preparation
AI puts the database to work on the new request, helping retrieve and connect useful information.
- New project scope
- The estimate starts with required deliverables and the activities needed to produce, check and coordinate them.
- Historical references
- Relevant precedents provide reference points to adapt to the conditions of the new project.
- Assumption review
- Proposed hours provide a working basis for technical leads. Inclusions, exclusions and information gaps inform the bid decision.
Queryable project knowledge
The database serves more than the next estimate: it makes accumulated knowledge accessible.
- Natural-language search
- The team can ask questions of past project information and explore relevant precedents.
- Context before reuse
- Understanding what an assignment included helps assess whether its references apply to the new scope.
- Shared experience
- Documented knowledge becomes accessible to colleagues who did not work on the original project.
Competitiveness starts before the bid.
For an EPC contractor — Engineering, Procurement and Construction — estimating engineering effort combines technical and financial decisions. The project brings data and AI into this process to support more informed estimates, aiming to limit both underestimation risk and the risk of an uncompetitive bid.
Estimated hours support technical assessment; they are not a guarantee of actual effort. Historical data quality, scope and assumptions affect the result. Rates and commercial decisions remain the team’s responsibility.
Questions that matter
- Which past projects help us assess this MDR?
- What differs from the most relevant precedent?
- What hours are documented for comparable activities?
- What information do we need before finalising the estimate?
What it makespossible.
- Organised project knowledge to support estimating.
- AI support for estimating engineering effort in new bids.
- Conversational access to information from previous projects.
How much uncertainty sits behind the hours in your bids?
Let’s start with your context, available data and the first useful outcome.
Tell us about your project
AI technical archive.
An archive you can talk to: find similar projects, retrieve previous solutions and explore historical costs. An approach applied across different settings, from engineering firms to in-house technical departments.