Context Engineering and Memory for Business AI Agents
A business AI agent makes each decision from a limited set of instructions, records and prior events. Context engineering determines which evidence the model receives for the present step. Memory design determines which information may remain available after that step. The agent becomes dependable only when both designs preserve source authority, freshness, scope and correction rights.
An agent acts on the evidence placed before it
A business process may draw on a current customer record, an effective policy, an open task, a manager's approval and several permitted tools. The model does not examine every available source before each decision. The application selects a working set and places that information in the model's context.
That selection can determine the outcome. A clear instruction cannot compensate for an expired policy, the wrong customer's record or a tool description that conceals a consequential side effect. Prompt wording therefore addresses only one part of the implementation problem. The team must also control which evidence enters each decision and why the agent may rely on it.
Context is a decision packet, not a document store
The useful context for one step combines several types of information. Stable instructions define the agent's purpose and limits. Governed knowledge supplies applicable policy or procedure. Live records describe the current customer, asset, order or event. Tool definitions state which actions are available. Workflow state records completed steps, approvals and unresolved obligations.
These sources do not carry equal authority or change at the same rate. A policy owner may revise a compensation rule each quarter, while a room assignment can change during the conversation. The application should therefore assemble a fresh, step-specific decision packet from governed sources instead of placing a large collection of material in one prompt. More context is useful only when the additional information improves the decision.
Retrieval finds candidates; it does not establish authority
A retrieval system can rank passages that appear relevant to a request. However, semantic similarity does not prove that a passage applies to the customer, product, jurisdiction or date in question. A retired policy can resemble the current policy closely enough to rank well.
The application must therefore filter retrieved material through business identifiers and source rules. Each material item should carry its origin, version, effective period and scope. When two authoritative sources conflict, the agent should not choose the more fluent passage. The workflow should follow a defined source hierarchy or refer the conflict to the responsible owner.
Workflow state, memory and systems of record serve different purposes
An agent needs continuity, but continuity does not require one undifferentiated memory. Workflow state preserves the facts and obligations of the current case, such as an approval request, a transaction identifier or an unresolved action. Long-term memory retains selected information that may help in a later session, such as a consented communication preference. A system of record remains the authoritative source for current facts such as account status, inventory, entitlement or room assignment.
Confusing these purposes creates avoidable errors. Conversation history cannot prove that a payment was made, and a remembered room number cannot establish where a guest is staying today. The implementation team must decide which repository owns each fact before the agent is allowed to retrieve or retain it.
Retention requires an explicit business reason
Storing every conversation is not a memory strategy. The team should first identify the later decision that retained information will improve. It can then specify which fact may be extracted, whose information it is, how staff or systems will verify it, who may retrieve it and when it must expire.
The same rule applies when a platform automatically extracts preferences, summaries or prior episodes. Automated extraction reduces manual processing, but it does not decide whether the information is accurate, lawful to retain or appropriate for another purpose. Before long-term memory enters a business workflow, the implementation team must specify provenance, consent where required, access, correction and deletion.
Current evidence must overrule stale memory
Retained information may have been incomplete, mistaken or true only at the time it was recorded. The agent should therefore retrieve current authoritative data whenever a decision depends on a changing business fact. Memory can help locate the relevant source or personalise an interaction, but it should not silently replace that source.
The application also needs a rule for contradictions. It may update a remembered preference after confirmation, mark an earlier item as superseded or pause when two authoritative records disagree. Without that rule, memory can make the agent appear consistent while it continues to act on an error.
Long cases require selective compression
A long-running case produces messages, documents, tool results and intermediate decisions. Returning all of that material to the model increases cost and can obscure the instruction or evidence that matters now. The application may instead retain structured workflow facts, retrieve supporting documents when needed and compress older conversation into a shorter record.
However, compression discards detail. The team must test whether a summary preserves material decisions, accepted evidence, exceptions and unresolved obligations. A shorter context is safer only when omitted information cannot change the next authorised action.
A hotel fault shows how the sources must remain separate
Consider a guest who reports an air-conditioning fault after moving to a different room. The property system supplies the current stay and room. The maintenance system supplies the open work order and its status. The hotel's current service-recovery policy supplies the permitted response. Workflow state records whether an employee has approved an exception. A consented language preference may come from long-term memory.
Each source answers a different question. If the agent reuses the earlier room number from conversation history, it may send engineering staff to the wrong room. If it treats an acknowledged work order as completed, it may close the complaint before anyone repairs the fault. If it retrieves an expired compensation policy, it may offer a remedy that staff cannot honour.
The agent should therefore assemble the current decision packet again after the room move. It can use the language preference to communicate clearly, but it must obtain the room, repair status and permitted remedy from their authoritative sources. This separation lets hotel staff personalise the response without allowing remembered information to corrupt the hotel's operation.
Evaluation must inspect the evidence behind the action
An evaluation should vary the conditions that can break the context design. Test the agent with stale policies, similar customer names, missing records, conflicting sources, malicious instructions inside a retrieved document and a memory that contradicts a current record. The trace should show which items entered the model, why the application selected them and which source governed the final action.
The evaluation must then examine the business result. Did the agent identify the correct customer and case? Did it apply the current rule, protect restricted information, preserve unresolved obligations and refer an unresolvable conflict? These findings show whether context and memory support the process, rather than merely whether the model can repeat stored information.
How Marketways defines the context and memory design
Marketways begins with the decisions and actions in the target workflow. We identify the evidence each step requires, the authoritative source for every material fact and the conditions that make that evidence applicable. We then define the context map, retrieval filters, source hierarchy, workflow state, memory policy and conflict rules.
The resulting specification states what the agent may receive, retain and use at each consequential step. The implementation team tests those boundaries before deployment and after material changes. Business, data and engineering owners can then see when the agent has enough evidence to act and when it must retrieve a current record, request clarification or refer the case.