Company Culture for Advanced AI: Habits That Prepare Your Team

Company Culture for Advanced AI: Habits That Prepare Your Team

Company culture for advanced AI is the set of habits that leads a team to document what it knows, review what the agent delivers and learn from every mistake. With those habits, the technology can grow more capable without control shrinking. It does not depend on which model the company uses today. It depends on the team being able to explain its work, define what is acceptable and correct course quickly.

Key takeaways

• More capable agents demand more clarity, not less: if you cannot describe your own process, you cannot delegate it.
• Living documentation (rules, exceptions, examples) is the asset that makes any agent useful and any model switch less painful.
• Review must be proportional to risk and must have an owner, otherwise it becomes a rubber stamp or a bottleneck.
• Agent errors should become test cases and rule updates, not stories told in the hallway.
• Culture is built with small, repeated routines, starting from one real workflow, not with a single training session.

Why does culture matter more than the tool?

AI tools change at a pace that is hard to follow. What changes slowly is how a team works: where it records decisions, who approves what, what happens when something goes wrong. When a company has those elements, switching models or widening an agent's scope is a technical adjustment. When it does not, every change becomes a crisis of trust.

There is also a practical reason to think about this now. It is reasonable to assume (a hypothesis, not a fact) that agents will be able to carry out longer and more ambiguous tasks than they do today. A team whose processes are implicit, and depend on the memory of two or three people, will stumble exactly when the agent becomes more capable, because the agent will start acting in areas where nobody wrote the rules down.

It helps to separate the philosophical debate from the operational work. If you want to understand what superintelligence is and is not before deciding anything, read about superintelligence myths that get in the way of business decisions. The point here is simpler: the habits that serve a reasonable agent today are the same ones that protect the company in front of a much better agent tomorrow.

Which documentation habits prepare the team?

Documenting does not mean writing long manuals that nobody opens. It means keeping, in a known place, the minimum a new colleague (human or agent) would need to do the work safely. Anthropic's documentation on long-running agents, for example, shows how progress files and handoff records help an agent resume work between sessions. The same principle applies to teams: what is not written down is lost at shift change.

The habits that pay off most are these:

• Record the goal of each workflow in one sentence, with the expected outcome and who is accountable for it.
• Keep a list of real exceptions: cases where the default rule does not apply, and why.
• Save good and bad examples of output, with a short note explaining the difference.
• Write down what the agent may do alone, what needs approval and what is forbidden.
• Date and attribute rule changes, so you know who changed what and for which reason.
• Separate what is company policy, what is one person's preference and what is still a hypothesis.

One important caution: documentation that contains customers' personal data calls for attention to LGPD, Brazil's data protection law. Examples should be anonymized, and access to the material should follow the same criteria as access to the original data. If the team does not yet have rules for AI tools, a good starting point is a company policy for employee ChatGPT use that says what can and cannot go into each tool.

When the team uses coding assistants or terminal automations, part of this documentation can become reusable instructions. That is the case with Claude Code skills, which let you package the team's way of doing a task so it does not depend on each person's memory.

How should review work when the agent gets better?

The most common mistake is treating review as a single step, identical for everything. In practice, review should be proportional to risk. An internal draft summary can get a quick check. A reply to a customer about a warranty, a charge or a contract deadline deserves human approval before it goes out. An irreversible action, such as canceling an order or changing a customer record, requires an explicit limit.

A simple decision guide, in list form:

• If the error affects a customer's money, health, rights or reputation, human review comes first and is mandatory.
• If the error is correctable and visible, review can be done by sampling, with someone responsible for checking the log periodically.
• If the error is cheap and reversible, a decision record that allows auditing later is enough.
• If the decision directly affects a person in an automated way, keep in mind the right to review provided by LGPD, a topic we cover in our text on automated decision-making and the right to review.
• If nobody can classify the risk, treat it as the highest level until you map it better.

The reviewer also needs the right conditions. Reviewing well requires knowing what context the agent had, which rule it applied and what it did not know. Without a record, the reviewer sees only the result and ends up approving on impression. With a record, review becomes learning: you can see where the rule failed and fix it at the source.

As the agent makes fewer mistakes, a new risk appears: the reviewer relaxes. A mature culture fights this explicitly, with sampled reviews even when everything looks fine and with the freedom for anyone to pause a workflow when something looks off.

How do you turn mistakes into team learning?

Teams that learn treat an agent's error as information about the process, not as one person's failure. That requires an environment where reporting a problem is safe. If an employee fears being blamed for letting the agent get something wrong, they hide the case, and the company loses its most valuable data.

A routine that works is a short, blameless incident review with four questions: what happened, which rule or piece of information was missing, what did we change, and how will we know it worked. The answer to the last question is what closes the loop. Every relevant error should become a test case that runs whenever the agent or the rule changes. Anthropic's guidance on agent evaluations and OpenAI's evaluation guide both address this logic: evaluate in a repeatable way, with cases that represent real use.

To test without exposing customers, the ideal is a separate environment. We cover this in mock tools for testing AI agents in a safe sandbox, and the central idea is that nobody needs to learn from an error in production when it can be reproduced beforehand.

How do you measure progress without turning it into surveillance?

A habit only lasts if the team sees value in it. Measuring how many people used AI, or how long each person spent in the tool, usually breeds distrust and defensive behavior. It is more useful to measure the process: is the workflow clearer, has rework dropped, are exception cases documented, are reviews happening on time. We go into this in how to measure AI productivity without surveillance on your team.

The agreement must be transparent. The team should know what is recorded, for what purpose and who sees it. The agent's decision logs are about the agent and the process, not about the individual performance of whoever reviews.

Practical plan: how to start with one real workflow

This is a lean outline for starting the habits without building a large program:

• Choose a workflow with reasonable volume and controlled risk, for example triage of support requests or preparation of proposals.
• Describe the current workflow on one page: input, steps, decisions, exceptions, owner and how the result is measured today.
• Define what the agent may do, what needs approval and what stays out of reach.
• Gather a few real, anonymized examples of easy, difficult and edge cases.
• Agree on a success criterion the team accepts before starting, and how it will be measured.
• Run the pilot with a record of each decision and human review proportional to risk.
• Hold a short, periodic review of errors, updating rules and test cases.
• At the end of the pilot, decide together: expand, adjust or stop.

Illustrative scenario

Imagine, as an illustrative scenario, a services company that uses an agent to answer customer questions on WhatsApp. At first, the refund rules exist only in the coordinator's head. The agent answers according to what was written in its prompt, and one day it gives a reply that contradicts an exception only she knew about.

The team then builds a habit: the coordinator records the exception on a rules page with a date and a justification, the case becomes a test, and the agent starts routing any non-standard refund request to a human. Weeks later, when the company decides to switch models, the team runs the same cases and quickly sees what changed. The switch does not depend on anyone remembering everything. That is the value of culture: the memory of the operation no longer lives in one person.

How the map, limit, pilot and transfer method applies

The method we use in consulting reflects these same habits. Mapping is documenting the current process and the starting point. Limiting is defining the data, tools and actions allowed, with human approval where the risk calls for it. Piloting is running one real workflow with records and an agreed success criterion. Transferring is handing the operation to the team along with the documentation, the tests and the review routines, so the company can decide on its own whether to expand, adjust or stop. You can read more about how Juan Carlo works with companies.

As a risk management reference, the NIST AI Risk Management Framework organizes governance, mapping, measurement and management practices that fit well with this approach, without requiring a heavy structure to get started.

Frequently asked questions

What is company culture for AI?

It is the way a team documents, reviews and learns when working with AI systems. It includes clear rules about what the agent may do, an owner for each decision and routines for correcting errors. It is less about enthusiasm for technology and more about working discipline.

Do I need to worry about superintelligence to build this culture?

Not necessarily. The habits of documenting, reviewing and learning apply to today's agents and are likely to apply to more capable ones. As for superintelligence itself, treat it as a topic to follow and a hypothesis, not as a premise for operational planning.

Where do I start if the team is small?

Choose a single workflow and write one page about it, with rules, exceptions and an owner. Run a pilot with a record of decisions and a short, periodic review of errors. In small teams, the advantage is that one person can usually keep the documentation current without bureaucracy.

How do I keep human review from becoming a rubber stamp?

Set the level of review by risk and give the reviewer the context the agent used, not just the result. Sample outputs even when everything looks fine and let anyone pause the workflow. Track the cases where the reviewer corrected the agent, because they show where the rule needs to improve.

Sources

• NIST: AI Risk Management Framework
• Anthropic: Demystifying evals for AI agents
• Anthropic: Effective harnesses for long-running agents
• OpenAI: Evals guide