CEO Summary — what this system is and why it exists

The scoring system is our firm’s automated gut feel about every client, person, and project — built so the team’s attention automatically goes where it earns the most.

Every client carries two numbers. Credit (do they pay well, take fee and scope conversations gracefully, and are they good to work with — built from payments, invoice aging, email and call tone, and what our own team says privately) and Health (is the relationship warm and active — it decays a little every quiet day and recovers when we actually talk to them). Credit is uncapped: a client who pays four invoices the same day visibly pulls ahead of one who’s merely fine. Health stays 0–100.

Every person carries a warmth number (0–100), and every project carries a risk number built from the knowledge graph — open questions nobody answered, commitments we owe, risk flags, a struggling client, and cold people woven through the job. Old questions fade out of the score instead of inflating it forever, and a cold person tied to many of our jobs counts more than a one-job annoyance.

The highest-credit clients whose health is slipping, with whom we have the largest book of work, surface first — and within those clients, their most at-risk projects rise to the top.

Three rules keep it trustworthy. Every signal counts exactly once (no double-scoring). Conversations attach to a project first, and the project decides which client benefits — calling a third party like an architect no longer blindly credits whoever they’re globally linked to. And the AI only ever proposes; nothing moves a score from a knowledge-graph suggestion until a human accepts it, and every number is explainable and correctable from the screen it appears on.

Every dial is configurable at /settings/clients/score-settings, every change is audited, and build-time tripwires plus SQL regression tests keep anyone — human or AI — from quietly reading scores from the wrong place or re-introducing old math.

Paying early is rewarded.

Paying late is penalized.

All weights are configurabe and are used to automatically prioritize our tasks.

How does the knowledge graph fit into all of this?

We’ve been experimenting with knowledge graphs at PermitZIP because engineering firms are full of context that disappears. Gathering the right information when you need it on a complex project has an impedance mismatch problem in our industry.

A project is not just a folder. It is a messy web of people, clients, contractors, emails, meetings, decisions, site visits, open questions, promises, risks, and history. Most firms carry that in people’s heads until someone is busy, out sick, leaves, or just forgets. Then everyone starts digging through email like archaeologists.

That is the problem we all are trying to fix. Procore probably did the first best job at helping to solve that. But now we have new frontier models that are making personal in-house Procore a reality for everyone with a Codex or Cowork subscription.

Our knowledge graph went live a couple months ago.

And it is already starting to change how we look at projects. It pulls together the normal trail of work: emails, meetings, project records, people, companies, documents, open questions, commitments, and risk flags.

One project I keep coming back to is a complicated single family mega mansion on the beach. In the graph, you can see the project sitting inside a web of people, emails, meetings, documents, and unresolved issues. Our knowledge graph already had the information shown in image below (risk flags, open questions, open commitments). We are just associating a configurable point system to each of those. And calculating the risk for the project.

I can click to see the flags. I can disregard duplicated, or false or outdated information. But the signal is incredibly useful to us. We immediatley to go work on a project like this (for the fast paying clients that we like). The system is starting to show where the unresolved context is piling up.

What we’re learning

The graph is far from perfect. We’re actively monitoring, reseraching, and fine tuning how it works and what is classifies. Some signals are stale. Some things get counted wrong. Some relationships need cleanup. But even that is useful because now the mess is visible.

We are learning that emails, meetings, calls, comments, and project records should not all be treated the same. A one-hour meeting probably tells you more about project risk than a random email reply. A stale open question should not hurt a project forever. A client should not automatically get blamed for chaos caused by a contractor. A person with influence across five risky projects matters more than someone who was difficult once and is no longer active in the market.

PermitZIP is trying to make high-quality MEP engineering work on smaller commercial projects.

That means we deal with tight budgets, fast timelines, imperfect information, and a lot of coordination gaps. Those jobs can go sideways quickly if the firm is only reacting to inbox noise. We’re also dealing with a larger-than-average population of lower experienced players with expectations that are completely unrealistic (huge risk for everyone involved).

The graph gives us another way to ask better questions:

• Which projects are quietly accumulating risk?

• Which clients pay well but create a lot of drag?

• Which contractors keep showing up near unresolved issues?

• Which commitments are still open?

• Which relationships are getting colder?

• What is the chain of custody that lead to this decision?

• Which project needs leadership attention before it becomes a fire?

It helps our firm remember what happened, connect the dots, and point us toward what matters.

Technically speaking, it’s used to pre-feed our agents with that information so they can produce more accurate results (very important when each run might cost $10 or more).

What I’d try if I worked at another firm

First I would make sure I have a Claude Cowork or OpenAI Codex subscription with extra usage turned on. If I couldn’t get that, I would quit and find another job that would. What kind of company today doesn’t provide these resources to their engineers?

Anyway, I would not start by building a platform. I would pick one painful operating problem and model that.

For example: “We lose track of open questions after meetings.” Or “We do not know which clients are actually profitable until too late.” Or “Our PMs remember relationship history, but the company does not.” Or “We cannot see which projects are getting risky until someone is already mad.”

Take ten projects. Pull together recent emails, meeting notes, project folders, client names, companies, open issues, and payment history if you have it. Then ask how those things should connect.

I’d head straight to Claude or ChatGPT and prompt something like:

We are a [type of firm] and we are struggling with [specific recurring problem]. We have project data spread across emails, meeting notes, folders, CRM records, and accounting. How could we use a knowledge graph to connect people, companies, projects, issues, risks, and decisions? What is the simplest version we could test this week without building a full platform?

The knowledge graph is useful because firms like ours run on context, and context is easy to lose.

We are trying to make that context visible. Who was involved. What was promised. What is still open. Where risk is building. Which relationships matter. Which projects need help.

It is early, imperfect, and very much still under construction. But it already gives us better questions than we had before.

We all know business runs on relationships.

But recently, at our firm, we realized the software we use to run the business knows almost nothing about them.

Our CRM knows who got billed.

Who paid.

Who signed the proposal.

What stage the opportunity is in.

How much the lead is worth.

Ours even has a field where we can mark that we don’t like someone. The “client credit score.”

But it does not know how much that person matters.

It does not know that the contractor on this new job is the same one we fought with last time.

It does not know that the architect is polite over email but keeps steering the owner away from our recommendations.

It does not know that the developer bringing us work also keeps bringing us the jobs nobody wants to touch.

The firm knows all of that.

It just lives in hidden places that have been previously impractical to capture.

In a meeting comment.

In a project huddle.

In the five-minute vent after a frustrating review.

And then it disappears right before you need it.

So we’re trying to study ways we can capture this data once and for all.

The person who matters is not always the person who pays

It’s dangerous to treat “the customer” like the center of the universe.

Design and construction do not work that cleanly.

The owner may pay the invoice.

The architect may control the room.

The contractor may control the pace.

The developer may control the next three jobs.

The owner’s rep may be the person who quietly makes everything easier, or quietly makes everything harder.

So we stopped treating everything like one giant client record. We tried that, and it wasn’t giving us good predictive signals.

A billing customer pays us.

A company is the real-world business behind the work (multiple per project).

A person is a person (multiple per company per project).

The person carries reputation, warmth, and history.

We stopped obsessing over billing customer (top down) and started studying the people (bottom up).

The point of contact who loved you leaves, and the proposals leave with them.

The person who drove your team insane is suddenly signing contracts for your biggest account.

An account can look healthy right up until one project quietly goes nuclear.

Your CRM doesn’t store all that information. That is unless, you want to make your job managing CRM instead of closing deals.

We wired up the memory

Think about how much relationship data your team creates in a normal day.

Meetings.

Calls.

Emails.

Internal threads.

Site visits.

“Be careful, we’ve worked with them before.”

Nobody is documenting all of that by hand no matter how much HR tells them to.

So we wired it up.

Meeting transcriptions.

Call recordings.

Internal discussions.

Emails.

The system reads the stream and starts connecting the dots.

Who works for whom.

Who brought in what.

Who keeps showing up around risk.

Who makes projects smoother.

Who makes them harder.

All of it goes into a living relationship graph.

After only two months, it’s grown to tens of thousands of connections deep.

Built from conversations that used to evaporate.

The lesson so far is:

Just wire it up.

The company starts having a memory it never had before. Once you have the data, you can figure out how to use it later.

In some ways, it’s only possible to know what it can do for you until you capture it first.

So… just wire it up.

What we found

Things got interesting when we looked at the data.

Our graph had flagged a certain outside firm as a scope-creep risk.

Not once.

Four times.

Same name.

Same pattern.

Tense communication.

Extra internal effort.

Coordination that got harder than it should have.

The graph knew.

We did not act on it.

On paper, things looked fine.

In the room, people braced when the name came up.

The gut said run.

The paperwork said fine.

The difference between your collective gut instinct and the paperwork is reflected in your margins.

A real example: getting fired

A few weeks ago, a person showed up on one of our jobs.

We do not have a great relationship with them.

They had no contract with us.

This week, we got fired from that job.

Their opinion of our design was the reason.

For the record, their objections were wrong and not code-compliant.

Their recommendations to the client were illegal.

Didn’t matter.

They controlled the narrative.

Being right did not save us.

So we looked at the graph.

That one person had more than twenty relationships with other clients and projects in our world.

We were not looking at a difficult person.

We were looking at blast radius.

One confidently incorrect person with that much reach can do damage way beyond the project they are standing in.

Blast radius is the cost of ignoring influence

Once relationships live in a graph, influence stops being a gut feeling.

You can walk the connections.

One step out.

Two steps.

Three.

How many people, projects, companies, and clients can this person touch?

A difficult person on one job is annoying. A difficult person tied to twenty other relationships is a business problem.

And if they like you, great. That is a huge asset.

If they do not, pretending they do not matter is stupid.

And so now we’re finally getting a chance to measure the true cost of having an ego.

The old answer would have been easy.

“They are wrong.”

“They do not know what they are talking about.”

“They are recommending an illegal installation.”

Wouldn’t it be nice if being right mattered in business?

If it did, I could have retired at fourteen. Just ask my dad.

If a wrong person has twenty-plus relationships in our world, being right is not enough.

Ignoring them because your pride is hurt is not principled.

It is expensive.

The trick is to get the signal as quickly as possible that a high blast radius risk just showed up at the OAC meeting.

Where we are now

At PermitZIP, we already have passive capture running across meetings, calls, and emails.

We already extract people, companies, projects, and relationships into a living graph.

We already have tens of thousands of connections.

We already automatically score billing customers on credit and relationship health.

We already track warmth and reputation signals on people.

The next phase is connecting the graph directly into scoring and risk.

Who keeps showing up around problems?

Who has reach?

Who has low trust?

Which projects are exposed?

Which relationships need attention before they become expensive?

I want to know when someone pays well but hires contractors that burn the team.

I want to know when someone is difficult but influential regardless of our contractural relationship.

I want to know when the client is not the issue, but the third party around them is.

I want to know when a person with a bad history just showed up somewhere they can do real damage.

And I want to know when I need to swallow my pride because the relationship has more reach than my opinion of the person.

We’re rolling out a system upgrade this week. If it works, I’ll write more and start to release the technical findings in the white paper section of the site.

Stay tuned.

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York, hosts Kenneth Shultz, Engineering Director at PermitZIP, and Carter Huddleston, Electrical Principal Engineer at PermitZIP, sit down with Nick Heim, Senior Innovation Engineer at StructureCare, for one of the most practical and candid conversations of Season 4.

Rather than discussing AI as a futuristic concept, the episode focuses on how engineers are already integrating AI tools directly into daily workflows. From replacing traditional Google searches with context-aware AI systems to automating repetitive engineering tasks and dramatically reducing project turnaround times, Nick shares real-world examples of how AI is quietly reshaping productivity across the construction and engineering industries.

The conversation also dives into why many organizations still hesitate to adopt AI despite its obvious advantages, the rise of performative “AI thought leadership” on social media, and the widening gap between people talking about AI and professionals actively using it every day. Kenny, Carter, and Nick discuss workflow automation, prompt engineering, engineering analysis, AI-assisted communication, and how younger professionals increasingly view AI tools as a normal part of modern work.

Along the way, the trio explores practical implementation strategies, the limitations of free AI tools, cybersecurity and prompt injection risks, and the growing expectation that engineers and consultants will become AI-literate in the near future. They also unpack how large language models are changing collaboration, research, and technical problem-solving inside engineering environments.

Fast-paced, highly relatable, and packed with actionable insight, this episode is an honest look at where practical AI adoption stands today, and how quickly the gap is growing between companies embracing these tools and those falling behind.

Keywords

AI in engineering, artificial intelligence, engineering workflows, AI adoption, construction technology, workflow automation, ChatGPT, prompt engineering, digital transformation, engineering productivity, AI tools, large language models, construction innovation, AI implementation, future of work, engineering technology, business automation, prompt injection, AI security, productivity acceleration

Takeaways

• AI is increasingly becoming a standard utility tool for engineers and knowledge workers.

• Practical AI implementation matters far more than theoretical AI discussions.

• Many professionals still underestimate how rapidly AI workflows are improving productivity.

• Context-aware AI tools are beginning to replace traditional search-based workflows.

• Companies resisting AI adoption may face growing competitive disadvantages.

• Younger engineers are integrating AI into work and personal life simultaneously.

• AI-assisted engineering workflows can dramatically reduce repetitive task time.

• Understanding AI risks and cybersecurity concerns is becoming increasingly important.

Chapters

1. Welcome and Building Smarter with AI Conference Intro

2. Meet Nick Heim: Innovation Engineering and AI Workflows

3. Why AI Is Becoming a Standard Utility Tool

4. The Difference Between AI Theory and Real Usage

5. Replacing Google with Context-Aware AI Systems

6. Engineering Productivity and Workflow Automation

7. Why Companies Still Resist AI Adoption

8. The Rise of AI Thought Leadership Culture

9. How Younger Engineers View AI Differently

10. Using AI for Research, Analysis, and Communication

11. Prompt Engineering and Real-World AI Implementation

12. Cybersecurity, Prompt Injection, and AI Risks

13. How AI Is Accelerating Engineering Workflows

14. What the Future of AI Adoption Looks Like

15. Final Thoughts and Where to Find Nick Heim

Where to Find Nick Heim

LinkedIn · StructureCare

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

A lot of engineers on X have apparently forgotten basic engineering economics.

The current argument goes like this:

VC money is drying up.
AI compute is getting expensive.
Some AI workflows cost as much as human labor.
So replacing people with AI may not be as cheap as everyone thought.

After a year of layoffs, that is an easy headline to enjoy.

“Humans are back.”

Maybe.

But be careful.

The fact that AI token spend can approach, or even exceed, human labor cost does not automatically make the human-only workflow more economical.

It means the comparison finally has to get serious.

Cost only matters relative to output.

And output only matters relative to profit.

So no, software jobs are not suddenly safe.

Neither are AE jobs.

The risk is just moving from cheap AI hype to actual operating model math.

The wrong comparison

People keep comparing AI spend to salaries like those are interchangeable budget lines.

“This team spent $100 per employee per day on frontier model usage.”

Okay.

What did they produce?

Did they ship more features?
Did they close more tickets?
Did they review more submittals?
Did they answer more RFIs?
Did they reduce rework?
Did they increase billable throughput?
Did they create something the company can actually sell?

Without those answers, the cost number is mostly noise.

A fully human workflow might cost X per unit of output.

A human-plus-AI workflow might cost Y per unit of output.

That is the first comparison.

But it still is not enough.

The better question is:

How much profit does each dollar of spend generate?

Cost per output is not the final metric

Cost per feature matters.

Cost per RFI response matters.

Cost per submittal review matters.

Cost per drawing revision matters.

But none of those numbers matter by themselves.

A company does not survive by producing output. It survives by producing profitable output.

So the real question is:

“How much sellable work did this cost create?”

In software, the useful metric might start with dollars per shipped feature, then move to revenue, retention, or usage created by that feature.

In engineering and construction administration, it might be dollars per billable hour, dollars per RFI response, dollars per reviewed submittal, or dollars per completed revision.

The unit changes by industry.

The economic relationship does not.

What this looks like for an AE firm?

In the AE industry, a lot of engineering-side work is hourly.

That gives us a natural translation layer.

Human time becomes billable hours.

Now token consumption has to fit into that same model.

So we convert token spend into an effective hourly charge based on the person driving the agent. Tokens are not treated like some random software expense sitting off to the side. They are tied to the project work they support.

If an engineer is using agents to support construction administration work, those agents may help draft RFI responses, review submittals, generate revisions, research code paths, assemble context, or improve the depth and quality of a response.

The token spend is attached to the work.

And when the work is billable, the token spend can be translated back into revenue.

We do this now at PermitZIP.

At the time of writing this, our effective billing rate rate is around 6.7x our token spend.

That is before fully measuring the productivity gain.

We have not yet fully quantified how many more RFIs, submittal reviews, revisions, or permit-related tasks one person can complete per day with the right agent workflow.

But we already know the token spend itself can produce a return when it is aimed at billable project work.

So the upside is not just:

It is:

That is a very different economic picture.

Humans bill linearly

A human can only bill for the time they spend.

One hour of human time generally becomes one hour of billable time.

That is the traditional professional services model.

It scales linearly-ish.

This is one reason engineering firms often get low valuation multiples. Revenue is tightly coupled to headcount. More work requires more people. More people create more coordination, more management, more review, more overhead, more inefficiencies, and more risk.

AI changes the shape of that relationship.

The objective is fine tuning what one good human can drive.

If one engineer spends an hour directing multiple agents across multiple projects, and those agents consume tokens that are tied to billable project work, that engineer may create more than one hour of billable value inside one clock hour.

The right human, driving the right token spend, can produce and support more billable output than the human could produce alone.

Some work is still cheaper with humans

Some work is still cheaper with humans.

There are tasks where the prompting, validation, retrying, reviewing, and context loading cost more than just having a competent person do the work.

There are tasks where the model creates output quickly, but also creates just enough uncertainty that a human has to inspect everything anyway.

There are tasks where the token spend is real, the latency is annoying, the error rate matters, and the productivity gain is not enough to justify the workflow.

The economics are task-specific.

Engineers should understand this.

A tool is not good because it is technically impressive. It is good when it improves the system.

Token cost does not map cleanly to labor cost

We have been paying for token consumption for over a year now at PermitZIP.

It is already obvious that token cost does not map cleanly to human labor cost.

A dollar of human labor and a dollar of token spend do not produce the same kind of output.

Human labor is flexible, contextual, and slow.

Token-driven execution is fast, scalable, and uneven.

Both are non-deterministic in their own annoying ways.

Both are also confidently wrong more often than anyone wants to admit.

Humans get distracted, misunderstand priorities, get tired, miss details, defend bad assumptions, have egos, and have bad days.

Models hallucinate, over-answer, miss context, follow bad instructions too confidently, and sometimes create work that looks finished before it is actually useful.

Humans can notice when the request is dumb.

Models can brute force through structured work at a speed humans cannot touch.

Humans carry judgment.

Models carry throughput.

The return profile is not the same.

The advantage comes from blending human judgment with token-driven execution.

Outsized returns show up when the human knows how to direct the system.

The budget shift.

A lot of companies staffed up for human-only throughput.

Then they discovered that serious AI usage is not just a few subsidized subscriptions.

It is infrastructure.
It is token budget.
It is tooling.
It is evaluation.
It is workflow redesign.
It is people who know how to direct the system.

So now companies are rebalancing.

The layoffs we are seeing in tech are tied to this recalibration of production costs.

Budgets are moving from headcount-only operating models to blended systems where compute is a real cost center.

Companies usually cannot keep the same labor budget and simply add serious AI spend on top.

The money has to come from somewhere.

In many cases, that means fewer people, higher-leverage people, and more expensive tools.

That sounds harsh.

But supply and demand does not care about your feelings.

The operating model has changed.

The objective is whether the blended system produces more profitable output per dollar.

Ignore that at your own risk.

Being laid off today can mean getting locked out of the industry for a long time, because the cost of labor plus tokens is being reconciled in real time.

If you get booted from the human part of the system, do not assume another company is backfilling with more humans.

A lot of them are not.

They are making room for the tokens.

The useful metric is profitable output per dollar

This is where the conversation should be.

Not “AI is cheaper than humans.”

Not “AI is more expensive than humans.”

Those are lazy categories.

The useful questions are:

Then:

For software, maybe that starts with cost per feature or features shipped per day. But the company still has to ask whether those features increase revenue, reduce churn, expand usage, or create enterprise value.

For AEC, maybe it is RFIs answered per day, submittals reviewed per day, revisions completed per day, or permits processed per week.

But the output has to connect to dollars.

Can it be billed?
Can it protect margin?
Can it reduce write-offs?
Can it improve cycle time?
Can it increase the amount of work one person can responsibly carry?

Headcount is not the only scarce resource

A lot of people are emotionally attached to headcount as the main measure of capacity.

More people means more output.

Sometimes.

But every manager who has actually run an engineering team knows headcount also creates coordination cost.

More reviews.
More meetings.
More onboarding.
More QA.
More HR.
More process.
More communication paths.
More places for work to hide.

AI has its own costs too.

Prompting.
Context management.
Tooling.
Evaluation.
Human review.
Bad outputs.
Security concerns.
Token burn.
Adoption.

Neither system is free.

The point is not to worship AI or defend headcount.

The point is to compare operating models honestly.

The best AI systems are human-directed

The strongest workflows I have seen are human-directed systems.

A person with judgment defines the task, constrains the output, reviews the result, and decides what matters.

The model handles the parts where speed, volume, pattern matching, drafting, restructuring, extraction, research, or iteration create leverage.

The return comes from designing a system where human judgment sits in the right place.

Many companies treat AI like a toy subscription or a magic labor replacement machine.

Both are bad operating models.

The better model is more uncomfortable:

Fewer people.
Better people.
More expensive tools.
More output.
More revenue per human.
More profit per dollar of total spend.

That is where this is going.

Wishful thinking does not change the math

If AI costs as much as a human engineer per year, that does not automatically make it expensive.

If it produces significantly more profitable output per dollar, it is cheap.

If it produces noise, rework, and review burden, it is expensive.

The annual spend alone does not answer the question.

Neither does the token bill.

Neither does the salary comparison.

The metric is the blended system:

Human cost plus token cost, measured against useful output, then measured against dollars generated.

That is basic engineering economics.

Software engineers should understand this better than almost anyone.

Cost. Throughput. Quality. Constraints. Revenue. Return.

That is what matters now.

That is what the industry is calibrating around.

Employees can ignore it.

Companies can ignore it.

Neither gets a special exemption from the math.

Tech is already laying people off while it figures out the right mix of humans, tools, and compute.

AEC is not immune to that.

If you are an employee and you want to pretend this is hype, fine.

Understand the risk.

If your job gets cut, the replacement may not be another person.

It may be a smaller team with better tools, bigger token budgets, and a different operating model.

Getting back in will be harder if your skills only fit the old model.

Maybe you are locked out for a few months.

Maybe a few years.

Maybe permanently if the work you used to do gets absorbed into the system and the industry stops hiring for it.

That is what happens when production costs get recalibrated.

If you run a company, the warning is just as direct.

Your competitors are doing this math too.

They are testing where humans matter, where agents work, where tokens replace labor, where quality improves, where margins expand, and where cycle time collapses.

Some of them will figure it out before you do.

They will produce more with less.

They will price differently.

They will hire differently.

They will carry more work per person.

They will generate returns you cannot match with a headcount-only model.

So measure the system honestly.

Human cost.
Token cost.
Useful output.
Revenue generated.
Margin protected.
Rework avoided.
Cycle time reduced.

The recalibration is already happening.

You can participate in it, or you can be priced by it.

From replacing traditional Google searches with context-aware AI tools to automating engineering workflows and boosting productivity, the discussion dives into the real-world side of AI adoption, far beyond social media hype and “thought leadership.”

The episode also explores why some companies are still resisting AI, how younger engineers view these tools differently, and why practical implementation matters more than theory.

Recorded live at the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York.

🎧 Full episode drops Tuesday, May 26th, 2026.

PSA for anyone mad at their HVAC engineer or installer in Richmond today:

Your system was not designed to hold 68°F during peak summer.

It was not supposed to be.

It may not even be legal to design it that way.

Virginia energy code is clear:

For load calculations, the interior design temperature used for cooling cannot be lower than 75°F.

Not 72°F.

Not 70°F.

Not 68°F because someone likes it cold.

The code-compliant design basis starts at 75°F for cooling.

So if your office is sitting at 75°F to 78°F on a brutal summer day, that does not automatically mean something is wrong.

It means the system is doing exactly what it was legally designed to do.

The engineer did not miss your desire to be cold.

The installer did not magically override physics.

The code-compliant design basis is not “whatever temperature makes the owner happy.”

Cooling load calculations are based on required indoor design conditions, outdoor design conditions, occupancy, solar load, ventilation, envelope, equipment loads, and actual physics.

HVAC systems are not magic boxes that create unlimited cooling because somebody keeps pressing the down arrow on the thermostat.

The system was sized around a design condition.

The equipment was selected around a design condition.

The ductwork, airflows, controls, ventilation, zoning, and load assumptions were all built around a design condition.

If that design condition was 75°F indoors at the applicable outdoor design temperature (which is what Virginia energy code requires), then expecting the system to hold 68°F during peak summer is asking the system to perform outside the legal design basis.

Could there still be a problem?

Absolutely.

Bad airflow.

Bad balancing.

Bad controls.

Dirty filters.

Poor zoning.

Bad maintenance.

Undersized equipment.

A space being used differently than designed.

You were too cheap to buy the right equipment (most common).

All real.

Those issues happen every day.

They should be investigated when the symptoms point that direction.

But “I want it to be 68°F when it is 98°F outside” is not evidence of bad HVAC design.

It is evidence that you do not understand the design basis.

There is a difference between a system failing and a system being asked to violate the assumptions it was legally designed around.

A building sitting at 78°F during extreme heat is not automatically a failure.

A tenant being uncomfortable does not automatically mean the engineer missed the load.

A thermostat setpoint does not rewrite the energy code.

And no, yelling at the installer does not change the outdoor design temperature.

Before blaming the engineer or installer, ask the only question that matters:

What indoor and outdoor temperatures was the system designed around?

That answer controls the conversation.

Not the thermostat setting someone wishes they had.

Not the owner’s preference.

Not the loudest person in the office.

The code and your budget set the design basis.

You may not like the answer.

But the code does not care about your comfort.

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York, hosts Kenneth Shultz, Engineering Director at PermitZIP, and Carter Huddleston, Electrical Principal Engineer at PermitZIP, sit down with Anthony Scoppettone, Business Development Director, Strategic Accounts at ARCAP Consulting, for a grounded conversation about how artificial intelligence is transforming the construction industry.

With over 26 years of experience spanning scaffolding, glazing, waterproofing, roofing, manufacturing, project management, software development, and consulting, Anthony brings a uniquely practical perspective to the AI conversation. From hanging off skyscraper building scaffolds to implementing automation into modern business workflows, he shares firsthand insight into how construction professionals are adapting, or struggling to adapt, to rapid technological change.

The discussion explores AI adoption in construction firms, why many experienced professionals remain hesitant to embrace AI tools, and how younger generations are increasingly being tasked with implementing digital transformation inside legacy organizations. Anthony and Kenny also dive into the growing role of large language models (LLMs), AI-powered communication, workflow automation, and the challenge of preserving institutional knowledge as the industry evolves.

Along the way, the trio unpacks the realities of information overload, managing hundreds of daily emails, AI-assisted marketing, and how tools like Canva, Buffer, and language models are quietly reshaping day-to-day business operations. They also discuss why AI is unlikely to replace experienced professionals outright, but instead may amplify expertise by allowing “unlimited seniors to unlimited juniors.”

Candid, practical, and highly relevant to anyone navigating the future of work, this episode is an honest look at the intersection of construction experience, workforce evolution, and AI-driven transformation.

Keywords

AI in construction, construction technology, digital transformation, construction industry, artificial intelligence, construction management, institutional knowledge, AI adoption, construction leadership, workforce transformation, business automation, LLMs, construction innovation, project management, future of work, AI tools, construction consulting, generational workforce shift, business development, manufacturing technology

Takeaways

• AI is becoming increasingly necessary for managing modern construction and business workflows.

• Institutional knowledge remains one of the industry’s most valuable assets.

• Younger professionals are often leading AI implementation inside traditional organizations.

• Many construction companies remain hesitant to adopt AI due to legal, ethical, and operational concerns.

• AI tools can significantly improve communication, email management, marketing, and productivity.

• Pairing experienced professionals with AI-assisted junior employees may accelerate workforce development.

• AI is not replacing expertise; it is amplifying access to knowledge and information.

Chapters

1. Welcome and Live Podcast Setup

2. Meet Anthony Scoppettone: From Scaffolding to Software

3. Working on Skyscrapers, Stadiums, and the World Trade Center

4. Managing Construction Operations and Large Field Teams

5. Implementing Technology Across Multiple Industries

6. AI for Email Management and Workflow Automation

7. Why Construction Companies Resist AI Adoption

8. Using AI Tools for Marketing and Social Media

9. Generational Shifts and Institutional Knowledge

10. Can AI Replace Junior-Level Work?

11. The Role of LLMs in Workforce Development

12. Legal and Ethical Concerns Around AI

13. Manufacturing, Product Consulting, and Digital Transformation

14. Why AI Is Not Going Away

15. Final Thoughts and Where to Find Anthony

Where to Find Anthony Scoppettone

LinkedIn · ARCAP Consulting

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York, hosts Kenneth Shultz, Engineering Director at PermitZIP, and Carter Huddleston, Electrical Principal Engineer at PermitZIP, sit down with Melita Cekani, Founder of Cekani Architectural Design, to explore how artificial intelligence is transforming architecture and interior design workflows.

With a background in both art and architectural design, Melita shares how her studio uses AI to accelerate concept development, generate design iterations, and support creative exploration, while still relying on human judgment for final execution. The conversation dives into the growing realism of architectural rendering, the blurred line between renders and real photography, and the challenge of maintaining originality and artistic direction in an AI-assisted world.

The discussion also explores modern design operations, including working with international rendering teams, leveraging time-zone advantages for around-the-clock production, and using AI tools to improve communication, proposals, and client collaboration. Along the way, the trio unpacks the realities of residential design, managing subjective client feedback, and structuring creative workflows so projects don’t spiral into endless revisions.

From luxury interiors and visualization technology to remote collaboration and AI-enhanced productivity, this episode offers a practical and honest look at where creativity and technology are heading.

Thoughtful, visually engaging, and highly relevant to both creatives and technologists, this episode is a deep dive into the future of design in the AI era.

Keywords

AI in architecture, interior design, architectural visualization, AI rendering, luxury interiors, architectural design, AI-assisted creativity, photorealistic rendering, 3D rendering, design technology, AI workflows, remote design teams, architectural rendering software, creative AI, future of architecture, ChatGPT for design, digital design tools, AI in interior design, design process, architecture podcast

Takeaways

• AI can accelerate concept development and creative exploration in architecture and interior design.

• Human judgment and artistic direction still drive final design decisions.

• Hyper-realistic renders are becoming increasingly difficult to distinguish from real photography.

• Global remote teams can create near 24-hour production workflows.

• AI tools improve communication, proposal writing, and client collaboration.

• Residential design requires balancing creativity with client expectations and clear boundaries.

• Structured iteration processes help prevent endless design revisions.

Chapters

1. Welcome and Live Podcast Setup

2. Meet Melita Cekani and Cekani Architectural Design

3. Using AI for Architectural Concepts and Iterations

4. Artistic Backgrounds and Creative Design Thinking

5. Can You Tell Render From Reality?

6. The Limits of AI in Interior Design

7. Managing Global Design Teams and Time Zones

8. Communication Challenges and AI-Assisted Collaboration

9. Residential Design and Client Expectations

10. Using Miro Boards and Structured Design Workflows

11. Why Interior Design Can Become Endless

12. AI, Photoshop, and Rendering Enhancement

13. The Future of Creative Workflows in Architecture

14. Final Thoughts and Where to Find Melita

Where to Find Melita Cekani

Instagram · LinkedIn · Cekani Architectural Design · Melita Cekani

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

From AI-assisted concept generation and hyper-realistic renders to global design collaboration and client communication, this episode explores where artificial intelligence helps and where human creativity still leads.

Recorded live at the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York.

🎧 Full episode drops Tuesday, May 12th, 2026.

The AI Policy Question Is Too Small

Imagine you are sitting in the room drafting your company’s AI policy.

Someone says:

“We need to make sure employees do not paste sensitive project information into ChatGPT.”

Everyone nods.

Of course.

Nobody wants proprietary data, client information, project disputes, pricing, contracts, employee records, or internal decisions exposed to a system they do not fully control.

But then ask the question that makes the room uncomfortable:

Are employees allowed to email that same information?

Because if the answer is yes, your policy has a hole big enough to drive a bid package through.

Construction keeps asking the AI question too narrowly:

What sensitive information should employees avoid putting into ChatGPT?

Good question.

Incomplete question.

We Already Sent It Everywhere

Before ChatGPT showed up, what did we do with that same information?

We emailed it.

Forwarded it.

Attached it as a PDF.

Uploaded it to a shared drive.

Sent it through a bid invite.

Dropped it into a portal.

Printed it.

Scanned it.

Photographed it.

Copied five more people.

Then we acted like the information was still controlled.

Construction Runs on Distributed Information

Paper sounds safe until it gets scanned into a PDF.

Phone calls sound safe until the call gets transcribed.

In-person conversations sound safe until half the room has AI note-taking tools running.

Secure portals sound safe until you ask basic questions.

Secure from whom?

For how long?

With what logging?

With what downstream integrations?

With what vendor access?

With what AI features turned on by default?

The AI conversation keeps getting framed like this is about one box on one website.

Do not put sensitive data into ChatGPT.

Fine.

But the data was already out of the building.

It was already in inboxes, attachments, cloud folders, portals, vendor systems, subcontractor accounts, project management platforms, scanned PDFs, OCR indexes, and forwarded threads nobody could fully trace.

That does not mean every system is the same.

It does not mean security is fake.

It does not mean companies should be careless.

But it does mean the clean mental model is wrong.

The model says private information is something you possess.

Construction does not really work that way.

Construction runs by distributing information.

Drawings have to move.

Specs have to move.

Pricing has to move.

RFIs have to move.

Submittals have to move.

Schedules have to move.

Client comments have to move.

Internal decisions become external coordination.

Private information becomes project information.

Project information becomes shared information.

Shared information becomes somebody else’s attachment.

The Inbox Is Not a Vault

Healthcare has HIPAA.

Finance has stricter frameworks.

Government work has classification systems.

Some industries have real restricted-information infrastructure.

Construction mostly runs on contracts, NDAs, civil disputes, relationships, trust, email threads, PDF attachments, forwarded markups, shared drives, RFIs, submittals, bid invites, and “looping in” five more people.

That is the actual operating system.

And the inbox is not a vault.

It is a distribution layer.

Once something lands in email, you often lose meaningful control over where it goes next.

It can be forwarded.

Downloaded.

Indexed.

Backed up.

Searched.

Summarized.

Copied into another system.

Attached to another thread.

Dragged into a folder that syncs somewhere else.

Read by software.

Parsed by software.

Stored by software.

Eventually, maybe learned from by software.

The Old Moats Are Drying Up

People get very focused on whether ChatGPT will train on their data.

I understand why.

But that fear is already too narrow.

Construction has spent decades treating certain things like they were the crown jewels.

The spreadsheet someone built ten years ago.

The standard spec note that gets copied from project to project.

The detail library passed around internally.

The checklist.

The template.

The way one senior person likes to phrase something on a drawing.

That used to feel like institutional knowledge.

In some cases, it was.

But a lot of that value is not going to survive contact with modern AI.

A spreadsheet that took someone years to perfect can now be recreated in minutes.

And it will be better. Way better.

A specification section can be drafted, compared, revised, and adapted from a short prompt.

A standard detail library is not the moat it used to be.

Copying and pasting old standards from project to project is not some protected advantage.

In many cases, it is probably a worse way to work now.

A lot of what construction has historically treated as proprietary knowledge is becoming commodity knowledge.

Get used to it.

Not Everything Is a Secret

That does not mean nothing should be protected.

Some things absolutely should be.

Employee information.

Personal financial information.

Private client information.

Security-sensitive building information.

Legal strategy.

Credentials.

Anything that would create real harm if exposed.

But construction contracts love to call everything confidential.

That does not make everything worth protecting like a secret.

Build the Tool That Replaces the Spreadsheet

If every drawing note, spreadsheet, template, markup, and internal comment is treated like protected intellectual property, the industry cannot function.

Not in an AI world.

Maybe not even in the world we already have.

Construction requires information to move.

AI makes that movement more useful.

The upside is that we can stop worshiping old artifacts and start building better tools.

Use the data.

Use the patterns.

Use the lessons buried in old projects.

Use the RFIs, submittals, markups, estimates, and schedules to improve how work gets done.

Build systems that help teams make better decisions.

Build tools that reduce rework.

Build tools that make coordination faster.

Build tools that turn experience into leverage instead of letting it sit in someone’s private spreadsheet until they retire.

That is where the value is moving.

Not toward hoarding every piece of information.

Toward knowing what to do with it.

The old question was:

How do we stop anyone from copying our stuff?

The better question now is:

What is still worth protecting, and what should we be using to build the next version of how we work?

If your company’s advantage is a spec paragraph someone wrote twenty years ago, you do not have much of an advantage.

If your advantage is judgment, execution, relationships, accountability, speed, and the ability to turn messy project information into better outcomes, that is different.

That is much harder to copy.

And it is much more useful.

So yes, be careful with AI tools.

But stop pretending the goal is to keep every piece of construction knowledge locked in a vault.

There is no vault.

There is email.

There are PDFs.

There are portals.

There are shared drives.

There are vendors.

There are models.

There are tools that can recreate in seconds what used to take years to accumulate.

A lot of that old knowledge is becoming cheap.

That does not make it useless.

It means the value has moved.

The spreadsheet is not the moat anymore.

What you build with the knowledge is.

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York, hosts Kenneth Shultz, Engineering Director at PermitZIP, and Carter Huddleston, Electrical Principal Engineer at PermitZIP, sit down with Juan Vides, Vice President at Hire Point USA, Founder of Winning on Wednesday, and Business Development Manager at TechAcs, Inc.

With a background in programming turned business development, Juan shares practical insights on what actually drives sales in today’s world. From building a network through consistent outreach to creating meaningful relationships that go beyond transactions, the conversation explores the fundamentals of trust-based business.

The discussion covers the power of in-person networking, the limitations of digital-only communication, and why consistency is the most underrated advantage in sales and content creation. Juan also explains how his long-running networking group and podcast have helped him connect with professionals across industries, from students to executives, by focusing on authenticity and value.

Along the way, the trio dives into real-world lessons on personal branding, lead generation, and why many professionals struggle to promote themselves effectively. They also unpack the idea that people still prefer to work with those they trust, and how building that trust requires time, repetition, and genuine interaction.

Candid, relatable, and highly actionable, this episode is a practical guide for anyone looking to grow their network, improve their sales approach, and build long-term business relationships in an increasingly digital world.

Keywords

Sales strategy, business development, networking, relationship marketing, personal branding, B2B sales, lead generation, professional networking, content creation, trust-based selling, digital marketing, in-person networking, sales consistency, podcast marketing, LinkedIn networking, business relationships, entrepreneurship, client acquisition

Takeaways

• People still do business with those they know, like, and trust.

• In-person interaction remains one of the most effective ways to build relationships.

• Consistency in outreach, content, and networking compounds over time.

• Trust and rapport cannot be built instantly—it requires repeated interaction.

• Authenticity and sincerity are critical in building long-term business relationships.

• Personal branding and visibility play a key role in attracting opportunities.

• Many professionals underutilize self-promotion, which limits growth.

Chapters

1. Welcome and After-Hours Setup

2. Meet Juan Vides: From Programming to Business Development

3. Selling Safety Gear and Understanding Market Needs

4. Building Leads Through Networking and Digital Strategies

5. Why In-Person Networking Still Matters

6. The Impact of COVID on Business Relationships

7. Launching Winning on Wednesday: A Networking Community

8. Podcasting and Content Creation for Growth

9. Consistency as a Competitive Advantage

10. Building Trust Through Relationships

11. Authenticity vs Transactional Selling

12. Personal Branding and Self-Promotion

13. Golden Nuggets: Consistency and Genuine Connection

14. Final Thoughts and Where to Find Juan

Where to Find Juan Vides

LinkedIn · TechAcs · Winning on Wednesday

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

From building relationships through networking to the power of consistency and authenticity in sales, this episode dives into what actually drives business today. Juan shares practical insights on in-person connection, personal branding, and why trust still matters more than ever.

Recorded live at the IIBEC Metro New York Chapter’s Building Smarter with AI conference.

🎧 Full episode drops Tuesday, May 5th, 2026.

Your AI better be able to explain itself in a deposition.

Not in a demo.

Not in a sales deck.

In a deposition.

The demo is easy.

The subpoena is where the system gets tested.

AEC is a long-tail liability business.

Something you stamped in 2024 can become a lawsuit in 2031.

Seven years later, your lawyer is not going to ask:

“Did the AI seem smart?”

They are going to ask:

“Why did you specify it this way?”

And the answer better not be:

“I think someone on the team remembered seeing that in an email.”

Today, most engineering firms defend decisions by digging through old PDFs, emails, RFIs, meeting notes, specs, code comments, and half-remembered conversations.

Then a grey-haired principal tries to reconstruct the logic under oath.

Terrible system.

Graph RAG changes the game for engineering firms, but not for the reason most people think.

Everyone talks about better search.

Fine.

Search is useful.

But the real value is the evidence trail.

When the system says:

“This detail applies to this project.”

It should also be able to show:

The spec section.
The code reference.
The AHJ ruling.
The RFI response.
The submittal comment.
The prior project precedent.
The internal standard.
The person who approved the exception.

Not vibes.

Not “the model said so.”

A defensible chain of reasoning.

That matters in MEP.

We do not just need AI that can answer questions.

We need AI that can prove why the answer was allowed.

Why this equipment was selected.
Why this clearance was acceptable.
Why this load assumption was used.
Why this exception was made.
Why this note ended up on the drawing.

The firms that figure this out will not just move faster.

They will reduce risk.

They will train younger engineers better.

They will stop losing institutional knowledge every time someone retires.

They will stop treating project memory like a scavenger hunt.

Graph RAG is usually sold as a knowledge management tool.

In engineering, it is also a litigation defense file.

Build the system so it can answer the lawyer seven years from now.

Not just the PM this afternoon.

Disclaimer: I’m not a lawyer. Please do not treat this as legal advice.

I’m using litigation risk as the thought experiment.

The point is simple:

If AI is going to influence engineering decisions, the system better preserve the evidence trail behind those decisions.

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York, hosts Kenneth Shultz, Engineering Director at PermitZIP, and Carter Huddleston, Electrical Principal Engineer at PermitZIP, sit down with Spiro Markatos, President at Skyline Restoration Inc.

This episode dives deep into the hidden world of facade restoration, an industry responsible for maintaining some of the most iconic and historic buildings in cities like New York. Spiro shares firsthand insights from decades in exterior restoration, including working on nationally recognized landmarks and navigating the risks that come with repairing aging structures at extreme heights.

The conversation explores the origins of modern facade safety laws, including how real-world tragedies led to regulatory changes that still shape building maintenance today. Spiro explains how restoration companies calculate risk, manage complex projects, and coordinate across multiple trades to keep buildings safe and operational.

Beyond construction practices, the discussion touches on emerging technology in the field, including how AI is beginning to support quantity takeoffs, submittal generation, and workforce tracking. The hosts and guest also explore the growing issue of fraudulent claims in construction, an expensive and widespread problem that impacts insurance costs, project planning, and industry sustainability.

From skateboarding down the ramps of the Guggenheim during late-night restoration work to overseeing large-scale facade rehabilitation projects, this episode highlights the technical, legal, and human challenges behind maintaining the buildings we rely on every day.

Practical, candid, and grounded in real-world experience, this episode offers valuable insight into the people and processes responsible for keeping cities safe, functional, and standing strong.

Keywords

Facade restoration, building envelope, construction safety, historic restoration, exterior restoration, rope access, high-rise maintenance, construction technology, AI in construction, facade inspection laws, urban infrastructure, structural maintenance, waterproofing systems, restoration contractors, construction fraud prevention, skyline restoration, building safety compliance, historic landmark repair, urban building maintenance

Takeaways

• Facade restoration plays a critical role in preventing dangerous structural failures in aging buildings.

• Modern facade safety laws were created in response to real-world tragedies involving falling building materials.

• Historic restoration requires specialized expertise and careful coordination between engineers, contractors, and safety professionals.

• Restoration work often involves high-risk environments such as rope-access repairs and high-rise scaffolding systems.

• AI tools are beginning to support construction workflows, especially for estimating, documentation, and safety tracking.

• Fraudulent injury claims are a major cost driver in the construction industry, impacting insurance rates and project economics.

• Collaboration between design professionals and contractors is essential to ensure projects are both buildable and safe.

Chapters

1. Welcome and Guest Introduction

2. Meet Spiro Markatos: Restoration Industry Leader

3. Introduction to Skyline Restoration Inc.

4. Working on Historic and Iconic Buildings

5. The Reality of High-Rise Restoration Work

6. How Facade Safety Laws Were Created

7. Understanding Building Envelope Restoration

8. Design-Build Collaboration in Construction

9. Estimating Risk and Pricing Restoration Projects

10. AI Applications in Construction Workflows

11. Technology for Worker Tracking and Safety

12. The Growing Problem of Construction Fraud

13. Lessons from Decades in the Restoration Industry

14. Final Thoughts on Keeping Cities Safe

Where to Find Spiro Markatos

Skyline Restoration Inc. · LinkedIn · Instagram

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

From restoring iconic landmarks to understanding how safety laws were shaped by real tragedies, this conversation dives into the risks, responsibilities, and evolving technologies behind exterior restoration work. The episode also touches on workforce safety, fraud challenges in construction, and how AI is beginning to support field operations.

Season 4 was recorded live at the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York.

🎧 Full Episode releases Tuesday, April 28th, 2026.

Every client email is not just an email.

Sometimes it is a change order wearing casual clothes.

Construction people know this.

One sentence can move a deadline.

One “quick question” can reopen a design decision.

One missing drawing can force a full reassessment.

One new piece of information can blow up the calendar.

But somehow the industry still treats email like it is free.

It is not.

Every time a client hits send, somebody has to read it, interpret it, decide if it changes the scope, figure out who owns it, check the contract, check the assumptions, check the exclusions, maybe call the client, maybe document the call, maybe price the work, maybe move the schedule, maybe explain why the “small ask” is not small.

Somebody pays for that time. Right now, too often, it is the engineering firm.

Most firms do not have a system for this.

They have inboxes.

They have memory.

They have hallway conversations.

They have a project manager who “knows what’s going on” until they are sick, underwater, distracted, or gone.

Then everyone acts surprised when responsiveness falls apart.

Maybe the team is not lazy.

Maybe the request is loaded.

Maybe nobody wants to touch it because nobody knows:

Is this in scope?
Is this billable?
Is this urgent?
Is this a client-created problem?
Is this going to wreck the schedule?
Is this worth interrupting design work?

That hesitation is where profit goes to die.

We have been building around a simple idea:

Treat inbound client communication like operational data.

Email comes in.

The system checks the contract, assumptions, exclusions, project context, and prior communication.

It flags whether the request looks in scope or out of scope.

It gives the team enough context to call immediately.

The call gets recorded, transcribed, attached to the project, and turned into next steps.

If it needs a work order, create one.

If it affects delivery, say so.

If the client keeps sending new information after the work is scheduled, the schedule moves.

Fine. That is reality.

Good clients organize their thoughts.

Good clients send complete information.

Good clients understand that every new input has a cost.

The industry already understands this.

They may not call it rate limiting.

They call it a later delivery date.

Same idea.

Send clean information, get cleaner execution.

Send chaos, get delay.

AI will not fix bad client behavior.

But it can finally make the cost visible.

Price the interruption.

Document the call.

Protect the calendar.

Stop pretending the inbox is free.

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference in New York, hosts Kenneth Shultz, Engineering Director at PermitZIP, and Carter Huddleston, Electrical Principal Engineer at PermitZIP, sit down with Eugene Gurevich, Senior Structural Engineer and Construction Phase Director at Rand Engineering & Architecture.

The conversation dives into one of the most pressing questions facing engineering firms today: what happens when AI tools gain access to proprietary drawings, reports, and internal company knowledge? Eugene shares real-world concerns about protecting intellectual property while still leveraging the massive efficiency gains AI can provide.

Together, they explore the technical and philosophical implications of integrating AI into engineering workflows, from prompt injection risks and data privacy tradeoffs to the rise of local AI models designed to protect sensitive information. The group also examines how licensing laws may keep engineers legally responsible in an increasingly automated world, even as AI systems handle more design and coordination tasks.

Beyond AI, the discussion expands into broader industry shifts, how engineering business models could evolve, whether intellectual property will retain its value, and what lessons the music industry’s transition to digital distribution can teach the design and construction world.

The episode also highlights Eugene’s unique dual perspective as both a licensed structural engineer and architect, including his work performing high-rise inspections using rope access systems, sometimes hundreds of feet above ground level.

Thought-provoking, technical, and forward-looking, this episode offers a candid look at how engineers must adapt to protect their knowledge, maintain responsibility, and navigate the rapid evolution of AI-powered design workflows.

Keywords

Artificial intelligence, AI security, intellectual property, AI in engineering, data privacy, prompt injection, engineering workflows, digital transformation, construction technology, structural engineering, rope access inspection, building inspections, engineering responsibility, AI risk management, Rand Engineering & Architecture, PermitZIP, IIBEC conference, local AI models, engineering automation

Takeaways

• AI tools can unlock massive productivity gains—but they also introduce new risks around intellectual property exposure.

• Combining private data, internet access, and external inputs creates security vulnerabilities such as prompt injection risks.

• Local AI models may become a key solution for protecting sensitive engineering data.

• Engineers will likely remain legally responsible for decisions—even as AI automates more workflows.

• Business models in engineering may shift, with value moving from drawings to real-time decision support.

• Intellectual property may become harder to protect as digital tools accelerate data sharing and duplication.

• Real-time feedback from AI can significantly improve decision validation and reduce long-term design risk.

Chapters

1. Welcome and Guest Introduction

2. Meet Eugene Gurevich: Structural Engineer and Architect

3. Engineering Hierarchies and the “Pencil Tip” Concept

4. AI Adoption Challenges in Engineering Firms

5. Understanding Prompt Injection and Data Security Risks

6. Protecting Intellectual Property in AI Workflows

7. Local AI Models vs Cloud-Based Systems

8. The Future of Engineering Responsibility

9. Business Model Shifts in Design and Construction

10. Lessons from the Music Industry’s Digital Transformation

11. High-Rise Rope Access Inspections and Real-World Risks

12. Final Thoughts on the Future of Engineering in an AI Era

Where to Find Eugene Gurevich

Rand Engineering & Architecture · LinkedIn

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

In this Season 4 Episode 7 of The Blueprint Tour, hosts Kenneth Shultz and Carter Huddleston sit down with Eugene Gurevich, Senior Structural Engineer & Construction Phase Director at Rand Engineering & Architecture, to explore one of the most urgent questions facing the industry: how safe is your intellectual property in an AI-driven world?

Recorded live at the IIBEC Metro New York Chapter’s Building Smarter with AI conference, this episode dives into AI security risks, the future of engineering responsibility, and how rapidly evolving technology may reshape ownership, liability, and professional workflows.

🎬 Full episode releases Tuesday, April 14th 2026.

In this live-recorded episode of The Blueprint Tour from the IIBEC Metro New York Chapter’s Building Smarter with AI conference, hosts Kenneth Shultz (Engineering Director at PermitZIP) and Carter Huddleston (Electrical Principal Engineer at PermitZIP) sit down with Nicholas Ceme, Business Development Engineer at Peikko North America.

With a background in structural engineering and a transition into technical sales, Nicholas shares how he’s leveraging AI to solve a problem every professional faces: too many leads, not enough time. He breaks down how he’s building Python-based tools that analyze large volumes of contacts, prioritize high-value opportunities, and automate follow-up workflows.

The conversation explores the real-world applications of AI in engineering and business development, from lead intelligence and data synthesis to prompt engineering and workflow automation. The trio also dives into deeper topics, including how AI is reshaping hiring dynamics for junior engineers, the rise of engineers building their own AI systems, and the growing importance of privacy, local AI models, and data control.

Candid, technical, and forward-looking, this episode offers a practical look at how AI is moving beyond theory, into the daily decision-making processes that drive modern engineering businesses.

Keywords

Artificial intelligence, AI in engineering, lead generation, sales automation, business development, workflow automation, prompt engineering, Python automation, structural engineering, Peikko North America, Nicholas Ceme, PermitZIP, IIBEC conference, AI tools, data analytics, engineering workflows, local AI models, future of work

Takeaways

• AI can analyze and prioritize leads, helping professionals focus on the highest-value opportunities.

• Engineers are increasingly building their own AI tools using Python and automation frameworks.

• AI is more effective in workflow optimization and communication than in full design replacement, at least for now.

• Hiring dynamics are shifting, with AI increasing the productivity of senior engineers and reducing reliance on junior roles.

• Prompt engineering and structured context significantly improve AI output quality.

• Privacy concerns are real, local AI models and data anonymization are becoming critical considerations.

• AI is evolving from a productivity tool into a decision-making layer across engineering and business development.

Where to Find Nicholas Ceme, PE

LinkedIn · Peikko North America

Where to Find The Blueprint Tour

YouTube · TikTok · TheBPTour.com
Kenneth Shultz (Host) · Carter Huddleston (Host)

In this teaser for Season 4, Episode 6 of The Blueprint Tour, Nicholas Ceme shares how he’s building AI-powered workflows to analyze large volumes of contacts, prioritize leads, and improve decision-making. The conversation also explores how engineers are beginning to build their own AI tools, the shift in hiring dynamics as automation increases efficiency, and the growing importance of privacy and local AI models.

The full episode drops April 7th, 2026.