Superintelligence Consulting

In superintelligence consulting, the first 30 days should produce four documents you can verify: a map of the current process, a baseline of how it performs today, limits on the data and actions the AI is allowed to use, and a pilot charter with an agreed success metric. A serious consultancy does not promise results or hand over a slide deck about trends. The goal of the first month is to let you decide, with evidence, whether to pilot, adjust or stop.

Key takeaways

• The first month exists to produce a decision, not to put AI into production across every process.
• The four deliverables are: process map, baseline, data and action limits, and pilot charter.
• Without a baseline, no later result can be compared with anything, and every number becomes an opinion.
• Clear data and action limits (with human review) come before any choice of tool.
• A trustworthy proposal states what it does not promise and allows for the option to stop.

What does it mean to hire a superintelligence consultancy?

The term is popular, but it can be confusing. No company operates an artificial intelligence that outperforms humans at everything today, and anyone selling that is selling an idea, not a service. In commercial practice, superintelligence consulting usually means building an AI layer inside the company: models, agents, integrations with your systems and operating rules that extend what the team can do in specific processes.

If you want to separate concept from deliverable, it helps to read superintelligence myths that get in the way of decisions before you meet a vendor. To understand how that layer is organized internally, see the article on the five building blocks of a company superintelligence layer.

The point for the person deciding is simple: what you are buying is method and applied work on a real process. That is why the first month has to generate artifacts that exist on paper, that your team can read, challenge and correct.

What are the four deliverables of the first month?

The pace may vary with the size of the process, but the sequence below is a good standard for checking a proposal.

• Week one: interviews with the people who run the process, a survey of the systems and channels involved, and selection of the candidate workflow. Deliverable: draft process map.
• Week two: observation of the real process, sampling of cases and a record of how the work is measured today. Deliverable: baseline.
• Week three: inventory of data and possible actions, classification by risk, and a definition of where human approval applies. Deliverable: limits document.
• Week four: pilot design, success criteria, stop conditions and a handover plan. Deliverable: pilot charter and a decision meeting.

Notice what is not on the list: no agent talking to real customers. That can happen in the pilot, after the charter is approved. When a vendor starts with deployment, it skips exactly the steps that protect you.

What should the process map and the baseline look like?

The process map describes how the work actually happens, not how the manual says it happens. It should show who performs each step, in which tool, with what input, what the output is and where exceptions occur. A good map also marks the steps that involve judgment, because that is where AI needs the most care, and the repetitive, deterministic steps, which often can be solved with ordinary automation.

A checklist for evaluating the map you receive:

• Each step has an owner identified by role.
• The channels (WhatsApp, email, phone, spreadsheet, ERP, CRM) are listed, with what passes through each one.
• The most frequent exceptions are described, along with what the team does today.
• Fixed-rule steps are distinguished from judgment steps.
• The people who run the process have read the map and confirmed that it reflects reality.

The baseline comes right after and answers a direct question: how does this process behave today? It might be time to first response, rework, the number of cases that come back, time until a proposal goes out, or any indicator the company already tracks or can estimate with an honest sample. The consultancy should not invent attractive indicators. It should measure what matters to the process owner.

Without this record, the pilot ends with a feeling that things got better or worse, and nothing more. With it, you can compare. When reliable data is missing, building the baseline can itself be part of the work: recording the process for a short period, together with the team, before anything changes.

Which data and action limits should the document include?

This is the deliverable that most separates a careful consultancy from a tool showcase. The limits document answers two questions: what data can the AI see, and what actions can it take.

On data, the text should list the sources, the purpose of each use, the classification (personal data, sensitive data, confidential business information) and where processing happens. For Brazilian companies, this connects to the LGPD, Brazil's data protection law: purpose, necessity, legal basis, minimization and record keeping. The ANPD, Brazil's national data protection authority, publishes guidance that works as a reference for the conversation with your legal team. If the model runs outside the country, international data transfer comes into play, and that needs to be written down, not assumed.

On actions, the list should separate what the agent can do alone (check a status, answer a question using an already approved policy), what it can do only with human approval (grant a discount, change a record, send a proposal) and what it never does (decide on credit, termination or diagnosis). When an automated decision affects the data subject, it is worth reviewing Article 20 of the LGPD and the right to review with your legal team.

A few practices tend to show up in well-made documents:

• Minimum permissions: each tool receives only the access it needs.
• Decision logs: every response or action by the agent is recorded with the context used.
• A handoff point to a human defined by situation, not improvised.
• Handling of untrusted inputs: customer messages and documents can contain malicious instructions, and the OWASP guidelines for applications built on language models describe this risk.

To structure risk management in a recognized way, the NIST AI Risk Management Framework offers a shared vocabulary (map, measure, manage, govern) that helps organize the document without inflating it.

What must a pilot charter contain?

The pilot charter is the working agreement for the experiment. It turns the diagnosis into a small test with a beginning, a middle and an end. If you take only one document out of the closing meeting, make it this one.

Charter checklist:

• Chosen workflow: one real, bounded process, not the whole company.
• Objective and success metric, defined from the baseline and accepted by the process owner.
• Scope of data and actions, referring back to the limits document.
• Who takes part: the owner on the company side, who reviews, who approves exceptions.
• Evaluation method: test cases, samples reviewed by people and clear criteria for what counts as an error. Agent evaluation guides, such as those published by OpenAI and Anthropic, show how to build these case sets before going to production.
• Stop conditions: what forces the pilot to pause (an incorrect answer on a sensitive topic, a customer complaint, an integration failure).
• Logging and observability: what will be logged, who will read it and how often.
• Handover plan: documentation, access and training so the team can take over or shut it down.
• Final decision: expand, adjust or stop, with a date for the conversation.

If a pilot has no stop condition, it is not a pilot. It is a rollout without warning.

It is worth noting that Anthropic's documentation on building agents recommends starting with the simplest solution that works and adding complexity only when the need is demonstrated. The pilot charter is the place to apply that principle: one workflow, few tools, clear measurement.

What does this look like in an illustrative scenario?

Illustrative scenario: an electrical supplies distributor receives quote requests by WhatsApp and email. Salespeople copy the data into a spreadsheet and then retype it into the system. The owner wants to use AI to speed things up but does not know where to start.

In the first month, the consultancy interviews two salespeople and someone from finance, and finds that the bottleneck is checking product codes and delivery lead times, not the first contact. The map shows that reading the request is a repetitive step, while the discount decision requires the manager's judgment.

The baseline records, from a sample of recent requests, how long it takes between the request and the quote being sent, and how many quotes come back because of item errors. The limits document defines that the AI can read the message and propose a draft quote based on the catalog, but sends nothing to the customer without the salesperson's approval, and never changes a price. Customer data stays restricted to what the quote requires.

The pilot charter proposes testing a single channel with a small group of salespeople, comparing against the baseline, and stopping if the draft produces item errors on anything the salesperson considers critical. By the end of the month, the owner has material to decide. This is only an example of the format, with no numbers and no promise of results.

For teams in sectors with similar routines, there are practical articles on AI for solar energy companies and other segments on the blog, showing how the same reasoning adapts.

How do you apply the method, and which warning signs should you watch for?

The method Juan Carlo uses follows four verbs: map the current process and baseline, limit data and actions, pilot one real workflow with logging and an agreed metric, and hand over so the team can decide whether to expand, adjust or stop. The four deliverables of the first month correspond to the first three verbs and prepare the fourth. If you want to see how this translates into day-to-day work, read how Juan Carlo works with companies. When managed operation is needed, it is delivered by Be Human.

When evaluating proposals from any vendor, be wary when you see:

• A promise of results or guaranteed gains before any diagnosis.
• A choice of tool or model before the process is understood.
• No document covering personal data and the LGPD.
• A pilot with no metric, no logging and no decision date.
• Total dependence on the vendor, with no material for your team to take over.
• Language saying AI will replace the whole team, when what can be demonstrated is support for specific steps.

An honest proposal also admits that the outcome of the diagnosis may be not to pilot now, because the process is poorly defined, the data is not organized or the expected gain does not justify the risk. That is a legitimate result of the first month.

Frequently asked questions

Does a superintelligence consultancy deliver a working agent in 30 days? Not necessarily, and be wary of anyone who guarantees it without a diagnosis. The safer pattern is to deliver the map, baseline, limits and pilot charter, and only then build an agent for a bounded workflow. In simple cases, a restricted prototype may appear at the end, but as part of the approved pilot.

Do we need organized data before we start? You do not need everything ready, but you need to know where the data is, who is responsible for it and which parts can be used. Part of the first month's work is exactly to inventory this and point out what needs fixing before the pilot begins. If critical data does not exist or is inconsistent, the consultancy should say so clearly.

Who should take part in the first month on the company side? The process owner, one or two people who do the work day to day, and someone from IT or data protection, depending on the size of the company. Without the people who do the work, the map stays theoretical. Without someone accountable for data, the limits document stays incomplete.

What happens if the diagnosis shows it is not worth piloting? You still receive the map, the baseline and the risk analysis, which remain useful for future decisions. Stopping at this stage costs less than discovering the same problems with an agent already in production. A good contract treats this possibility as a valid outcome, not a failure.

Sources

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