The jargon is complicated. The capabilities underneath are simple.

Prompt engineering

Shaping a single instruction so a model does what you want. The task, the format, the examples, the constraints.

It is the most familiar of the seven and the easiest to underestimate. Writing one good instruction is simple to demonstrate and harder to do consistently, because tasks vary, models change, and the approach that worked well last quarter may not be the strongest one now. It behaves like a practised skill rather than a one off lesson. People get better by writing, seeing what comes back, adjusting and going again.

There is a level beyond everyday competence too, where you compare versions of a prompt and measure which one actually performs better on the work that matters. Fewer teams reach that point, and the ones that do get noticeably more out of the same tools.

Teach it, then keep practising. This one is for everyone, and it builds little and often. Around forty minutes of deliberate practice a few times a week, over a couple of weeks, gets most people to a reasonable standard. Use real tasks from their own work rather than exercises, because the competence comes from the repetition.

Read the full piece: Prompt Engineering: how prompting still impacts results.

Skill engineering

A skill is knowledge plus tools. You take the prompting, wrap it with the information it needs and the tools it can reach, and package the result so it delivers a meaningful unit of work the same way every time, for anyone who runs it.

This is the step most organisations skip, and it is where things start to compound. Your marketing manager stops rebuilding the same brief every Tuesday afternoon and starts running it.

It is also where the ground shifts. One person can build a skill for themselves. The moment it is meant to be shared it needs current data, real system access, permissions and a single live version. At that point it is a small piece of software.

Teach the concept, then scale it with tooling. Your people should build for themselves, starting with whoever repeats the same request most often. The moment a second person needs it, or it touches live data, you need one live version, controlled access and a record of what changed. That is a tooling problem rather than a training one.

Read the full piece: Skill Engineering: getting results on real tasks.

Context engineering

This one deserves most of your attention, and the name is doing it no favours.

Strip the label away and the idea is straightforward. The quality of what comes out depends almost entirely on the quality and relevance of what goes in. Not the cleverness of the request. The information available at the moment of the decision.

Which should sound familiar, because it is data management. Every principle your data team has argued for over the last decade now decides whether AI works in your department.

Teach it, and put accountability behind it. Someone needs to be answerable for whether the information going in is accurate and current, and that tends to work best inside how you already manage data rather than bolted alongside it. A good place to start is asking what your team quietly re-checks by hand before they trust an answer.

Read the full piece: Context Engineering: why the right information determines the outcome.

Harness engineering

Your most capable people will find value in AI whatever you do. A harness is what extends that to everyone else.

It is everything wrapping the work that makes a good outcome the default rather than the reward for being careful. What the system can reach, which tools are available, what gets checked before anything is sent or paid, and where it stops and asks a person. A decent model with a well built harness will generally beat a strong model with a poor one.

Buy it, specify it yourself. Someone else builds it, your team writes the rules. Start with the people closest to the risk and ask them one question: what would have to be checked before this went out without you watching. Their answer is the spec.

Read the full piece: Harness Engineering: making good results the default for everyone.

Process engineering

The first four are about how a person works with AI. This one is about the shape of the job they are doing, and it is where the largest gains tend to sit.

There are two different questions available here, and they lead to different places. Automating a process makes the current shape faster. Reimagining it asks whether that shape should still exist. The second usually turns up more, because processes accumulate steps that compensate for constraints which have since gone away.

So the more useful opening question is not “what can we automate?” It is “if we designed this today, knowing what is now possible, what would it look like?”

Build the competency in house, buy the accelerant. The judgement is yours and stays yours, because the people doing the work are the ones who know which steps carry real thinking and which are habit. What you buy is pace: a method, someone to run the sessions, and the build capacity to act on what comes out. A good place to start is the process everyone complains about.

Read the full piece: Process Engineering: rethinking the work, not just speeding it up.

Loop engineering

A loop is how a piece of work runs to completion on its own: set a goal, act, check what happened, adjust, go again, until it is finished and verified. This is how a good deal of software now gets delivered, including ours.

The important thing is that loops are no longer only an engineering concern. Plenty of useful ones are within reach of a capable person in your team: a task that runs every morning, tidies its own output and flags anything odd. Those are worth encouraging, because that is where a lot of the everyday value sits.

What separates a good loop from an expensive one is stopping. A system that cannot tell when it is finished, or cannot show the work is right, is not a productivity gain. It is an overnight bill. That holds whether the loop was built by your operations manager or by an engineering team.

Build the simple ones, buy the hard ones. This is for your capable, curious people, not only engineers. Start with a task someone does every morning on their own data. When a loop begins touching real systems, money or customers, bring in people who do this for a living and ask how they verify the work.

Read the full piece: Loop Engineering: how complex builds actually get delivered.

Graph engineering

The same territory, further along. Instead of one agent working through a task, the work is given an explicit shape: named steps, defined routes between them, work running in parallel where it can, and points where a person approves before anything continues.

One firewall, because this term collides with something your data team already does. It has nothing to do with knowledge graphs, Neo4j or GraphRAG. Those structure what a system knows. This structures how the work runs.

What the structure buys is control and auditability. When something goes wrong you can point at the step where it went wrong, which for regulated work is often worth more than the speed.

Buy it, when the work earns it. There is nothing to start yourself here, and that is the honest answer. Knowing this level exists lets you ask a build partner which level of structure a piece of work actually warrants, rather than paying for structure you do not need.

Read the full piece: Graph Engineering: structure and control for bigger outcomes.

Three you teach. Two you buy. One you start yourself and buy help with as it grows. And one where the capability itself is the thing worth owning.

Hiring did not come up once, which is worth a moment. It is not that these capabilities matter too little to hire for. It is that they are the wrong level to hire at. Ask for context engineering experience in a job advert and you will mostly get people who know the phrase. What tends to predict whether someone gets results is a track record of learning, clear thinking about information, and the ability to look honestly at how work is done. Those sit underneath all seven rather than inside any one of them, and we have written about them separately in the skills that make or break AI impact.

If you think you need help building these capabilities, applying them to the problems that matter, and getting real value from AI in your business, get in touch. We are always happy to talk about how we work with our clients to get there.