Perhaps the greatest limitation of artificial intelligence in your company isn’t in the model yet. It may be in the image you have built of what AI is.

TL;DR

Many people met AI through a conversation window and concluded that it is useful for answering questions, writing emails, and producing text with a somewhat generic voice. That can already be useful when there is context and method. But a chatbot interface is only a door. An AI system can also interpret documents, compare data, validate deliverables, find failures, coordinate tools, prepare decisions, and perform bounded actions. In some cases, it can make a low-impact operational decision within strict rules, with evidence, limits, abstention, records, and reversibility. The leap isn’t giving the machine unrestricted freedom. It is turning human criteria into a verifiable architecture.

When someone tells me artificial intelligence can write an email faster, I don’t disagree.

It can.

When they say it can summarize a meeting, assemble a presentation, or answer a question, they are also right.

The problem is believing that the technology ends there.

It is like looking at a computer and concluding that it is a typewriter with a power cord. Technically, it can do that too. It just isn’t a very useful description of what is sitting on the desk.

Most people met AI through a text box.

You write on one side. You receive an answer on the other.

After a few generic answers, invented references, or sentences wearing the perfume of corporate LinkedIn, a conviction forms: “this is interesting, but it can’t be trusted”; “it will sound too AI-generated”; “if I use it, I’ll lose authority”; “it is for playing, not for running a company.”

Some of that fear is healthy.

The mistake is confusing lack of control with an inevitable limit of the technology.

A chatbot is an interface, not the definition

A chatbot is a conversational interface. It receives messages and returns responses.

Behind that interface there may be only a language model responding to the current text. There may also be memory, documents, tools, rules, permissions, validators, and other systems capable of consulting or changing the world outside the conversation.

The screen can look almost identical.

The architecture is not.

In the first case, you ask a question and receive an answer.

In the second, you can say “prepare this article” and start an operation that reads editorial contracts, researches sources, verifies references, creates files, generates an image, produces versions in three languages, validates the site, and stops before publishing because that decision remains mine.

The chat is the doorknob.

It isn’t the house.

Even chat-only use can be much better

Before spreading agents throughout a company, it is worth recognizing that a good conversation already solves real problems.

A chat interface can help you:

• turn disorganized speech into questions that reveal the requirement;
• compare two proposals and expose different criteria without pretending it chose the objective for you;
• summarize a set of documents with links to their origin;
• prepare a meeting by anticipating objections and missing information;
• rewrite a text for a defined voice and audience;
• test the clarity of a decision by asking the system to look for weak premises;
• convert an idea into a checklist, plan, or verifiable specification;
• explain a technical term at the level of the person who will actually use the information.

None of this requires AI to click anything.

It requires the conversation to have context, criteria, and a better contract than “help me with this.”

A limited use isn’t necessarily a poor use.

What is poor is not knowing it was a choice.

“It will sound too AI-generated” is a process warning

Generic text isn’t an inevitable signature of the tool.

It is usually the predictable result of a generic instruction, little context, no voice reference, and no review.

If I ask “write a professional post about innovation,” I shouldn’t be surprised when I receive a polite collection of commonplaces. The model doesn’t know the perception that bothered me, the experience supporting my reading, the joke I would make, the claim I would refuse to publish, or the kind of source I consider sufficient.

Those things need to enter the system.

That is why I turned my way of working into a harness: a set of context, memory, procedures, tools, and validations around the model. The goal isn’t to make AI “sound like me” through a trick. It is to prevent it from filling important gaps with the statistically comfortable answer.

My authority doesn’t increase because I typed every character manually.

It doesn’t increase because the answer arrived beautifully formatted either.

It depends on whether I can sustain the thesis, show where the facts came from, declare the limits, and answer for the decisions I made.

Error isn’t solved by banning the tool

Language models produce probabilistic outputs: given similar inputs, they may formulate different answers and be wrong with remarkably inconvenient verbal confidence.

That is a reason for governance.

It isn’t a reason to pretend human processes were already error-free.

A person can forget a rule, copy the wrong number, fail to check a document, or decide under pressure. AI can introduce other errors: fabricate a source, misread an exception, use outdated context, or choose an inappropriate tool.

Responsible design doesn’t merely ask “human or AI?”

It asks:

• What kind of error can occur at each step?
• How will it be detected?
• Which check can be performed by a fixed rule?
• Which part requires interpretation?
• When must the system abstain from answering?
• Who receives the exception?
• How can the action be interrupted or reversed?

Fear of error is a terrible architect when it produces paralysis.

It is an excellent requirement when it produces controls.

From conversation to operation: six different roles

Calling everything “AI” hides important decisions. I prefer to separate the roles the system can play.

On mobile, swipe the table sideways to compare use and control.

Role	Example	Necessary control
Reflection interface	Organize an idea, formulate questions, compare alternatives, or prepare a conversation	Clear context, sources for factual claims, and the decision preserved with the person
Reading and structuring	Classify tickets, extract invoice fields, summarize histories, or normalize documents	Limited access, data provenance, quality sampling, and an exception route
Validation and quality assurance	Compare a deliverable with requirements, find broken links, flag missing fields, or review consistency	Explicit criteria, deterministic checks where possible, and no self-approval without a counterweight
Executing agent	Query systems, gather evidence, create artifacts, open tasks, and use tools to achieve an objective	Minimum permissions, action records, cost limits, and human approval points
Decision support	Assemble scenarios, expose assumptions, organize risk, and reveal missing information	Traceable evidence, declared uncertainty, and a human accountable for the objective and consequence
Bounded operational decision	Route a ticket, block an item outside policy, or authorize a small replenishment within approved limits	Strict policy, low impact, reversibility, confidence threshold, abstention, audit, monitoring, and escalation

These roles can appear together.

A support interaction can start in chat, retrieve the order, summarize the history, validate the policy, propose three options, and execute only the one within its granted authority. If the situation exceeds the limit, the system doesn’t improvise power.

It stops.

Quality assurance is also work for AI—but not only for AI

One of the most interesting uses isn’t producing the main content.

It is trying to prove that the deliverable is wrong.

An agent can compare a proposal with the requirements and flag missing items. It can find a claim without a source. It can review whether a contract uses the same concept incompatibly. It can read a set of tickets and find a pattern nobody had aggregated.

At the same time, deterministic rules—code that produces the same result for the same condition—can check what requires no interpretation: required field, date format, internal link, maximum amount, expected signature, passing test.

We don’t have to choose between AI and conventional software.

A reliable system combines each where it works best.

AI interprets language and context.

Fixed automation protects invariants: conditions that must remain true throughout the process.

The human defines what matters and owns what cannot be delegated.

An agent isn’t a chatbot with self-esteem

An AI agent is a system in which the model can choose next steps and use tools within a bounded objective.

It can observe the result of an action, adjust the plan, and continue until it finishes, encounters a blocker, or needs a human decision. That ability increases usefulness and risk at the same time.

Anthropic distinguishes workflows from agents: in a workflow, code predefines the path; in an agent, the model dynamically directs part of the process and tool use. This is one company’s taxonomy based on its own practice, not a universal definition. The useful principle is to start with the simplest solution and add autonomy only when it improves a measurable outcome.

In 2026, the company also published its principles for trustworthy agents, arguing for human control, transparency, security, and privacy. The source describes Anthropic’s own product design and position. It doesn’t prove that every agent on the market follows those principles.

Giving tools to a model without restricting permissions doesn’t create a digital employee.

It creates an error surface with access to systems.

“Decision-making AI” needs a longer sentence

I don’t particularly like the expression “AI decided” when that ends the explanation.

I prefer to say:

The system executed a specific operational decision within an approved policy, using this evidence, under these limits, and with this exception route.

It is a less marketable sentence.

It is also a much more honest architecture.

Automated decision-making should not mean generic authority. It means turning a policy into verifiable conditions:

• which input is valid;
• which source may be used;
• which outcome is authorized;
• which value or impact limit applies;
• what confidence level is required;
• when the system abstains;
• who receives the exception;
• what gets recorded;
• how the outcome can be undone.

Routing a ticket to the right queue can fit this design. Authorizing a small replenishment within budget and approved vendors can too.

Hiring someone, denying credit, defining medical treatment, or assuming significant legal risk involve analyses, rights, and responsibilities that don’t disappear because a model produced a score.

The greater the impact, the less acceptable it is to hide the decision behind the word “intelligence.”

Governance expands what can be done

Governance is sometimes treated as the department responsible for saying “no” after someone has an idea.

I see it differently.

When we know which data may be used, which tool may act, which evidence must exist, where approval is mandatory, and how the system fails safely, we can permit more execution without relying on blind trust.

The NIST AI Risk Management Framework organizes risk management into four functions: govern, map, measure, and manage. It is a broad voluntary framework currently undergoing revision; it does not certify an implementation or provide a universal checklist. It supports an important idea: risk must accompany the entire system lifecycle.

Governance isn’t the opposite of capability.

It is what turns raw capability into bounded authority.

Imagination opens the door. Architecture decides whether we should enter

There is also the opposite mistake: discovering that AI can do more than converse and concluding it should do everything.

It shouldn’t.

Many tasks still call for a simple integration, a deterministic rule, a better form, or removing a useless step. In “Your company doesn’t need to figure out where to put AI”, I showed how to start from the bottleneck and choose the smallest sufficient intervention.

The point here comes earlier.

If your image of AI ends at the chatbot, you may not even be able to formulate the options worth evaluating. If your image begins with an autonomous intelligence that will solve the entire company, you won’t be able to either.

One view is too small.

The other is too large to remain responsible.

An exercise for seeing the operation differently

Choose one recurring job in your company and don’t ask “how do we add AI?” yet.

Ask:

1. What information enters, and where does it come from?
2. What must someone understand before acting?
3. Which part follows a fixed rule?
4. Which part depends on language, context, or an exception?
5. Which error repeats?
6. What evidence would show that the deliverable is correct?
7. Could the system merely prepare the work?
8. Could it validate the work independently?
9. Could it perform a reversible action?
10. Is there a low-impact decision that fits a strict policy?
11. When must it stop and call a person?
12. Who remains accountable for the outcome?

The answer may be a better chatbot.

It may be an automation, validator, agent, decision-support system, or a combination of all five.

What it shouldn’t be is a technology purchase searching for a problem to justify the invoice.

This is the kind of translation I deliver

At i-9.ai, my work doesn’t begin by offering a chatbot to every department.

It begins by understanding how the operation works, where context gets lost, which criteria already exist, which decisions repeat, and what the smallest architecture is that can improve the outcome with control.

Sometimes the answer is conventional software. Sometimes it is automation. Sometimes it is a conversational interface. Sometimes it is a set of agents, memory, tools, and validations. It is often a combination.

If you recognized a process that could be better understood, validated, or executed, get in touch. The conversation doesn’t need to start with the tool.

It can start with the work that currently depends on too much effort, improvisation, or trust.

The limit worth preserving

I’m not afraid of an answer “sounding like AI.”

I’m afraid of an answer sounding certain without evidence, criteria, or an accountable owner.

I also don’t believe authority comes from doing everything manually. Authority comes from being able to explain why something was done, with which information, under which limits, and how it will be corrected if it is wrong.

AI can be a conversation.

It can be a tool.

It can be an interpretation layer, a validator, an executor, or a bounded part of a decision.

What it cannot be is the excuse for nobody answering for the system anymore.

If your imagination moves beyond the chatbot window and your governance follows, the conversation changes.

The question stops being “what can AI do?”

It becomes:

Which capability is worth building here—and which control needs to be born with it?

Keep reading

• Your company doesn’t need to figure out where to put AI: how to start from the bottleneck and choose among process, automation, assistance, an agent, and governed decision-making.
• AI isn’t one thing: model, agent, automation, and harness: a map of the layers hidden behind the word “AI.”
• The best answer isn’t the one that pleases me most: why context, sources, disagreement, and validation matter more than a pleasing answer.

Learn more

• Chatbot: encyclopedic context on conversational interfaces.
• Automation: an overview of systems that execute processes with different degrees of human intervention.
• Quality assurance: an introduction to practices used to prevent and detect quality problems.
• Observability: the ability to understand a system’s internal state through evidence such as logs, metrics, and traces.
• Principle of least privilege: a security rule under which each person or system receives only the access necessary to perform its function.

References and limits of use

• NIST, “Artificial Intelligence Risk Management Framework 1.0” (2023): organizes risk activity into govern, map, measure, and manage. It is broad and voluntary and doesn’t certify any architecture described in this article.
• NIST, “AI RMF Playbook”: offers suggested actions for operationalizing the framework. NIST itself states that the material evolves and its suggestions aren’t a universal checklist.
• Anthropic, “Building Effective Agents” (2024): presents the company’s distinction between predefined workflows and agents that dynamically direct tools. It is an engineering reference from Anthropic, not a mandatory taxonomy.
• Anthropic, “Trustworthy Agents in Practice” (2026): describes principles and product choices for human control, transparency, security, and privacy. It doesn’t evaluate all agents or guarantee that an external implementation is trustworthy.

The examples are architecture hypotheses intended to explain degrees of capability and control. They do not replace technical, legal, labor, financial, medical, or security analysis in the real context.

The cover image is a synthetic editorial illustration created to show the passage from conversation to a governed operational system.