AI doesn’t fix broken processes: it makes them faster

Over the last few months I have spent a large part of my time bringing artificial intelligence agents into work that ranges from software development and code review to process automation.

The image at the top of this article is part of that work: a control plane from which different agents can run specialized tasks, collaborate, review results and move forward within a defined flow.

But after working with this kind of architecture, there is one conclusion I consider far more important than any model, agent or platform:

Artificial intelligence does not turn a bad process into a good one.

It can make it faster. It can automate it. It can even hide some of its flaws for a while.

But if the process is badly designed, has too many exceptions, depends on knowledge that was never documented or has bottlenecks, automating it with AI will not solve the problem.

In some cases we will simply get a poor process to fail faster.

Before automating, understand the process

There is one question I consider essential before deploying AI agents:

Does this process work correctly when people do it?

If the answer is no, it is probably not yet time to automate it.

First we need to understand where the information comes from, who makes the decisions, what dependencies exist, what the exceptions are, where the bottlenecks are and, above all, what knowledge people use to do the work correctly.

Because automating does not just mean replacing manual steps with calls to a model.

A good process should have, among other things:

• clearly identified inputs;
• defined decision criteria;
• owners and limits of authority;
• exception handling;
• controls and validation mechanisms;
• measurable outcomes;
• traceability;
• points of human intervention where they are truly needed.

When those conditions exist, AI can become an extraordinary accelerator.

When they don’t, AI inherits the problem.

Agents change how software is built

The same idea applies to software development.

An agent can analyze code, build a feature, run tests, review security, validate architecture or challenge the work produced by another agent.

That significantly changes how fast we can build software.

But it does not remove engineering.

In fact, in my experience the opposite happens: the more capability we hand to agents, the more important good architecture, standards, controls and technical knowledge become.

An agent can generate a huge amount of code in very little time. That does not mean the code should reach production.

That is why it is worth moving from using AI only as an individual assistant to designing systems of specialized agents, each with a defined purpose, tools, context and responsibilities.

One agent builds.
Another reviews.
Another analyzes architecture.
Another checks security.

And the system decides when a task can move on, when it has to go back to review and when it needs human intervention.

Speed then no longer depends only on how fast one person can write code.

The challenge becomes a different one: how well we can design the system that produces, reviews and governs that work.

From software to business processes

The same concept can extend to almost any area of an organization.

Purchasing, sales, operations, support, administration, finance, human resources, document management and customer service all have processes that can benefit from agents able to analyze information, run tasks and work with other systems.

But there is an important difference between automating tasks and automating processes.

A task can be fairly simple: classify a document, write a summary, review information or draft a reply.

A complete process usually involves decisions, dependencies, exceptions, different systems and responsibilities spread across several people.

That is where architecture becomes essential.

Connecting a model and waiting for results is not enough.

You need to define what each agent can do, what information it can use, what actions it can take, which decisions need approval and what happens when the result does not meet the agreed criteria.

Useful autonomy is not about letting AI do anything.

It is about giving it the right level of autonomy within clearly defined limits.

Knowledge is still human

There is also a recurring concern whenever artificial intelligence comes up: what will happen to people.

I think we are asking the wrong question.

AI can learn patterns, process huge amounts of information and carry out certain activities at extraordinary speed. But an organization’s real knowledge does not live only in its documents.

It also lives in its people.

In the person who knows why an exception exists.
In the one who sees that a seemingly simple requirement will have consequences in another area.
In the one who knows the story behind a decision.
In the one who knows when to follow the procedure and, also, when to stop it.

That know-how is one of the most important assets of any company.

That is why I don’t believe our mission should simply be to replace people with agents.

We should use AI to multiply the capacity of the people who already hold that knowledge.

A good developer with agents can greatly expand what they can deliver.

An architect can evaluate alternatives faster.

A security specialist can widen the reach of their reviews.

A process expert can turn years of experience into instructions, criteria, controls and knowledge that agents can reuse.

To me, that is a fundamental part of this transformation.

It is not about competing with AI

For years we have used technology mainly to execute instructions.

Now we are starting to work with systems that can interpret context, propose alternatives and run entire chains of activities.

That requires learning a new way of working.

We have to know how to delegate to agents.
We have to know how to provide context.
We have to learn how to set limits.

And, perhaps most importantly, we have to know how to review and question their results.

The advantage will not necessarily go to whoever uses the most artificial intelligence.

It will go to whoever knows what to delegate, what to automate, what to keep under human judgment and how to design the collaboration between people, agents and systems.

Engineering first. Automation second.

There is an understandable temptation to start an AI project by asking which model to use, how many agents we need or which platform to deploy.

I would start earlier.

• What problem are we solving?
• How does the process work today?
• Where are the bottlenecks?
• What knowledge does a person use to make the right decisions?
• What can be automated and what should stay under human supervision?

Then we can talk about agents, models and automation.

Because a well-designed process can become an excellent AI-augmented process.

A badly designed one will still be a bad process, even with agents, automation and the most advanced model available.

Artificial intelligence is an extraordinarily powerful tool.

But knowledge, judgment and accountability are still ours.

We should not compete with AI. We should learn to build with it.

And that may be one of the most important professional skills we will need to develop over the next few years.