The more the word “AI” enters the vocabulary, the less it explains. Demystifying begins by separating the layers before discussing the magic.

TL;DR

Artificial intelligence is not a single piece. A model transforms inputs into outputs; an automation follows predefined steps; an agent can choose next steps and use tools within limits; a harness organizes context, memory, skills, sources, permissions, approval points, and validations around all of this. The boundaries are not universal, but the distinction prevents expecting human comprehension from an interface, autonomy from an isolated model, or security from a well-written prompt. The direction remains human. The system serves to transform that direction into execution that is more legible, governed, and verifiable.

“AI did it.”

That sentence might even be correct. Almost always, it is incomplete.

After years of building software and, more recently, orchestrating agents, automations, memory, skills, subagents, tools, permissions, and validations, I treat it as a request for clarification.

Which part of the system did exactly what?

Was it a model generating text? A search retrieving documents? A flow following rules? An agent choosing tools? A traditional program calculating the result? A person approving the action? All of it together?

Calling each of these things “AI” is like calling the engine, transmission, driver, road, and traffic rules “car” and expecting the mechanic to figure out the rest from context.

Sometimes they do.

Sometimes the budget figures out you, too.

Demystifying artificial intelligence is not pretending that everything became simple. It is separating the layers enough to ask better questions. I started taking this distinction more seriously when I realized that a word too broad was hiding completely different decisions: choosing a model, automating a process, delegating actions, or governing an operation are not variations of the same problem.

First: which AI are we talking about?

“Artificial intelligence” is a huge umbrella. It covers very different techniques, systems, and applications: image recognition, prediction, recommendation, planning, language processing, robotics, and much more.

In this text, my focus is on generative systems based on large language models and the agent architectures built around them. I am not saying that all AI works like a chatbot or that every intelligent system uses the same techniques.

The OECD, in explaining the updated definition of an AI system, acknowledges that there is no simple red line separating AI from non-AI. Its definition describes a machine-based system that, from explicit or implicit inputs and objectives, infers how to generate predictions, content, recommendations, or decisions capable of influencing physical or virtual environments.

This formulation is useful for a reason that often disappears in marketing: it speaks of a system, not a magical entity.

And within the system, the model is just one component.

The map on one page

Words vary between companies, articles, and tools. The table below does not intend to settle the terminology; it offers an operational map for this blog.

Layer	What it does	What it does not guarantee
Model	Transforms an input into an output based on learned patterns	Correct source, appropriate objective, durable memory, or access to external systems
Automation	Executes a sequence of steps, rules, and integrations	Judgment on unforeseen situations or responsible decision-making
Agent	Uses a model to choose steps, consult context, and trigger tools within an objective	Unlimited autonomy, reliability, or permission to act on everything
Harness	Organizes environment, context, memory, skills, tools, sources, permissions, checkpoints, and validations	Automatic truth, zero risk, or good human direction

The point is not to memorize the names.

It is to realize that each layer solves a different problem — and creates a different type of risk.

Model: the engine is not the whole operation

A model receives inputs and produces outputs.

In the case of a large language model, this involves learning regularities from large datasets and generating sequences compatible with the received context. The output can be excellent, mediocre, wrong, or fabricated with a fluency that makes the error harder to notice.

The NIST Generative AI Profile uses the term confabulation for false or incorrect outputs presented with confidence. The document explains that generative models approximate statistical distributions of training data and that large language models predict the next token. This can produce correct and consistent content; it can also produce something factually wrong or internally contradictory.

Linguistic plausibility is not proof.

The model is not automatically a database, a search engine, an access policy, a business process, or a source of truth.

It also does not have its own will. When it seems to pursue an objective, it is a combination of training, instructions, context, code, and human choices producing that behavior.

That is why a prompt can improve a response without turning the model into a governed system.

The prompt informs a task. It does not, on its own, create access control, reliable history, human approval, observability, testing, rollback, or accountability.

A powerful engine still needs everything else. The industry took decades to build these layers, as I recounted while tracing the evolution from mainframes to agents.

Automation: when the path can already be drawn

Automation is the execution of a process by rules and integrations.

It can use AI, but it does not need to.

A hypothetical flow can receive a document, validate mandatory fields, consult a registry, record the result, and send a notification. If the steps and relevant exceptions are known, traditional code or a workflow automation tool can solve the problem with more predictability, lower cost, and less room for improvisation.

This is not less modern.

It is engineering choosing the tool proportional to the problem.

Much of what is sold as an “agent” is, in practice, an automation with a model call in the middle. There is nothing wrong with that. The error begins when the flashiest name creates expectations that the architecture does not deliver.

Agent: delegated autonomy, not personality

There is no universal definition of an agent.

An engineering reference from Anthropic distinguishes workflows, in which models and tools follow predefined paths, from agents, in which the model dynamically drives the process and tool use. It is the company’s own taxonomy, not a law of computing, but it helps locate the main shift.

In an agent, the model does not just produce a final answer. It can observe the state, choose a next step, trigger a tool, evaluate the result, and continue until it concludes, fails, or hits a limit.

This does not turn it into a human worker, an emotional partner, or the owner of the decision.

The agent’s autonomy was delegated by someone. Its objective was defined or accepted by someone. Its tools were exposed by someone. Its permissions need to be limited by someone. And its material actions continue to require human and organizational accountability.

The greater the autonomy, the more important it becomes to answer:

• what can the agent see?
• what can it change?
• when does it need to request approval?
• how will its action be recorded?
• which validation separates an attempt from a delivery?
• how to stop or revert when something goes off track?

Subagents do not change this nature. They are a way to divide context, expertise, and review among instances or roles. They do not form a human team inside the machine.

Harness: the system that makes the agent operational

It is in this layer that I focus much of my current work.

A better model helps. But switching models does not, on its own, solve scattered context, contradictory instructions, memory without origin, tools without permission, decisions without an owner, or deliveries without validation.

I use harness to name the system around the agent. Its function can be summarized in three commitments:

• make the context legible, so that rules, sources, history, and objective do not depend on a lost conversation;
• make the action governable, with tools, permissions, approval points, stopping criteria, and defined responsible parties;
• make the result verifiable, with tests, logs, and sufficient evidence to review, correct, or reject the delivery.

Memory, skills, subagents, and tools are ways to implement these commitments. They are not characters: memory is recoverable information; a skill is a reusable procedure; a subagent is another execution with delimited context and function.

An OpenAI report on harness engineering with Codex describes the importance of making context, tools, documentation, and feedback loops legible for agents. It is a specific case from the company, not a universal recipe. The useful distinction is this: model capability and environment quality are different problems.

The operational base I have built can already transform human criteria into reusable, governed, and verifiable execution. It is not a proprietary foundational model; it is an architecture that combines components and work contracts.

The best answer is not the most pleasant one

There is another layer that a technical diagram often hides: the behavior we choose to encourage.

I do not refine my agents to receive more elegant agreement. I want the best verifiable answer that the context and sources allow — including when it points out that my question is poorly formulated, that evidence is missing, or that I am defending a hypothesis too early.

A study on sycophancy in language models found situations where responses aligned with the user’s beliefs were favored even when this competed with correctness. The work does not represent all models and contexts, but it supports an important caution: pleasantness is not a sufficient metric of quality.

That is why my contracts require the agent to expose uncertainty, seek counterpoints, point out blind spots, and ask questions when ambiguity can change the execution.

If it is not yet clear what should be done, I do not want an imperative verb to turn confusion into action.

The direction is mine.

The system’s role is to help make it more explicit, confront it with reality, and execute it within limits.

This criterion is deepened in “The best answer is not the one that pleases me most”.

Why confusion between layers is expensive

When everything receives the same name, different questions seem to have the same answer.

A company might hire a model expecting it to know its processes. It might buy an agent platform when a simple automation would suffice. It might release a critical tool because the chatbot responded well during a demo. It might call a folder of conversations corporate memory. It might treat a prompt as a security policy.

The result is not always a cinematic catastrophe.

Sometimes it is worse: a silent collection of hard-to-audit decisions, fragile integrations, hidden manual work, and confidence that grows faster than evidence.

Separating the layers allows choosing the right control:

• model requires quality evaluation, limits, and behavior monitoring;
• automation requires rules, exception handling, and observability;
• agent requires scope, tools, permissions, and stopping criteria;
• harness requires governance, defined accountability, memory, validation, and continuous maintenance.

There is no architecture that makes risk zero. There is architecture that makes risk more visible, limited, and manageable.

Governance is not a document placed at the end

When a system can influence decisions or act on an operation, governance must be born with the architecture.

The NIST AI Risk Management Framework 1.0 organizes risk management into functions like govern, map, measure, and manage. The framework is voluntary and broad. It does not certify a specific tool, does not guarantee compliance, and does not replace technical, legal, or organizational controls of the context.

Its value for this conversation lies in shifting the question.

Instead of “which AI will we use?”, we start asking:

• which decision or process is at stake?
• who can be affected?
• which data and sources support the output?
• what level of error is tolerable?
• where is human supervision mandatory?
• how to measure behavior and quality after launch?
• who can stop, correct, and answer for the system?

Governance is not the brake applied after acceleration.

It is part of the steering.

When not to use an agent

Demystifying AI also means admitting when it is not the best solution.

I would start with something simpler when:

• the rules are stable and can be coded directly;
• the acceptable error is near zero and there is no safe validation;
• the necessary data cannot be exposed to the model or the platform;
• there is no owner to approve actions, monitor results, and answer for failures;
• the cost of unpredictability exceeds the gain in flexibility;
• a person can solve the rare case better than a permanent system.

Agents are useful when there is real variability, sufficient context, well-delimited tools, and evaluation criteria. Outside of that, adding autonomy can just be an expensive way to make errors more creative.

What this has to do with i-9.ai

This separation of layers already guides what I can deliver through i-9.ai.

Not starting with the tool of the week. Starting with the operation.

Understanding the problem, the data, the decisions, the people, and the risks. Discovering if the answer requires software, automation, a model, an agent, a full harness — or none of these things. Only then designing a customized and governed solution.

The base is reusable, and some automations are mature enough to be practically replicated. This does not eliminate adaptation: integrations, permissions, data, risks, and processes continue to belong to each client’s context.

Whenever the problem allows, my preference is for open source, private infrastructure, and sovereignty over data, policies, and operation. It is not dogma nor a promise of absolute isolation. Useful external dependencies need to be evaluated, declared, and governed.

The principle of delivery remains: technology should expand capability without hiding dependency, uncertainty, or responsibility. If this way of thinking resembles what your company needs, get in touch. The conversation starts with the operation, not the tool of the week.

Seven questions before accepting “let’s add AI”

When the next conversation starts with that phrase, try to return seven questions:

1. What concrete outcome needs to change?
2. Are we asking for a response or authorizing an action?
3. Which data, sources, and context can the system use?
4. Can the path be automated or does it require dynamic choices?
5. Which tools and permissions will actually be necessary?
6. Who verifies, approves, and answers for material decisions?
7. How to detect failure, stop execution, and return to a safe state?

If no one can answer, the project is not yet ready to accelerate.

Maybe it is just ready to think better.

And that is already a start.

Demystifying AI does not diminish the technology. It does the opposite: it removes from it the obligation to sustain a fantasy and allows us to see where capability actually exists.

When the magic leaves the stage, architecture, context, criteria, limits, and responsibility enter.

That is where artificial intelligence begins to become useful.

Keep reading

• The best answer is not the one that pleases me most: how to transform anti-sycophancy criteria into context, permissions, checkpoints, and validations.
• Technology evolution: from mainframe to the infamous pun in real time: the historical line that made it possible to talk to systems capable of using context and tools.
• The seductive predictability of AI: why a fluid and personalized interface remains different from human reciprocity.

References and usage limits

The sources below support specific definitions, distinctions, or practices. None of them proves that a concrete architecture will be safe, effective, or appropriate without context evaluation.

• OECD.AI, “What is AI? Can You Make a Clear Distinction Between AI and Non-AI Systems?” (2024) (accessed Aug 26, 2026): explains the updated definition of an AI system and distinguishes model from system; acknowledges that there is no simple and universal boundary.
• Anthropic, “Building Effective Agents” (2024) (accessed Aug 26, 2026): presents the distinction used by the company between predefined workflows and agents that dynamically drive tool use; it is not universal standardization.
• Sharma et al., “Towards Understanding Sycophancy in Language Models” (2023): investigates sycophancy in five assistants and the role of preference data; it does not represent all versions, architectures, or use cases.
• NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” (2024): defines and contextualizes confabulation risks in generative AI; it does not imply that every output is false nor measure a specific model from this article.
• NIST, “Artificial Intelligence Risk Management Framework 1.0” (2023): voluntary framework to govern, map, measure, and manage AI risks; it is not certification nor a guarantee of compliance or security.
• OpenAI, “Harness Engineering: Leveraging Codex in an Agent-First World” (2026) (accessed Aug 26, 2026): engineering report on legible context, documentation, tools, and feedback loops in a specific project with Codex; it does not demonstrate suitability for every organization.