Mentor dos Nerds Home About
About

About

I am Felipe Abreu, founder of Mentor dos Nerds, a technology professional, mentor, and author.

Felipe Abreu orchestrates software, agents, automations, and data flows in front of an operation connected to other sectors Editorial illustration created with AI from authorized visual references.

My foundation did not begin with the recent wave of artificial intelligence. It was built over years of developing software, dealing with real systems, and learning that technology only delivers value when it survives requirements, integrations, failures, maintenance, and people.

I hold a degree in Computer Science from UNISINOS. Throughout my career, I have worked across the entire lifecycle of a project: talking to the client, gathering requirements, identifying the problem behind the request, turning that understanding into a system, choosing strategies and architectures, implementing, deploying to infrastructure, and maintaining the operation as observable, secure, and recoverable via backups.

This end-to-end perspective is one of my greatest strengths. I do not simply receive a ready-made specification to code, nor do I deliver a repository expecting someone else to figure out how to get it running. I can follow the full distance between a poorly formulated need and a system in production — including the compromises, risks, and decisions that arise along the way.

The “lazy” developer who got up for coffee

I have always been a somewhat lazy developer — in the sense of wanting to solve things well and fast enough to get up from my chair.

When I worked physically in companies, finishing a problem early gave me time to go to the kitchen, have coffee, talk with people, and visit other departments. In those conversations, I began to understand how each area actually functioned: where information stopped, which rule was not documented, which shortcut sustained the operation, and why an apparently simple request arrived at the software in that form.

At the time, I did not call that process discovery. It was curiosity, coffee, and a desire not to stay stuck at my screen. But that circulation taught me something that still guides my work: no system exists only in code. It crosses people, decisions, incentives, exceptions, and agreements that rarely fit entirely within a specification.

Today, when I think about agents and automations, I continue doing the same thing with much more capable tools. Before accelerating a process, I want to understand the operation that will be accelerated. Automating without crossing into other sectors is just making the error arrive faster and with a better interface.

From software to agent orchestration

Today, I focus much of my work on orchestrating AI agents and automations.

This does not mean just writing a better prompt. It means building a work system where context, memory, skills, subagents, tools, permissions, validations, and decision criteria cooperate without removing from humans the responsibility for direction.

I use AI to externalize context, coordinate ideas, delegate execution, and increase operational capacity. At the same time, I take traceability, monitoring, security, information integrity, backups, and limits seriously. A Ferrari at high speed still reaches the wall sooner if no one is handling the steering.

What I build

My work happens at the intersection of:

  • software architecture and development;
  • AI agents, automation, and operational memory;
  • integration of processes, tools, and data;
  • infrastructure, security, and continuity;
  • technical leadership, communication, and human development.

In practice, I seek to map processes and bottlenecks, identify where software, automation, and AI can generate value, and implement solutions with the level of control the context demands. Sometimes this means combining market tools. In other cases, it means building a custom architecture because security, sovereignty, integration, or governance matter more than immediate convenience. Whenever the problem allows, I prefer open source, private infrastructure, and paths that preserve the client’s control over data, policies, and operations.

Why this blog exists

This blog is my intellectual and technical calling card.

It is also the editorial and authorial core of i-9.ai. This is where I have room to develop the perceptions, criteria, and safeguards that guide the work delivered by the company—without turning every article into a sales proposal.

Here I record how I think, what I am building, which questions remain open, and where technological enthusiasm needs to meet method. Some texts are practical. Others investigate the human effects of technology. In both cases, I want to separate evidence, hypothesis, and personal synthesis without killing the conviction of the text.

I do not write to prove that every novelty is a revolution. Nor do I write to treat every change as a threat. I write to understand the direction, test what works, and return to the world something that can be discussed, used, and verified.

And the services?

This space is also the gateway to the services I deliver through i-9.ai.

This does not turn the blog into a disguised sales page. Before hiring any solution, I want a potential client to be able to understand which problems I am trying to solve and why I care about direction, security, traceability, integration, governance, and human impact in deliverables.

If you like this way of working and see a problem I can help turn into a system, get in touch. You do not need to arrive with a ready-made solution: we can start with the need, the criteria, and what needs to change in the operation.

The articles remain the best way to get to know my repertoire, my method, and the type of problem I like to solve.

I offer presence, tools, and a path. Direction remains a human responsibility.