In June 2026 the CITB published its Construction Workforce Outlook 2026–2030, and the numbers travelled fast: UK construction needs an average of 41,200 extra workers a year (about 206,000 by 2030) to grow the workforce toward a projected 2.68 million (Construction News; PBC Today). CITB is candid that “too few people are entering the sector, too many experienced workers are leaving, and productivity improvements have not been sufficient to close the gap.”

The second half of that sentence matters more than the first. The sector is old: roughly 35% of the workforce is over 50 and only about 20% is under 30, with total employment near its lowest in 25 years (Construction Management). The government’s own data tracks the wider over-50s employment picture too (GOV.UK, Sept 2025). By the mid-2030s a large share of today’s workers will have retired: the same “great retirement” wave we mapped out in our earlier piece on construction’s retirement cliff.

More than a third of UK workers in construction industry are over 50, while under-30s make up only a fifth with total employment near its lowest in 25 years.

Put the levers together and the squeeze is clear. Recruitment is running behind demand, retirements are accelerating, and, as CITB itself notes, productivity improvements haven’t been enough to close the gap. Two of the three levers (hire and train) are slow and capacity-limited, which throws the weight onto the third: doing more with the people you have. That’s the honest case for automation and agentic workflows: not to cut headcount, but to raise the efficiency of project delivery so a smaller, younger workforce can carry a bigger pipeline. And it pairs with knowledge capture rather than competing with it: capture preserves the judgement, automation lifts the throughput.

Recruitment plans count bodies. They don’t count what leaves with the retirements: the Tacit Knowledge (judgement, context, and hard-won experience, and the majority of what a firm actually knows) that keeps projects moving safely and quickly. It’s the reasoning a senior engineer applies almost automatically, and it was rarely written down anywhere a graduate can find it.

This is where the “AI will fix the skills gap” story needs a caveat. AI can absolutely support decision-making. But it cannot replace knowledge that was never captured in the first place. Point a model at your archive and it will only ever be as good as what’s actually in there, and most firms’ hardest-won judgement isn’t in the archive at all. It’s in people who are about to leave.

So the most valuable workforce move a firm can make between now and 2030 isn’t only to recruit and train faster (it should). It’s to capture senior-leader judgement while those senior leaders are still here: the decisions they make, the reasons behind them, the alternatives they rejected: structured, searchable, and connected to the projects they came from. Do that, and a junior can ask “how have we handled this before, and why?” and get a real answer, instead of interrupting the one person who remembers.

The skills gap is a hiring problem. The knowledge gap is a capture problem, and capture has a deadline. That’s the work that compounds: every retirement becomes an addition to the firm’s institutional brain rather than a subtraction from it.

From archive to a senior leader over your shoulder

Capturing the knowledge is only step one. A searchable archive still waits for someone to know what to ask, and juniors, by definition, often don’t know the question. The value shows up when that captured judgement is put to work proactively, in the flow of the work:

  • In-context recommendations: as an engineer works on a detail, the system surfaces how the firm has handled it before and why, the way a senior leader glancing over their shoulder would. The knowledge comes to them; they don’t have to go hunting for it.
  • On-the-job training that scales: instead of one senior leader mentoring three juniors, the captured reasoning coaches everyone, on every project, at once. It turns experience into a teacher that never retires and is never too busy.
  • Predictive foresight, not reactive lookup: because the system has seen the pattern across dozens of past projects, it can warn before the mistake: the clash that recurs on this building type, the spec clause that always gets missed, the assumption that bit the last three jobs. That is the difference between remembering what went wrong and preventing it from happening again.

This is the real answer to the 2030 cliff. You can’t clone a 30-year engineer, but you can capture their judgement, and then have AI apply it, teach it, and act on it foresightfully across a workforce that is younger and thinner than the one retiring. Experience stops being something you lose at a leaving do and becomes an asset that gets sharper with every project.

Capture the why, not just the what

None of this works if capture stops at the decision itself. A record that says what was chosen teaches a junior nothing; a record that captures why (the constraint that ruled out the obvious answer, the alternative that was rejected and the reason, the judgement call behind a number) teaches them to reason. This is where traceable decision-making earns its keep. It is usually framed as a compliance or golden-thread requirement, but its quieter payoff is knowledge transfer: when every decision links back to its rationale, its requirement and its author, a new engineer doesn’t just inherit the answer, they inherit the thinking behind it. That is the difference between a document store and a teacher, and it is what lets 30 years of “we tried that and here’s why it failed” actually pass to the next generation instead of retiring with the person who learned it the hard way.

Good data by design, not data hoarding

There’s a tempting shortcut: capture everything, point AI at it, done. It doesn’t work. Feed every file, email and superseded revision into a model and you teach it your average (dead-ends, mistakes and abandoned ideas included) with no way to tell what was good practice from what was quietly corrected later. Volume is not the goal. The goal is to build good data as a by-product of the work people are already doing, so quality accrues without a separate, resented data-entry exercise. A few principles for how that works in practice:

  • Capture at the point of work: decisions, checks and their context are recorded as they happen, inside the day-to-day workflow, not reconstructed afterwards from memory.
  • Record the why with the what: the rationale, the rejected alternatives and the requirement a decision serves travel with the decision, so the reasoning is preserved, not just the outcome.
  • Label what “good” looks like: approved, built, and proven-in-service is distinguished from rejected or superseded, so the memory knows the difference between what was merely done and what should be repeated.
  • Keep provenance: who, when, which project, against which requirement, so every insight is auditable back to its source rather than floating free.

Note what this is not: we’re not training a large language model on your data. We’re building a memory of what “good” looks like for a network of agents to draw on, a curated, provenance-rich store of decisions and outcomes, not a black-box weight update you can’t inspect. Good data in, reliable behaviour out.

If this sounds like the promise every knowledge-management system made for the last twenty years (the wikis, the SharePoints, the lessons-learned logs that quietly went stale), it’s a fair challenge, and worth answering directly. Those systems failed for three predictable reasons: capture was a separate chore bolted onto real work, so it didn’t happen; nothing distinguished good practice from noise, so the store filled with the average; and the knowledge sat passively, waiting to be searched by people who didn’t know what to ask. The difference here is structural on all three counts: capture happens inside the workflow rather than after it, “good” is explicitly labelled rather than assumed, and the knowledge is pushed to the engineer in context rather than filed away for them to hunt. It’s not a better filing cabinet; it’s the shift from a passive repository to an active memory that works.

Why a foundational LLM won’t fill the gap

The obvious objection is: can’t a general-purpose assistant just absorb all this? For most AEC work, no, and it’s worth being precise about why. Generic assistants and foundational LLMs are unreliable here for four connected reasons: they don’t have your data, they don’t have your context, running them at project scale carries real cost, and their outcomes are unpredictable. The model doesn’t actually know how your firm operates or what “good” looks like, and your knowledge is fragmented across disconnected tools it can’t see. That is what makes the output inconsistent and hard to audit, and it is exactly why, for anything that carries risk, automation still feels safer to you than an assistant right now.

That gap is the specific problem we build for. Rather than a generic assistant, Tektome is a foundational Multi-Intelligence platform: agents that work from your business context and are built to understand construction information, models, specifications, PDFs, 2D and 3D, not just prose. In other words, we bring the guardrails and the common standard you already value in automation to agentic workflows on live projects, so captured Tacit Knowledge is applied reliably, not merely plausibly.

At Tektome we build the knowledge layer for exactly this: turning the judgement in your people and past projects into structured, reusable intelligence. If the 2030 cliff is on your risk register, let’s talk.

Don’t let 30 years of judgement walk out the door. If the 2030 workforce cliff is on your risk register, speak with the Tektome team to see how Tektome can help capture and apply your team’s tacit knowledge: coaching juniors, flagging risks before they recur, and keeping your firm’s institutional memory compounding instead of retiring.