How ConstructConnect Built a Governed Semantic Layer for Self-Service Analytics with Claude
Here's how ConstructConnect developed a governed semantic layer for self-service analytics, enhancing data consistency and usability across platforms.
This article was originally published August 2026, in Forbes, by Gaurav Singal, Chief Technology Officer at ConstructConnect®.
Every AI rollout I hear about starts in the same place: select an AI tool, choose a coding harness and schedule the training. Six months later, leaders wonder why adoption is mediocre.
The reason is that instead of concentrating on which training program to run, they should have been making sure the environment was ready for the tool and agents.
I learned the difference when we rolled out agentic AI development to all of our engineers at ConstructConnect in early 2026. We went from under 14% weekly active usage to over 94% in 12 weeks. Training mattered, but it wasn't what made the rollout successful or the adoption stick. The more important work happened before most engineers opened their AI coding harness.
Two weeks before our first training day, our AI center of excellence team spent most of its time preparing codebases, not writing curriculum. Modern AI coding agents need context to work effectively, not just during setup but in every session. When an agent opens a repository, it's implicitly asking:
What is this system for?
What conventions does this team follow?
What can I change independently?
What requires human approval?
What should I never touch?
If your codebase can't answer those questions, the agent improvises, sometimes correctly but often not. Either way, the results are inconsistent.
We built a context file (typically, CLAUDE.md or AGENTS.md) committed at the root of every repository. Each file is approximately 150 lines and explains the repository’s purpose, technology stack, CI/CD pipeline, integration dependencies and engineering conventions. It also defines three tiers of behavioral rules:
Things the agent should always do.
Things it should confirm before doing.
Things it should never touch without approval.
We now have these files in all our active repositories, and we auto-generate by having an agent analyze the repository’s structure, modules and dependencies. But this file isn't primarily for the AI. It captures the conversations many engineering teams have never written down.
Repository conventions, API boundaries and decisions about which authentication library to use and why often live in people’s heads rather than in the codebase. The agent-ready file forces you to write those decisions down, version-control and keep them current. Instead of relying on a document engineers must remember to consult, the repository itself becomes the source of truth guiding the agent’s behavior.
Do our most important repositories have a context file committed at the root?
Does it explain, in plain language, what the system does and who uses it?
Does it name the files or systems an agent shouldn't modify without human approval?
Do we have reusable, shared procedures for the workflows engineers run repeatedly?
Are the rules modular enough that only the relevant ones load for each task?
If the answer to any of those questions is no, your AI rollout will likely underperform regardless of which model, harness or training program you choose. Every engineer will pay an orientation tax during every session—a cost an organization should pay only once.
This isn't an elaborate technical project. We auto-generated our initial files using an internal skill that takes a couple of minutes per repository. The harder part was agreeing on what the conventions were.
That conversation turned out to be valuable independent of AI. It exposed inconsistencies and disagreements that teams had been working around for years.
What agent-ready codebases produce is visible in a team that had been working this way before the agentic rollout began. Our design system team used these same agent-ready foundations to accelerate delivery. The team shipped all its planned design components three quarters ahead of the original schedule. Its output reached six times their prior baseline with no additional headcount. The agent didn't replace the designers or engineers on that team. It expanded what they could ship in a day. That kind of compounding is only possible when the agent enters a codebase it can understand and navigate effectively.
There's also a benefit that has nothing to do with AI. A repository that can brief an AI agent effectively can also onboard a new human engineer faster. The first week a developer spends orienting in a new codebase costs real time. A well-maintained context file reduces that learning curve. It's infrastructure that pays the organization back twice.
The most common mistake I see in AI rollouts is training people before preparing the technical foundation. Organizations train everyone on Monday and plan to prepare the codebases later. That sequence is backward. It creates high initial enthusiasm but mediocre sustained value. I think of it being "high on AI"—a burst of excitement without the foundation required to produce lasting value. Engineers may then conclude that AI is more hype than help because their early sessions feel disorienting and slow.
We took the opposite approach.
We spent six weeks preparing the foundation and ran lighthouse teams for four weeks. Only then did we expand the agentic transformation across the full organization. By the time most engineers opened their AI coding harness, they were landing in codebases that were already prepared to work with an agent.
Twelve weeks later, 94% were still actively using the agentic stack. That wasn't because the tool was particularly easy or because our training was exceptional. It was because when an engineer sat down on day one, the environment was ready for them.
That preparation is the part most agentic AI transformation guides skip, and it's the difference between rollouts that generate temporary enthusiasm and ones that create durable adoption.
We applied this foundation-first approach to the creation of ConstructConnect Takeoff, our new AI-powered, web-based construction estimating solution that runs in your browser with no desktop installation. Its tools automatically name and scale your sheets, then it uses AI to detect and measure items on your plans.
That is what happens when the environment is ready for the agent: a robust product that answers what customers have been asking for, while providing us a roadmap to build more products that address the needs of the construction industry.
Gaurav Singal is ConstructConnect’s Chief Technology Officer. He is an award-winning global technology executive with more than 25 years of experience driving digital transformation, product innovation, and scaling technology organizations across fintech, logistics, gaming, and investment banking. Most recently, Gaurav served as Chief Technology Officer at Cantaloupe (NASDAQ: CTLP), where he led the company’s transformation into a global leader in unattended retail technology. He scaled a $3 billion-plus payments platform serving more than 1.2 million IoT (Internet of Things) locations across North America, expanded its SaaS platform internationally, and introduced AI-powered smart retail innovations. Previously, he served as Executive VP & CIO of the Georgia Lottery Corporation, where he led the organization through a successful digital transformation. His previous experience includes serving as the Chief Product Officer for Last Mile at XPO Logistics; and Vice President of Technology at Goldman Sachs, where he drove electronic trading innovation and AI-powered compliance analytics. Gaurav holds a Bachelor’s in Technology from the Indian Institute of Technology, Delhi, and a Master's in Computer Science from the University of Illinois, Chicago. Gaurav resides in Atlanta, Georgia.
Here's how ConstructConnect developed a governed semantic layer for self-service analytics, enhancing data consistency and usability across platforms.
I've spent twenty years in PMO roles, and two months leading a PMO through a shift to a Product Operating Model. I want to write about it now,...
You can give an engineering organization access to agentic tools very quickly. Getting the organization to work differently is the real test. Here...