You did not need another contract; you needed the card
The laminated card of the office’s standard procedure: the company’s standardized instruction that anyone applies without hiring another person. It sticks to whoever is already working. It does not open a new head or a new desk. In the harness, that is a skill (a packaged ability or procedure).
If you only have three minutes: skill = laminated standard-procedure card that adheres to whoever is already working; agent = an engineer sent to another office with a clean folder. The skill does not open new context.
This note is part of the series on the AI harness for civil engineering.
First the site scene, then the Anglicism
Think of the laminated sheet next to the lab’s 3D printer, or the card for “how to close the survey day.”
Path one: every time someone uses the AI, they rewrite the same eight rules in the prompt. By the third time they have been forgotten. The history diluted them. There was no procedure; there was short-term memory dressed up as culture.
Path two: those rules live as a skill. Whoever is already at the desk can apply them without inventing them again. The card sticks. It does not open a new chair. It does not open another head.
That is the fixed picture: the laminated card of how we do it here (sometimes called an SOP — standard procedure; you do not need to memorise the acronym). Anyone applies it. It sticks to whoever is already working. It does not open a new head or a new context.
What a skill is: the company’s standardized instruction
A skill, in practical AEC, is a company standardized instruction: the team’s know-how packaged so the harness can re-inject it. It is not a digital employee. It is the card that says how we work here.
A good skill says things like:
- Which units we use (kN and m; do not mix tonf halfway through the report).
- In what format to present results (table with IDs, units visible, assumptions separate).
- Which book, code, or standard to rely on (cited edition; not “what the model remembers”).
- How to name layers, loads, cases, or files (the office convention, not the chat’s inventiveness).
- When to stop and ask (the model is missing, the code edition is missing, the tool failed: do not fill the gap).
None of those lines is magic. They are the office’s culture written down so it does not depend on who is in the chat today. The harness can attach that procedure to a session or mission already open. It is not the model. It is not the solver. It is not the signature.
It adheres
It goes with whoever is already working. Like the card in the plant engineer’s pocket.
It does not open new context
The agent occupies new context: a clean folder, a new desk — often off the main harness thread. The skill does not. It orders the window you already have.
It is procedure, not personality
A good skill can be audited: steps, inputs, outputs, what is forbidden. A “charismatic agent” without a card is theatre. A card with nobody to execute it is paper.
Card examples that actually feel like AEC
Desktop demo — not a client case:
Units and presentation. “Always kN and m. Every table carries the unit in the header. If the file comes in another unit, convert it and say so. Do not invent IDs. If the model is not open, stop and ask.”
Code and source. “Rely on the code edition that is in the project folder. Cite article or section. If the edition is not there, do not fill the gap: stop and ask for the correct PDF.”
Preflight before the solve. “Before calling the engine: selection not empty, reasonable bounds, case units. If preflight fails, do not burn the solve. Log the error. Ask.”
Other typical cards: load-naming convention; template for a traceable report; when to ask for approval before touching the official model. The card does not open the office; the agent does.
Skill versus agent: same office, different pieces
Agent: you send an engineer to another office with a clean folder. Their own mission. A new desk. They come back with a deliverable.
Skill: you give whoever is already there — or the agent you already sent — the laminated card. The company’s standardized instruction. You do not hire anyone else. You do not open a new head.
If you need an isolated mission — review only level 3 without the budget chat — you open an agent. You can stick skills on it: the card travels in the clean folder, but the new office was opened by the agent, not by the card.
Why AEC confuses skill with “another digital intern”
Because marketing sells everything as an agent. And because the real pain is “nobody follows the procedure.”
Hiring heads (agents) without cards (skills) multiplies offices that improvise. Sticking on cards without a harness is having standard procedures nobody loads. The healthy order:
- Write the procedure as an auditable skill — a company standardized instruction.
- Attach it to sessions or missions that already exist.
- Open an agent only when the mission requires new context.
- Keep the engine (OpenSees, CalculiX, IfcOpenShell…) as the one that calculates.
- You sign.
The belief to break: “if the model is good, I do not need a standard procedure.” The other way around. The more capable the model, the more expensive it is to leave the procedure only in one person’s head or in a chat that gets compacted.
What a skill is not
First. “You upload a PDF of the code, you already have a skill.” You have a file. A skill is the procedure for how to use it: what to cite, when to stop.
Second. “The skill replaces the engineer.” No. It replaces chaotic rewriting of the same checklist. Judgement and signature remain human.
Third. “Skill = tiny agent.” No. The difference is context: the skill does not open a new head; the agent does occupy new context.
Fourth. “With a skill I no longer need a harness.” The harness is the workshop. The card lives there. Without a workshop, the card is one more paragraph in the prompt — and by the third question it dilutes.
For the map of the harness, read what an AI harness is. If what you are missing is another office, not another card, go back to the agent’s role.
Evaluation and limitations
Treat the notes below as evaluation context, not as a verified calculation or code check.
Treat the skill as a short, versioned procedure. If the applicable code changes, change the card — not an old thread.