Skills, Projects, GPTs, Agents: A Plain-English Map for the Built Environment

There is a moment, somewhere in most conversations I have about AI on a project, where the words start doing more harm than good. Someone mentions a "custom GPT", someone else hears "agent", a third person assumes both mean the same thing as the "skill" they read about last week, and within ninety seconds the room has quietly agreed to be confused together. The technology is not the problem. The vocabulary is.

So let me separate the five or six terms that cause the most trouble, and ground each one where we actually work: cost reports, programmes, RFIs, risk registers and the daily grind of getting a building delivered. The definitions are simple once they are pulled apart. The value, for our industry, is in knowing which tool fits which job.

A skill is a reusable set of instructions, and the easiest way to picture it is a recipe. A recipe does not cook anything by itself. It is the written method that lets any cook turn out the same dish to the same standard every time. A skill does the same job for AI. You write down, once, how you want a task done, the format, the rules, the things to avoid, and you save it, so you get the same result on every run instead of a slightly different answer each time. One small caveat is worth knowing. Left to itself the AI is a little unpredictable, so for the parts that have to be exact, the figures, the rounding, a good skill can call on a short piece of code to do that bit identically every time. It is the kitchen reaching for the scales instead of guessing by eye.

For us, this is the difference between asking for "a cost report" and having a Cost Report skill that already knows your headings, your rounding conventions, your anticipated-final-cost wording and the sentence you always forget to include about movement since last issue. Other natural candidates are a take-off schedule formatted to NRM 2, a risk register that scores consistently every time, or an RFI response that follows your house style. You build it once and you stop re-explaining yourself.

A project, in the sense ChatGPT and the others now use the word, is simply an organised workspace. It is where you keep the context for an ongoing piece of work: the documents, the previous conversations, the background the AI should always have to hand. It does not do anything on its own. It is the desk, not the person sitting at it.

The useful rule is this: reach for a project when you have a body of work that will run for weeks or months and you are tired of pasting the same background in every time. A live scheme is the obvious case. Drop the contract, the programme and the cost plan into one project and every question you ask inherits that context automatically.

This is where the branding causes most of the confusion. A Custom GPT (OpenAI) and a Gem (Google Gemini) are, for practical purposes, the same thing: a reusable assistant you set up once. You give it a standing brief, a job and a way of behaving, and it holds that role every time you open it. You can also give it its own reference documents to work from. If the model is the chef, this is the specialist you keep on the payroll rather than the temp you re-brief each morning.

A Tender Analysis assistant that always normalises bids the same way, or a Variation Assessor that knows the difference between a JCT valuation and an NEC compensation event, is a sensible custom GPT. The distinction worth holding onto is that a skill is a single repeatable task, whereas a custom assistant is a persistent role that may call on several skills and carry its own reference material. One is a verb, the other is a job title.

This is the term that carries the most weight, and the one most often muddled with a custom GPT. The difference is simple. A custom GPT answers you; an agent goes and does the thing. Ask a custom GPT to help with your cost report and it will talk you through it. Give the same job to an agent and it actually opens the file, updates the figures and hands you the finished draft. What sets an agent apart is autonomy: you give it a goal, it works out the steps itself, it uses whatever tools it needs, and it keeps going until the job is done. To close the kitchen picture, a skill is the recipe, a custom GPT is the hired specialist, and an agent is the head chef who runs the whole service. Handed "dinner for forty at eight", it plans, preps, cooks and plates without you calling each step.

That phrase, keeps going until the job is done, is worth pausing on, because it is how an agent actually works under the bonnet. You set a goal and the agent runs in a loop: it takes a step, checks how it went, adjusts, and goes round again, repeating until it has either reached the goal or hit a limit you have set. Some tools make this explicit with a goal command, where you simply state the outcome you want in plain words, say "reconcile this month's valuation against the application and flag anything that does not match", and let the agent loop away at it. It is a powerful way to work, and it is exactly why the guardrails in the next section matter: a loop with no boundary is a loop that can wander.

And here is the part that tends to get lost. An agent does not have to be a sprawl of bespoke, single-purpose bots wired together. It can be one thing. A single, capable, general-purpose agent that you simply hand different jobs to is very often the better answer. Claude's Cowork is a fair example: one agent you point at a cost report in the morning and a research summary in the afternoon, rather than a different contraption built for each. The instinct to spin up a separate agent for every task is usually just the instinct to overbuild.

The jobs that suit an agent are the ones you would happily hand to a diligent junior and check afterwards: chasing outstanding actions, sweeping a document register for the latest revisions, or pulling a progress report together from the month's data. The power is obvious. So is the reason for care, which I come to next.

Two supporting terms round out the picture. A plugin is a bundle, a way of packaging skills, assistants and tools together so they travel as one installable unit. A connector is the link between the AI and another system, the thing that lets it reach into your email, your drive, your scheduling tool or your common data environment. Connectors are what turn a clever writer into a useful colleague, because they give it access to the real project information rather than whatever you happened to paste in.

They are also where the risk lives. Once an agent can act, and a connector gives it the keys to live systems, permissions stop being an IT footnote and become a project-controls decision. The sensible discipline is straightforward: grant the narrowest access that does the job, keep a human in the loop on anything consequential, and put a hard stop around any agent that runs in a loop so it cannot quietly run away with itself. On a live scheme, an agent with write access to the wrong register is not a productivity gain. It is a defect waiting to happen.

If you remember nothing else, remember the shape of the decision. Use a skill when you keep doing the same task and want the same result each time. Use a project when you need a home for an ongoing body of work and its context. Use a custom GPT or Gem when you want a standing specialist for a recurring role. Use an agent when you want the work done, not just drafted, and you have thought through what it is allowed to touch.

My honest steer for most people in the industry is to start at the small end. Build one good skill for a task you do every week, feel the benefit of an output that no longer drifts, and let your appetite for agents grow from there. The failure mode to avoid is not caution; it is sprawl. Most of us have lived through the dashboard graveyard, the analytics screens that were a thrill to build and then quietly never opened again. Agents can go exactly the same way: a drawer full of half-finished assistants, each clever, none used. One agent you genuinely reach for every day is worth more than ten you admired once and abandoned. The firms that win with this will not be the ones who adopted the most advanced thing first. They will be the ones who understood the difference between the tools clearly enough to put the right one in the right place, and were disciplined enough to keep only what earns its place. The vocabulary, it turns out, was the bottleneck all along.