If your entire artificial intelligence strategy fits inside an editorial calendar, you may have bought a power plant to charge a phone.

TL;DR

Producing content is a legitimate use of artificial intelligence. This blog is an example of how a system with voice, context, sources, review, and validation can sustain an editorial operation without outsourcing direction or responsibility. The problem is reducing AI to manufacturing generic text to fill a feed and calling that transformation. The same technology can research, organize knowledge, integrate systems, validate deliverables, coordinate tools, perform tasks, and support decisions within rules. The useful question isn’t how many posts it generates. It is what verifiable capability now exists, for whom, under which criteria, and with whose responsibility.

What do you want to use artificial intelligence for?

I ask because “we want to use AI” has become a fairly common sentence. It sounds like a decision, but it still says almost nothing.

Use it for what?

Change which work?

Solve which bottleneck?

What capability does not exist yet and needs to be built?

In many conversations about the subject, the first concrete answer ends in content production.

“Can it make this month’s posts?”

It can.

You can also use a top-of-the-line computer as a paperweight. It will probably hold those sheets down with impressive competence.

The problem isn’t making posts. It is looking at a technology capable of interpreting context, consulting systems, comparing evidence, validating deliverables, coordinating tools, and performing tasks — and deciding that the great transformation will be publishing thirty captions about innovation.

Preferably with a rocket at the end.

Because innovation without a rocket, apparently, never takes off.

The problem isn’t producing content

It would be a rather convenient contradiction for me to attack AI-assisted content production on this particular blog.

I use AI to write.

I use it to organize ideas I started speaking into a microphone, find references, test counterarguments, check links, prepare images, preserve editorial decisions, structure versions in other languages, and validate the site before publishing.

I explained in “Writing with AI Didn’t Make Me Less of an Author” why that process is very different from requesting generic text and placing my name underneath it.

The perception that starts the article remains mine.

The direction remains mine.

What enters, what leaves, what needs a source, and what does not represent me still pass through my evaluation.

The system carries much of the operation that used to compete for space in my head with the thinking itself: remembering the reference, checking the claim, finding the related article, reviewing the structure, ensuring the image has a purpose, testing the link, and preventing a candidate version from being published without evaluation.

That is a real use of AI for content.

What I am criticizing is something else.

It is content without perception, thesis, context, criteria, or anyone willing to answer for what was published. A text factory that starts with genericity keeps producing genericity. The only innovation is the speed of the conveyor belt.

If readers scroll past the result with the same indifference with which the machine produced it, perhaps we optimized the wrong part of the work.

AI doesn’t choose why it was hired

A tool does not enter a company and discover, through its own illumination, what should change.

It receives a request.

When the request is generic, the response tends to fill the available space with something plausible. A prompt — the instruction and context given to the model — such as “create a professional post about innovation” contains none of the company’s experience, the customer’s real doubt, the contradiction worth discussing, or the limit of what may be claimed.

So the system does what it can with the void.

It delivers five bullet points, a positive conclusion, and some variation of “in an increasingly dynamic world.”

There. The digital transformation has been saved to a text file.

Except AI did not choose a bad direction.

Nobody chose any direction at all.

It simply filled the void with excellent grammar.

You don’t solve this by asking it to “sound more human.” You solve it by giving the work a reason to exist: a real question, a perception, an audience, a source, an objective, a quality criterion, and someone responsible for the final decision.

Without that, changing the model, buying more credits, or installing the tool of the week only increases the power available to keep going without knowing where.

“Sounding human” is far too low a bar

There is an understandable obsession with preventing a text from “sounding too AI-generated.”

I don’t want to publish a collection of smooth, balanced, empty sentences that could have been signed by any company on the planet either.

But sounding human is an insufficient test.

A person can also write generic text, repeat wrong information, and have nothing useful to say. We have been doing that by hand for quite some time. AI did not invent bad content; it merely lowered the cost of producing it at industrial scale.

The bar needs to rise.

Sounding human isn’t enough.

There must be something true, verifiable, and useful to say.

“True” does not mean every opinion needs an academic study before it may exist. It means the conviction belongs to the author and did not appear through spontaneous generation because the sentence sounded good.

“Verifiable” means dates, data, cases, technical mechanisms, and other factual claims must allow readers to find the origin and understand the source’s limit.

“Useful” means the text helps someone notice a problem, formulate a question, make a decision, or act with greater clarity. It doesn’t have to sell anything. It has to justify the time it asked from the reader.

A well-imitated voice without experience, criteria, or responsibility remains an editorial fantasy.

It has merely become more convincing.

The chatbot is the door, not the entire operation

Many people met AI through a conversation window. That explains why its most visible uses are writing, summarizing, answering, and rewriting.

And a chatbot interface can be extremely useful. It can organize a spoken requirement, compare alternatives, prepare a meeting, locate a gap, or help someone think before acting.

The mistake is treating the door as if it were the whole house.

Beyond conversation, AI-assisted systems can play different roles:

• deterministic automation executes a known rule and produces the same behavior when the condition repeats;
• a research and structuring layer finds documents, preserves their origin, and organizes material for analysis;
• a validator compares a deliverable against requirements and looks for missing fields, contradictions, broken links, or unsupported claims;
• an AI agent chooses next steps and uses tools within a bounded objective and permissions;
• governed memory preserves context and decisions with origin, date, scope, and the possibility of review, instead of depending on the conversation to “magically remember”;
• orchestration coordinates stages, tools, agents, and approval points so the work reaches a verifiable artifact;
• an integration connects systems so a person does not keep copying information between screens like a manual bridge powered by coffee;
• a system can support or execute a bounded operational decision, as long as there are policies, evidence, impact limits, abstention, records, a responsible owner, and a way to correct the result.

Not every company needs every component.

In fact, many should not even start with AI. A fixed rule, a conventional integration, a better form, or the removal of a useless step may solve the problem with less cost and risk.

Using the most complicated architecture available is not sophistication.

Sometimes it is just insecurity with a pretty diagram.

Not every fly needs a bazooka

There is a symmetrical mistake I don’t want to make either.

In computing, we have long used the expression “using a bazooka to kill a fly.” It came up, for example, when someone chose an enormous software structure — a framework — to build a single presentation page that could have been delivered with far less.

The technology changed. The fly is still in danger.

Today the bazooka may come with an agent, memory, ten skills — reusable instructions and procedures — and retrieval-augmented generation, or RAG. In plain language, RAG is a technique that retrieves information from a defined knowledge base and gives that context to the model before it responds.

All of it can be useful.

None of it becomes necessary merely because it exists.

If a formula calculates the result precisely, use the formula.

If a form organizes the input, build the form.

If a fixed rule moves the information safely, create the automation.

Building an agent with memory and tool access to perform what twenty predictable lines could solve isn’t innovation. It may simply be a sophisticated way to increase cost, maintenance, permissions, failure points, and response time.

Reducing AI to generic captions is a lack of imagination.

Putting AI everywhere is a lack of judgment.

Power does not justify excess. The right architecture is the smallest one that solves the problem safely.

The question isn’t “what did it produce?”

Output is easy to display.

Thirty texts.

Forty images.

A presentation born before someone finished asking for it.

All of this creates movement. Movement is photogenic. Operational capability tends to be quieter.

It appears when:

• information stops getting lost between departments;
• a document arrives with its sources and the gaps that were found;
• a deliverable is validated before moving to the next stage;
• a rule no longer depends on one person’s memory;
• an exception finds a responsible owner instead of disappearing into the flow;
• a decision receives better scenarios and evidence without hiding who answers for it;
• a recurring process produces an artifact another person can verify, correct, and maintain.

That is why the question that changes a project isn’t “how many posts can AI produce?”

It is:

What capability now exists?

Who can do what now that previously depended on manual effort, improvisation, waiting, or lost context?

How do we know the deliverable is correct?

What happens when the information isn’t enough?

Who may authorize an action?

Who remains responsible when something goes wrong?

If those questions have no answer, the problem is not the lack of a more powerful AI.

It is the lack of a project.

This blog isn’t an argument against content. It is an argument against ownerless content

I maintained other blogs between 2005 and 2008. I could write every line myself, but I could not sustain the entire operation around the writing for many days at a time.

This blog was born with support from ChatGPT and under my direction. Even so, at first I still had to explain the context again, coordinate stages manually, and correct a tone that did not accurately reflect how I develop an idea.

Today, the system receives editorial contracts, voice references, research rules, linking criteria, limits on what may be claimed, validations, and the precise point at which a decision must return to me.

It did not “become Felipe.”

It did not acquire consciousness, professional experience, or authorship through proximity.

I turned part of my way of working into instructions, examples, memory, tools, and reviewable criteria. That lets me externalize a perception, develop the thesis, and delegate coordination of the rest without teaching the entire operation again in every conversation.

This system does produce content.

It also researches, challenges, organizes, validates, preserves context, prepares evaluation, and prevents automatic publication.

The article is the visible result.

What we built is much more capable than the article file you see at the end.

That difference disappears when someone reduces every use of AI to “it writes posts.”

The feed is the storefront. The operation is the house

Content can educate a customer before a commercial conversation. It can translate terms, show criteria, make a problem visible, and allow someone to understand how a company thinks.

That is one of this blog’s roles for i-9.ai.

But content does not replace delivery.

The feed is the storefront.

The operation is the house.

There is no point publishing every day that the company is “revolutionizing the future” while someone still copies orders between spreadsheets, searches email for the right document version, and depends on one specific person to remember the next step.

Generating more content about innovation does not make the operation innovative.

It makes the contradiction better designed.

When I look at a company, I don’t start by asking which model it wants to use or how many publications it wants to automate. I start by looking for where work stalls, where context gets lost, which decision repeats, which error keeps returning, and which person has become a manual integration between systems.

That is why I wrote that your company doesn’t need to figure out where to put AI. It needs to identify where a real problem exists and which smallest intervention can improve the result with control.

Sometimes that intervention will be content.

Perhaps the bottleneck is precisely turning scattered technical knowledge into material that sales, support, and customers can understand. In that case, a governed editorial system can be a real operational capability.

Sometimes it will be automation.

Sometimes it will be a validator, an agent, an integration, reviewable memory, or a combination of them.

What it should not be is a tool looking for a flashy task to justify its purchase.

A quick review before calling it a strategy

If you are evaluating an AI use in your company, try answering:

1. What work, bottleneck, or decision gave rise to the project?
2. Who receives the result, and what can they do better with it?
3. What capability will exist beyond producing more output?
4. Which part requires language and interpretation, and which should remain a fixed rule?
5. Where does the data come from, and how will its origin be preserved?
6. What criterion defines a correct deliverable?
7. How does the system find errors, uncertainty, or missing information?
8. Which tools may it use, and how far do its permissions go?
9. At what point must it stop and return the decision to a person?
10. How will we measure whether the bottleneck improved?
11. Who maintains the system after the demonstration ends?
12. How can it be corrected, shut down, or rolled back?

If the honest answer is “we only want to produce good content more consistently,” that is fine.

Define voice, sources, review, objective, responsibility, and what makes the content worth publishing.

That is already far better than dressing an empty calendar in the word “strategy.”

But if there is a queue, rework, a repetitive decision, lost information, or a recurring error elsewhere in the company, perhaps the most important opportunity isn’t in the feed.

Perhaps it is working quietly every day to remain invisible.

The conversation that interests me starts before the tool

At i-9.ai, I work to transform context, requirements, and bottlenecks into systems that can be used, verified, monitored, and governed.

That may involve conventional software, automation, agents, data, memory, validation, infrastructure, security, and integration. It may involve content when content is part of the actual problem.

My work doesn’t begin with a generic package looking for somewhere to be installed.

It begins with understanding how the work actually happens.

If you recognized a process that currently depends on improvisation, lost context, or too much manual effort, get in touch. You do not need to arrive knowing which technology to use.

Bring the bottleneck. We can start there.

What is worth scaling

I don’t want less content because it was produced with AI.

I want less content that had no reason to exist.

I want systems that help people research better, explain better, decide better, and execute better — without hiding sources, limits, or responsibility behind a convenient interface.

If the right application is an article, great. Let it begin with a real perception, say something verifiable, and remain useful after the reader scrolls on.

If the right place for AI is inside the operation, even better. Let it leave the presentation about the future and enter the process with permissions, criteria, monitoring, and someone responsible for the result.

If the only result was publishing more things nobody needed to read, you did not expand capability.

You automated noise.

Artificial intelligence does not need to occupy every space.

But before using it only to fill one, it may be worth asking what it could help build.

Continue reading

• If You Think AI Is Just a Chatbot, You Started with the Wrong Limit
• Your Company Doesn’t Need to Figure Out Where to Put AI
• Writing with AI Didn’t Make Me Less of an Author
• The Best Answer Isn’t the One That Pleases Me Most

Learn more

• Chatbot: an encyclopedic overview of conversational interfaces; the term describes the interaction form, not the entire possible architecture behind it.
• Automation: an introduction to systems that perform processes with different levels of human intervention.
• Quality assurance: context on practices used to prevent, find, and correct problems before a deliverable moves forward.
• System integration: an overview of connecting components and systems that need to exchange data or coordinate processes.
• Prompt engineering: encyclopedic context on designing instructions and context for generative models; a prompt is not equivalent to the work system described here.
• Software framework: context on reusable software structures; a larger structure is not automatically better for a small need.

References and limits of use

• AWS, “What is Retrieval-Augmented Generation (RAG)?”: defines RAG as using an external knowledge base to add context to a language model’s response. It is documentation from a technology provider and does not prove that RAG improves every process, is necessary, or is the right architecture for the examples in this article.

The examples in this text are architectural hypotheses used to explain capabilities and controls. They are not case studies, a promise of results, or universal technical advice. The appropriate design depends on the process, data, risk, integrations, and who is responsible for the decision.