Caio Pedroso

In an earlier essay, I used memory to describe the shared state an intelligent system can safely rely on: reconciled identities, definitions, provenance, and durable facts. I still think that layer is necessary. But it only answers what the system knows. It does not fully answer how the system should make a decision, what it is allowed to do, or how it should learn from the outcome.

Everyone is trying to give AI more memory. More context from previous conversations, more access to company data, more tools, and more freedom to act. The direction makes sense, especially as agents move from answering questions into doing real work. But memory is only useful when the system knows what to do with what it remembers. In most companies, the harder problem is not forgetting but the absence of a clear structure for making a decision.

Imagine a support agent handling a refund request from an important customer. It can retrieve the account, summarize recent conversations, identify the subscription plan, calculate the amount, and recommend an exception. The answer may sound sensible, but the moment a recommendation gets close to an action, a different set of questions matters. Which refund policy applies? Is the customer actually eligible for an exception? Does account value matter, and according to which definition? Who can approve the refund? What other options were considered? What should be recorded if the exception is granted, and what should the system learn if the customer still leaves a week later?

Most agent systems are not designed around those questions. They are designed to retrieve information, reason over it, and produce an answer. Adding more context can improve the answer, but it does not turn the process into a reliable decision. A system may know a great deal about a customer and still have no way to distinguish evidence from assumptions, policy from habit, or a suggestion from an action it is allowed to take. Without those boundaries, AI produces plausible text uncomfortably close to operational consequences.

The confusion starts with the way we talk about agents. An agent can reason, call tools, move across systems, and complete a multi-step task. Those capabilities are valuable, but they do not make the agent the operating system of a company. A good analyst earns their value not by answering questions quickly but by knowing where to look, which definitions apply, what evidence can be trusted, what trade-offs need to be made visible, and when a decision should be escalated. The same is true for an agent. The agent is the interface to a system of decisions, not the system itself.

The more useful question, then, is not how much an agent can remember, but what environment it is operating inside. It needs a model of the company that goes beyond documents and database tables. It needs to know what the important objects are, how they relate to one another, which logic applies to them, what actions are available, and who has permission to take those actions. Palantir calls a version of this an ontology, which is often described as a semantic layer or a model of the business. The phrase sounds abstract, but the underlying idea is practical. An ontology makes operational reality legible to software.

A customer is not only a row in a CRM. The customer is connected to contracts, invoices, support cases, products, employees, risk rules, and a history of decisions. A portfolio is not only a list of positions. It belongs to an account, serves a client with specific objectives, operates under policy constraints, and changes in value with market conditions. An order is connected to inventory, pricing, fulfillment, margins, service levels, and permissions. Once those objects and relationships are explicit, an agent no longer searches through a pile of information hoping to assemble a reasonable answer. It operates inside a defined environment.

The environment also needs logic. Companies make decisions using policies, calculations, models, thresholds, and institutional knowledge, but much of it lives in spreadsheets, old documents, side conversations, or the judgment of a few experienced people. An agent may retrieve the relevant material and still fail because no one has decided which rule wins when sources disagree. Revenue can mean booked revenue, recognized revenue, recurring revenue, or cash collected. Risk can mean volatility, probability of default, regulatory exposure, or simply the chance that a manager will be uncomfortable. More memory does not resolve competing definitions. The system needs an explicit way to decide which definition applies in a given situation.

A real decision system connects the facts to the logic, the logic to the available alternatives, and the alternatives to an action with clear boundaries. It should know what can be suggested, what can be prepared, what requires approval, and what may be executed automatically. It should also leave a record of how the recommendation was produced. The goal is not to turn every interaction into a bureaucratic workflow. The goal is to make enough of the decision visible so intelligence can become operational without becoming reckless.

Consider a pricing exception. A sales agent may see a large opportunity, notice that the customer is asking for a discount, and recommend a lower price. A decision system would go further. It would identify the current price, expected margin, contract length, payment terms, customer segment, renewal potential, and any precedent created by similar deals. It could compare a direct discount with alternatives such as a longer commitment, reduced scope, delayed implementation, or different payment terms. If the proposed exception falls within the salesperson’s authority, the system may prepare the quote. If it exceeds the threshold, it can stage the decision for a manager, show why approval is needed, and preserve the reasoning after the choice is made.

The distinction becomes even clearer in finance. Suppose someone asks whether a portfolio should be rebalanced. An agent can look at the holdings, identify a concentration, and produce a persuasive explanation. It may even reach the right conclusion. A decision system still has more work to do. It needs to know which account and client are involved, which investment policy applies, whether the market data is current, how exposure and liquidity are calculated, what tax consequences may follow, and whether a proposed trade creates a different risk elsewhere.

A useful output would not be a paragraph saying that rebalancing could be sensible. It would be a scenario comparing the current portfolio with one or more proposed states. The user should be able to see which risks fall, which risks increase, how liquidity changes, what tax implications exist, which policy checks passed, which evidence was used, and which approvals are required. The system may then stage the trade without executing it, giving an advisor the ability to review, change, approve, or reject the proposal. Choosing not to act should also be recorded as a decision, because in many cases inaction is deliberate rather than accidental.

The same shape appears across a company. Underwriting exceptions, procurement choices, support escalations, supply-chain interventions, hiring decisions, and product changes all combine evidence, rules, alternatives, permissions, action, and an outcome. The details vary, but the structure is remarkably consistent. Someone is trying to change the state of the world based on incomplete information and a set of constraints. An agent becomes useful when it can help navigate the full path, not only produce language at the beginning of it.

Memory becomes much more valuable once decisions are structured in this way. Chat history can tell a system what someone said. A decision record tells it what mattered. It shows which evidence changed the recommendation, which option a person rejected, which constraint they cared about, when they preferred speed over completeness, and when they wanted the system to push back. It also captures what happened after the action, which is often the only way to know whether the decision was good.

Over time, the system can learn how to work with a person without quietly changing the underlying truth. Personalization may affect which trade-off appears first, how much detail is shown, when a caveat should be emphasized, or when confirmation is necessary. It should not change the data, the governing policy, or the evidence behind the recommendation. Shared truth needs to remain inspectable, while the experience around it can adapt to the individual. The separation matters because a system becomes dangerous when preference and reality are blended together.

Every decision also creates data that did not exist before. A question was asked, evidence was gathered, logic was applied, alternatives were compared, and someone approved, changed, or rejected the recommendation. An action followed, or a deliberate choice was made not to act. Later, an outcome appeared. Together, those events form a decision ledger, and the ledger is more valuable than a long archive of conversations because it preserves the relationship between judgment and consequence.

The ledger helps an organization see where its rules are unclear, where data is unreliable, which decisions repeatedly require escalation, and which interventions consistently produce good outcomes. It gives employees a way to inspect the system and gives builders a better way to evaluate it. Instead of asking only whether an answer sounded correct, they can examine whether the right evidence was used, whether the recommendation respected the relevant constraints, whether the approval path worked, and whether the action improved the outcome. Evaluation moves from language quality to decision quality.

A durable advantage starts to form around the accumulated history of those decisions. Models can be replaced, interfaces can be copied, and tool-calling capabilities will become common. A governed record connecting evidence, logic, human judgment, action, and outcomes is harder to recreate. The same is true for personalization built from real decisions. A competitor may import the customer data, but it will not immediately know which exceptions a team tends to approve, which risks a manager considers unacceptable, or how a particular user prefers to evaluate a trade-off.

Agents will continue to become cheaper and more capable. They will plan better, use more tools, and complete longer workflows. None of those improvements remove the need for an operational model underneath them. In fact, greater autonomy makes the need more urgent, because every additional action increases the cost of ambiguous definitions, weak permissions, and missing decision history. The agent matters, but the durable product sits in the environment that makes its work trustworthy.

The most interesting AI systems will not only remember more or answer better. They will understand what a question is connected to, which version of reality applies, what logic should be used, which alternatives deserve consideration, and what can safely happen next. They will make decisions easier to inspect before an action and easier to learn from once the outcome is known.