The harness: the model is only the engine

You have probably already heard someone say:

« Our product uses GPT. »

Or Claude. Or Mistral. Or Qwen.

Fine.

But that tells you very little about what the product actually does.

Two applications can use exactly the same model and still have radically different capabilities, performance and even behaviour.

Why?

Because between your application and the model sits a layer we talk about far less: the harness.

And you are about to see that it is probably one of the most important layers of modern AI.

Back to our document

In the first article of this series, we took an extremely simple example: you upload a big document and you ask:

« Summarise this in 5 bullet points. »

We saw that before your document even reaches the model, ordinary software has work to do:

• ▸extract the text from the PDF,
• ▸split the document up,
• ▸search for the interesting passages,
• ▸build the prompt,
• ▸send the information to the model,
• ▸collect its answer,
• ▸possibly ask it to start again.

Back then, I simply called that the software layer.

Today, a term is starting to take hold for a large part of that machinery: the harness.

So what is a harness?

To put it very simply:

« The model thinks. The harness organises its work. »

Picture an engine sitting in the middle of your garage.

Even at 500 horsepower, you will not get very far with it.

It needs:

• ▸a steering wheel,
• ▸a gearbox,
• ▸wheels,
• ▸brakes,
• ▸sensors,
• ▸a fuel tank,
• ▸a dashboard,
• ▸and a driver, or a system able to decide where to go.

For an AI model, it is exactly the same.

The model may be extremely capable, but it does not spontaneously know your internal documents, it has no access to your CRM, it does not necessarily know when to run a web search, and it does not magically decide how to break a complex task into ten steps.

All of that has to be organised by software.

That is the harness.

And that changes a lot about how we look at AI.

A model on its own is fairly limited

Take a classic LLM.

You give it text. It gives you text.

That is already impressive, obviously.

But now imagine you ask it:

« Tell me how much we invoiced client Dupont this year and compare it with last year. »

Your model probably has no idea who Dupont is.

It does not know your invoicing software.

It does not hold the necessary access rights.

It does not know which database to query.

And above all, you probably do not want to hand it your entire accounting data on every question.

So you are going to have to build it an environment. For example:

• 01understand that the question is about invoicing;
• 02identify the client in your CRM;
• 03call your accounting tool;
• 04retrieve only the data that is needed;
• 05possibly run a calculation;
• 06pass the results to the model;
• 07check that the answer respects the expected format;
• 08display the result to the user.

The model only did part of the work.

Everything else belongs to the harness.

First job: give it the right context

You have probably heard a great deal about prompt engineering these past few years. How do you write the best prompt?

• ▸"You are a chartered accountant with 25 years of experience…"
• ▸"Answer step by step…"
• ▸"If you do not know the answer, say so…"

It is useful.

But we are starting to move from prompt engineering to something much broader: context engineering.

The question becomes less:

« How should I phrase my sentence? »

and more:

« What information does the model actually need to carry out this task? »

Because filling its context window with 300 useless pages is rarely a good idea.

So the harness can select the relevant pieces:

• ▸the company's instructions;
• ▸the relevant history of the conversation;
• ▸certain documents;
• ▸the results of a search;
• ▸a tool's responses;
• ▸the work done in the previous steps.

And pass the model only what it needs at that precise moment.

This is where our old friend RAG comes back in. Instead of handing the model your entire documentation: question → search for the interesting passages → model → answer.

The harness orchestrates the search.

The model analyses the information it is handed.

Second job: give the AI tools

This is where things get far more interesting.

An LLM can now decide:

« To answer this question, I need to use that tool. »

That could be:

• ▸running a web search;
• ▸querying a database;
• ▸reading a document;
• ▸sending an email;
• ▸checking a calendar;
• ▸executing code;
• ▸calling your CRM;
• ▸launching another internal piece of software.

You are then starting to get what is commonly called an agent.

Take a very simple example. You say:

« Set up a meeting with Paul next week. »

The model can understand your intent.

But the harness has to let it:

• 01identify Paul;
• 02check your calendar;
• 03retrieve the free slots;
• 04possibly check Paul's calendar;
• 05propose a time;
• 06wait for your approval;
• 07create the event.

And above all… you have to stop the AI from doing anything stupid.

You probably want to let your agent read your calendar. You may be less keen on letting it delete every appointment in it.

That too is the job of this software layer.

MCP: the USB port of our agents?

Obviously, if every developer has to build a different connection for every tool, we will quickly recreate the wonderful world of IT integrations where everyone has their own API, their own format and their own 453-page documentation.

That is largely why protocols like MCP — Model Context Protocol appeared.

The idea is fairly simple: standardise the way an agent can discover and use tools or resources.

That is also why, at SOCLE, we chose to build our agents around this kind of protocol: to avoid, as far as possible, recreating a bespoke integration for every new capability.

Third job: decide what to do next

Giving the model a tool is one thing.

You still have to decide when to use it.

This is where what is generally called the agentic loop comes in. To simplify enormously: observe → think → act → observe the result → start again.

Take looking for a restaurant. Your agent could:

• 01understand that you are looking for an Italian restaurant;
• 02use a search tool;
• 03get five results;
• 04notice that you asked for one open tonight;
• 05check the opening hours;
• 06rule out the ones that are closed;
• 07look at their availability;
• 08present you with the three best options.

So we no longer necessarily do user → model → answer, but user → model → tool → model → tool → model → answer.

And that can carry on for dozens of steps.

The harness is the machinery that keeps this loop alive.

• ▸It passes the results along.
• ▸It holds the state.
• ▸It controls the number of iterations.
• ▸It detects errors.
• ▸It can ask the AI to change strategy.
• ▸And above all, it decides when it is time to stop.

Because an agent that thinks forever is philosophically fascinating, but economically rather catastrophic.

And what if one model is not enough?

We can go further still.

Why use the same model for absolutely every task?

Take a recorded meeting. We need to:

• ▸understand an audio file;
• ▸tell the speakers apart;
• ▸transcribe what they say;
• ▸correct certain errors;
• ▸understand the business context;
• ▸possibly generate a summary.

One enormous model could theoretically try to do all of it. But that is not necessarily the best solution.

At SOCLE, for instance, our transcription system combines several treatments: an agent specialised in speech recognition produces the transcript, then an LLM agent can apply a contextual correction taking the speakers and the business information into account.

Each technology is used where it is relevant.

That is exactly the point of thinking in terms of an ecosystem of agents rather than a single model.

Multi-agent

And of course, because we always love to complicate things as soon as they start working, we can give our harness several agents.

Picture a team in a company. You have:

• ▸a lawyer;
• ▸a developer;
• ▸a salesperson;
• ▸an accountant.

You could hire one extremely clever person and ask them to become an expert in all four fields. Or use several specialists and let them collaborate.

In a multi-agent system, the principle is similar. One agent can receive the request and pass it on to another, more specialised agent.

The harness then becomes a kind of conductor.

• ▸Who works?
• ▸In what order?
• ▸What information has to be passed from one agent to another?
• ▸Should they work in parallel?
• ▸Who checks the result?

At SOCLE, we use the A2A — Agent-to-Agent protocol in particular to structure these exchanges between agents.

The goal stays the same: avoiding a world where every new combination means rebuilding your entire product.

Fourth job: pick the right model

And this is where you will understand why, in the previous chapter, I explained that a model is ultimately "just an algorithm".

Your product does not necessarily need to be married to GPT, Claude or Mistral until death do you part.

The harness can act as a layer of abstraction between your application and your models. Imagine:

• ▸a small, fast model to classify a request;
• ▸a code-specialised model to analyse a program;
• ▸a more powerful model for a complex task;
• ▸a multimodal model to understand an image;
• ▸a local model for certain sensitive data.

Your user, meanwhile, has absolutely no need to know they just used four different models. They simply want their problem solved.

And this is something we care about a lot at SOCLE: we do not think an AI product should be built around a model. It should be built around a need.

Models then become resources the system picks according to the task at hand.

The most powerful model is not always the best product

This is perhaps the most important idea in this article.

Imagine two companies using exactly the same model.

Company A

It sends your question straight to the LLM with an enormous 15-page prompt.

Company B

Its harness:

• ▸identifies your intent;
• ▸retrieves only the necessary documents;
• ▸selects the right tools;
• ▸controls their permissions;
• ▸uses a specialised model for a sub-task;
• ▸checks the result;
• ▸asks a human to approve if needed;
• ▸traces every step.

It is also why comparing AI solutions purely by asking "which LLM do they use?" is starting to become an insufficient question.

It is like comparing two cars purely by asking how much horsepower the engine puts out. It matters. But you are forgetting everything around it.

Human-in-the-loop: sometimes the AI should simply ask

Another particularly important element in a harness: knowing when not to act alone.

Imagine an AI used in a legal context. It can:

• ▸transcribe an interview;
• ▸identify the speakers;
• ▸flag an inconsistency;
• ▸propose a correction.

But permanently altering a testimony without human approval would obviously be a very bad idea.

So the harness can introduce control points: AI → proposal → human approval → rest of the processing.

That is what is called human-in-the-loop.

And contrary to some very futuristic visions of AI, it is not necessarily a failure of automation. It is sometimes exactly what makes automation usable.

At one of our clients in the legal field, we use precisely this approach: various steps of the processing can be checked and corrected by the user before approval.

Fifth job: watch what is happening

This is probably one of the least sexy aspects of AI.

And yet, if you want to put a system into production, it becomes indispensable.

Your agent has just produced a bad answer. Why? Was it:

• ▸the model?
• ▸the prompt?
• ▸the document the RAG retrieved?
• ▸a tool's bad response?
• ▸a routing problem?
• ▸an earlier step that got it wrong?
• ▸a piece of information sitting in the memory?
• ▸another agent?

If your system consists solely of question → big black box → answer, good luck.

An industrial harness therefore also has to let you follow how the processing unfolded. At SOCLE, we are specifically working to make the various steps observable.

• ▸Which agent was called?
• ▸Which tool?
• ▸Which document?
• ▸Which model?
• ▸How long did it take?
• ▸In what order?

That lets you understand what your AI is actually doing. But also measure what it costs.

Because an AI that saves you 3 minutes of work while burning €12 of compute on every request may not be the fantastic digital transformation project announced in the slide deck.

And what about security?

As soon as you give an AI tools, the question obviously becomes critical.

A chatbot hallucinating a capital city is annoying. An agent connected to your IT system hallucinating an action is slightly more problematic.

So the harness also has to be able to enforce rules:

• ▸which tools are accessible;
• ▸which actions require approval;
• ▸which data can be passed on;
• ▸how many actions can be carried out;
• ▸which users hold which rights;
• ▸which results have to be checked.

The more the AI becomes able to act, the more important this layer becomes.

The security of an agentic system therefore cannot rest solely on "we politely asked the model in the prompt not to do anything silly."

That would be convenient. But let us not.

So where does the intelligence actually sit?

When ChatGPT appeared, we naturally attributed all the intelligence we were seeing to the model. That was logical.

But as our systems grow more complex, the boundary becomes much blurrier.

Part of the performance comes from the model. Another part comes from:

• ▸the quality of the tools;
• ▸the context it is given;
• ▸the memory;
• ▸the RAG;
• ▸the routing;
• ▸the orchestration;
• ▸the verification loops;
• ▸the other models around it.

The AI system therefore becomes more important than the model alone. And that is probably the most interesting shift we are seeing right now.

We have moved from "which model do you use?" to "what system have you built around your models?"

In short

It brings the model:

• ▸context;
• ▸documents;
• ▸memory;
• ▸tools;
• ▸rules;
• ▸the ability to act;
• ▸other agents;
• ▸control mechanisms;
• ▸observability.

And above all, it turns a plain model call into an actual product.

That is also why, at SOCLE, we work first and foremost on this layer. Our goal is not to create the next general-purpose model: other companies are already spending a few billion on that ;)

Our job is to let companies build usable systems around those models: agents, RAG, MCP-compatible tools, multi-agent ecosystems based on A2A, human control and step-by-step tracking.

The model then becomes an interchangeable brick inside a larger system.

And that leads us naturally to the next chapter. Because this whole fine system — the agents, the tools, the models called one after another — has to run somewhere.

Spoiler: it burns concrete, electricity and silicon.