Juan Carlo, AI Consultant in Brazil: How He Works With Companies

Juan Carlo, AI Consultant in Brazil: How He Works With Companies

Juan Carlo is an AI consultant and software developer in Brazil who works with companies remotely, in Portuguese and in English. The work follows four steps: map the process, limit data and actions, pilot one real workflow, and decide whether the company should expand, adjust or stop. Services range from an initial diagnosis to WhatsApp agents, process automation, monitoring, OpenClaw for companies and Claude Code for teams.

Key takeaways

• The work is AI consulting and development applied to business processes, delivered remotely in Portuguese and English.
• The method has four steps: map the process, limit data and actions, pilot one real workflow, and decide between expanding, adjusting or stopping.
• Stopping is a legitimate outcome: the pilot exists to produce evidence, not to justify the project.
• Services cover consulting, WhatsApp agents, custom development, monitoring, automation, OpenClaw and Claude Code for teams.
• This article gives no prices, client names or results. Scope and success criteria are set case by case, after the mapping step.

Who is Juan Carlo, and who is this work for?

Juan Carlo Gonçalves is an AI consultant and software developer based in Brazil. He helps companies map, implement, monitor and maintain AI systems inside business processes. The development side matters because the consulting does not end with a report: the same person who diagnoses the process can build, integrate and sustain the solution.

The people who benefit most are those who need to decide and act: business owners, operations managers, customer service leads and technology leads. Usually there is a repetitive process built on messages, documents or simple decisions, and the question is whether AI fits there without putting the whole operation at risk.

This is not the right work for someone who wants to apply AI everywhere at once, or who wants a guaranteed result before any test. The method starts from the opposite premise: begin small, measure, and only then decide.

There is also an authorship policy worth explaining. On this blog, and in the way the work is done, three things are kept apart: what comes from official documentation, what comes from implementation experience, and what is a hypothesis still to be tested. Technical claims rely on primary sources. Third-party results and metrics are not used as arguments.

What are the four steps of the method?

The method is deliberately simple, because most AI projects that go wrong fail from a lack of scope, not a lack of technology. The four steps are:

• Map the process: describe how the work is done today, who takes part, where the messages, systems and exceptions are, and set a baseline to compare against later.
• Limit data and actions: decide what the AI can read, what it must never see, what it can do on its own, what needs human approval and what gets logged.
• Pilot one real workflow: choose a single workflow, with real users, logs and a success metric agreed before starting.
• Decide: with the pilot records in hand, choose between expanding, adjusting or stopping, then hand the operation to your team or keep it under ongoing support.

The order matters. Mapping first avoids automating a process that nobody understands end to end. Limiting before building avoids finding out too late that the agent had access to more than it needed. Piloting a single workflow keeps the project from turning into a vague promise. And a final decision with three possible outcomes avoids the inertia of pressing on only because time has already been spent.

Anthropic's guide to building agents recommends looking for the simplest solution and adding complexity only when it clearly pays off. That principle shapes the method: in many cases, a deterministic workflow with one targeted AI step works better than an autonomous agent.

Why limit data and actions before building?

An agent that reads everything and does everything is hard to audit and hard to correct. Limiting is the step that makes the pilot safe enough to run with real customers and employees. In practice, it is a direct conversation about boundaries, recorded in writing.

The NIST AI Risk Management Framework organizes AI risk management around governing, mapping, measuring and managing. You do not need to adopt the whole framework to use its logic: knowing where AI enters, what can go wrong and who is accountable already improves the quality of a project.

These are the questions used to limit a workflow:

• Which personal data does the workflow touch, and is there a legal basis for that use?
• Does any data leave the country during processing? If so, what does LGPD require? The article on international data transfer under LGPD when using AI providers is a good place to start.
• Which actions can the agent take on its own, which need human approval, and which are forbidden?
• In which situations does the conversation pass to a person, and how does that person receive the context?
• Which records are kept: the question, the answer, the source consulted, the decision made?
• Who can switch the workflow off, and how quickly?

The last point is often forgotten. A clear off switch is worth as much as any instruction given to the model. It also helps to decide in advance what not to delegate. The article on what not to delegate to AI in business is a good starting point for that list.

The ANPD, Brazil's national data protection authority, is the official reference for interpreting LGPD obligations. Legal questions specific to your company should go to someone qualified to answer them, and technical consulting does not replace that opinion.

What does a pilot with a real workflow look like?

A pilot is not a demo. It is a real workflow, with real people, over a short agreed period, with everything that happens recorded. The difference is being able to answer at the end whether it worked or not, based on evidence and not on impressions.

The basic plan for a pilot has these steps:

• Choose a workflow with enough volume to learn from, but with contained risk.
• Record the baseline: how the workflow runs today, how long it takes and where it tends to fail.
• Define the success metric and the stop criterion before starting.
• Build a set of test cases from real situations, including the difficult ones.
• Run with data and action limits, human approval at critical points and logs of every decision.
• Review the records at short intervals and fix whatever is systematic.
• Gather the results and decide between expanding, adjusting or stopping.

The test case sets follow the evaluation (evals) logic described in guides such as the ones from OpenAI and Anthropic on evaluating agents: without representative cases and clear criteria, there is no way to know whether a change improved or worsened behavior.

Illustrative scenario: an electrical supplies distributor receives questions on WhatsApp every day about delivery status and duplicate invoices. The workflow chosen for the pilot is delivery status only. The agent queries only the order system, in read-only mode, replies with the information it finds, and hands off to a human agent when the customer complains, when the order cannot be found or when the question goes off topic. Invoices, discounts and cancellations are out of scope. Each conversation produces a record with the question, the source consulted and the answer. At the end of the agreed period, the team compares the records with the baseline and decides whether to extend the pilot to duplicate invoices, adjust the handoff rules or close the pilot.

Notice what the scenario avoids: broad access, irreversible actions and commercial decisions. To understand the channel layer better, the guide on how to integrate AI into your company's WhatsApp details what the operation requires, and the article on AI customer support and what to automate helps separate what belongs to the agent from what should stay with the team.

Which services are available?

The services follow the same method at different depths. Not every company needs all of them, and many start with the first one only.

• AI consulting: process diagnosis, architecture design, pilot and adoption plan.
• AI agents on WhatsApp: support and operations workflows with clear limits, handoff to a human and a record of decisions.
• Custom agent development: business context, integrations with your systems, evaluations and controlled operation.
• Agent monitoring and maintenance: reviewing the records, adjusting instructions and fixing failures after the agent goes into production.
• Process automation: deterministic workflows combined with AI only where judgment is needed.
• OpenClaw for companies: managed deployment with permissions, restricted tools, observability and human approval.
• Claude Code for teams: guided use of the coding assistant, with practices and rules shared across the team.

Managed operations are delivered through Be Human (be-human.ai). The separation is useful: consulting and the pilot answer the question of what is worth doing, and managed operation keeps running what was approved.

A note on automation: not every process needs an agent. When the rules are clear and the inputs are predictable, a deterministic workflow is cheaper to maintain and easier to audit. AI comes in where there is free-form language, varied documents or judgment. Anthropic's guide to building agents draws a similar distinction between workflows and agents, and it is a good read for anyone who wants the reasoning behind that choice.

How do you decide whether to hire an AI consultant now?

A good moment to talk tends to share a few signs. So does a bad one. This decision guide helps tell them apart:

• It is worth talking if there is a specific process, with an owner, that takes up the team's time every day.
• It is worth talking if someone can describe how the work is done today, even imperfectly.
• It is worth talking if the company accepts testing at small scale and deciding based on records.
• It is worth waiting if nobody can say which problem needs solving, only that the company wants to use AI.
• It is worth waiting if the process changes every week and there is no stable rule to teach a system.
• It is worth waiting if no one is available to review the difficult cases during the pilot.

For the first conversation, it helps to bring four items: the process you want to improve, the systems and channels involved (WhatsApp, CRM, spreadsheets, ERP), what cannot go wrong, and who in the company makes the decision. With that, the mapping starts faster and the discussion about limits is concrete from the start.

An honest question to ask any consultant, this one included, is what happens if the pilot does not work. The right answer is that the company closes it with a clear record of what was learned, with no obligation to continue. That exit needs to be agreed from the start.

Frequently asked questions

Does Juan Carlo work with companies in any city in Brazil? Yes. The work is done remotely, in Portuguese and English, with video meetings and written follow-up. Where the company is located matters less than how clear the process to be mapped is, and whether someone is available to take part in the reviews.

Do I need to integrate my systems during the pilot? Not necessarily. Many pilots start with limited, read-only access to a single data source and only expand integrations after the workflow proves useful. Integrating less at the start reduces risk and makes it easier to see what is working.

Who looks after the agent after the pilot ends? That is decided in the final step. The company can take over the operation with the material delivered, ask for monitoring and maintenance support, or contract managed operation through Be Human. It can also close the project if the records show the workflow does not pay off.

Is there a guarantee of results, and what does it cost? Results are not promised, because they depend on the process, the data and how well the team adopts the change. What is offered is a method with an agreed metric, records and a clear decision at the end. Scope and commercial terms are set in a direct conversation after the mapping, and are not published in this article.

Sources

• NIST: AI Risk Management Framework
• Anthropic: Building effective agents
• Anthropic: Demystifying evals for AI agents
• ANPD: Autoridade Nacional de Proteção de Dados