Your AI needs to know which decisions still apply

Yohei Nakajima argues that agents working inside a company need access to its rules, processes and decisions, while customer records can remain in the tools that already hold them. His CompanyOS idea includes a playbook that changes as the business makes decisions. I think a useful place to begin is with the exceptions a company has already agreed to.

Imagine a B2B service company that normally provides support during business hours. For a customer's product launch, it agrees to cover a particular weekend. Someone records that arrangement in a support ticket. The ticket is genuine evidence of a decision, but the agreement concerns that customer and that weekend. It says very little about what the company should offer the next customer.

An agent preparing a response could find that ticket alongside the standard support description. Both records may be accurate. To use them properly, it needs to understand the scope of the exception and which arrangement applies to the customer asking now. Making more of the archive searchable does not resolve that question by itself.

Someone in the business has to make the distinction clear. In this hypothetical case, I would want the exception to name the customer, the weekend covered and the person who agreed it. The current customer record should make the applicable support arrangement easy to find. The old ticket can remain available as history, with its limited purpose intact.

Nakajima's suggestion to keep the source of truth in existing business tools is useful here. If the customer agreement is maintained in the CRM or service system, I would want the agent to consult that record when preparing the response. Copying its contents into a separate knowledge store creates another version to keep current. A useful playbook can point to the relevant record and explain how to interpret it.

The date alone may be insufficient. A recently edited note could describe an old agreement, while an earlier decision still governs the work. I would want to know who made the decision and what it changed. If the team cannot establish which record applies, that is a question for the person responsible before the company makes a fresh commitment to the customer.

There is a different situation when an exception reveals a service the company wants to offer more broadly. Perhaps the launch support was useful enough to develop into a defined option. That needs a new business decision about what will be offered and under which conditions. A successful exception gives the team something to examine. The decision to turn it into a repeatable offer still belongs to the business.

Once that decision is made, the instructions used by the agent need to reflect it. The current service description and the relevant customer records should agree about what is available. Keeping the earlier decision as history can explain why the arrangement changed. It should also be possible to identify the decision that replaced it, so the agent has a clear route from the old record to the current one.

I would check this with a small internal exercise before relying on the arrangement. Give the agent the old support ticket and a request from another customer. Ask it to explain which support terms apply and show the records behind its answer. Then change the hypothetical policy and repeat the exercise. That tests whether the updated decision reaches the work the agent is preparing.

The exercise may expose a retrieval problem, an unclear instruction or a business decision nobody recorded. Those require different fixes. Adding another general instruction to be careful leaves the underlying question unresolved. The useful correction should make the relevant decision easier to find and apply when the next request arrives.

For a company beginning this work, I would choose a recent exception and follow it into the next similar task. Can the person or agent doing that task identify what was agreed, who it covered and whether it still applies? That gives the company a concrete starting point for a playbook its people and agents can use as the business changes.