A 90-Day Plan to Prepare Your Company for Far More Capable AI

To prepare your company for far more capable AI, build the parts any model will depend on instead of betting on one model. Use 90 days in three phases: organize company memory so an agent can read it, set permissions so an agent cannot exceed its role, and build evaluations so you can tell whether a new model is actually better. Those three assets keep their value whichever systems arrive next.

Key takeaways

• Plan around what a stronger model will need from you: accurate context, clear limits and a way to check its work.
• Days 1 to 30 are for memory: write down how one role works, in formats you own, with a named owner for each source.
• Days 31 to 60 are for permissions: start from read-only, grant actions in tiers and tie each widening of access to evidence.
• Days 61 to 90 are for evaluation: a set of real cases you can rerun on any model, including cases where the right answer is to escalate.
• Finish with a day 90 decision about what to keep, widen or pause, and who owns each area.

Why prepare for capability you cannot forecast?

Nobody can tell you which capabilities arrive next or when, so planning around a specific model is a poor use of 90 days. A better question is what a much more capable system would need from your company that it cannot supply itself. The answer is the same for a modest assistant and a very strong one: accurate context, clear limits and a way to check its work.

A stronger model does not remove those needs. It raises the stakes of each. A model that reads disorganized notes will act on them with more confidence. One with broad access can do more damage when an instruction is wrong. One whose output nobody checks can be wrong at greater volume. Capability amplifies whatever it stands on.

The three phases below each produce something that outlasts any model: a memory layer, a permission model and an evaluation set. They are the practical core of a company superintelligence layer that improves as models do. The NIST AI Risk Management Framework offers a shared vocabulary (govern, map, measure, manage) that fits this sequence well if your leadership wants one.

Days 1 to 30: how do you make company memory portable?

Memory is the asset most companies underestimate. A model can be swapped in an afternoon, but the knowledge that makes it useful took years to accumulate and usually lives in people's heads, old email threads and half-maintained wikis. A stronger model will read what you give it faster and trust it more, so the quality of that material matters more as models improve, not less.

Do not try to capture the whole company. Choose one role, such as a support lead, a procurement coordinator or an operations analyst, and build memory for that role only. The discipline transfers to the next role. Anthropic's writing on context engineering makes the same point from the model side: give the agent a small set of high-quality information that lets it do the work, not everything you own.

• Write the role's job on one page: what it handles, what it never handles and who it hands off to.
• List every source the role relies on: documents, spreadsheets, inboxes, systems, and the people who answer questions nobody wrote down.
• Name one human owner per source, responsible for keeping it current.
• Turn unwritten rules into short documents: procedures, exceptions, tone, definitions and escalation triggers. Record the reason behind each rule, not only the rule.
• Separate stable principles from facts that change often, so the changing parts can be refreshed without rewriting everything.
• Keep the material in plain, exportable formats you control. If a tool disappeared tomorrow, you should be able to move the content elsewhere.
• Mark what is confidential, personal or regulated, and decide where it may be stored and processed.
• Test retrieval: ask ten questions the role really receives and check that each answer can be traced to a source.

The last step matters most. If an answer cannot be traced, a stronger model will simply produce a more fluent version of a guess. Also confirm you can restore the memory after a failure; AI agent backup and restore covers what to save and how to test it.

Days 31 to 60: how do you set permissions that survive a stronger model?

Capability and authority are different things, and this phase keeps them apart. A more capable model should earn more access through evidence, not receive it because it sounds more competent. Treat permissions as a design decision you make once, review on a schedule and widen deliberately.

Assign every action the agent might take to one of four tiers:

• Read only: the agent looks things up and answers.
• Draft: the agent prepares work and a person sends or saves it.
• Act with approval: the agent performs the action after a named person approves it.
• Act alone: the agent acts without approval, only inside narrow and reversible limits.

Then work through these steps:

• Start every action at the lowest tier and deny by default, a principle OWASP's authorization guidance states plainly.
• Give the agent its own identity and credentials, never a shared login or a colleague's account.
• Limit each credential to the systems, records and operations the role needs, and set expiry where the system allows it.
• Separate reading from writing, and writing from anything that moves money, deletes data or contacts customers.
• Treat outside content such as emails, web pages and uploaded files as data, not instructions, because text from outside can carry commands meant to redirect the agent.
• Log every action with who approved it, so an incident can be reconstructed.
• Write down the evidence required to move an action up a tier, for example a run of reviewed outputs with no serious errors.

Schedule the review before you need it. The steps in quarterly AI agent permission review give you a repeatable format, and the result is a permission table a new model can be dropped into without anyone renegotiating trust from scratch.

Days 61 to 90: how do you build evaluations that judge any new model?

Evaluation turns the feeling that a new model seems better into a decision. Without it, you will either adopt every release on enthusiasm or avoid all of them out of caution, and both cost you. Anthropic's guidance on evals for agents describes the core idea: a repeatable set of tasks with a defined way to judge each outcome.

• Define the success criterion in plain words and in something observable. For a request-triage role, it might be requests routed correctly without rework, as judged by the team lead. The guide to AI agent pilot success criteria helps here.
• Collect real cases from the role's history, paired with the outcome a competent person would have chosen. Remove personal data first.
• Include hard cases: ambiguous requests, missing information, conflicting sources and cases where the right behavior is to stop and ask.
• Add safety cases: attempts to make the agent exceed its permissions, and instructions hidden in content it reads.
• Decide who grades. Use rules for what can be checked mechanically and human review for judgment.
• Run the set on your current model to establish a baseline, and store each result with the date, model, memory version and permission settings.
• Record cost and speed next to quality, because a better answer that arrives too slowly may not be better for the business.
• Rerun the set whenever the model, the memory or the tools change.

Keep the set growing. Every real failure becomes a new case. Over time this becomes the most valuable piece of the plan, because it encodes what good means in your company, and no vendor can supply that.

What does it look like when a stronger model arrives?

This is an illustrative scenario, not a report of a real engagement.

A mid-sized distributor has an agent that drafts replies to order status questions. At the end of 90 days it has a memory folder for that one role with named owners, a permission table in which the agent drafts and a person sends, and a set of real past cases. A new model becomes available.

Instead of a debate, the operations lead reruns the set. The new model handles ambiguous requests better but is more willing to promise delivery dates the memory does not support. The team keeps the draft tier, adds a rule about commitments and three new cases, and reruns. Only after the results hold does it discuss letting the agent send routine replies alone. The decision took days, not a re-implementation, and everyone could see why it was made.

How does Be Human's managed approach handle this?

A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which maps directly onto the three phases above. Managed operations then carry the recurring work: monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. Memory and context stay under your control and in portable form, so changing models is a reviewed change and not a rebuild. Service is remote, in English and Portuguese.

What should you decide on day 90?

The plan ends with decisions, not a launch. Put these on one page and give each an owner:

• Whether the first role's memory is trustworthy enough to extend to a second role.
• Which actions have earned a higher permission tier, and which stay where they are.
• Who owns memory, permissions and evaluations after the project, including an executive sponsor who can decide on access and budget.
• When the next permission review and the next evaluation rerun will happen.
• What would cause you to pause, and how you would pause without losing the work already done.

If you cannot answer the last item, the memory is probably not portable enough yet. Fix that before widening anything.

To find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Do we need to wait for superintelligent AI before starting? No. The work in this plan pays off with the models available today, because it makes a current agent more accurate and safer. It also means a stronger model meets a company that can actually use it. Waiting only delays the slowest part, which is organizing what your company knows.

Is this plan realistic for a small team? Yes, if you keep the scope to one role. A small team can write a focused memory folder, a one-page permission table and a modest set of cases within the time allowed. The plan scales by repeating it for the next role, not by starting bigger.

Should we fine-tune a model on our data instead of building memory? Usually start with memory the agent retrieves at the time of the task. It can be corrected by editing a document, restricted by permission and moved to another model. Fine-tuning ties knowledge to one model and is harder to correct, so consider it later, once your evaluations show a gap that retrieval does not close.

Who should own this plan? An executive sponsor who can decide on access and budget, plus one named owner each for memory, permissions and evaluations. The people who do the role day to day should review the evaluation cases, since they know what a good result looks like.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.