# AI agent context, memory and data infrastructure The context, retrieval, memory and provenance layers forming around agent systems, their suppliers and their unresolved control boundaries. Source: https://aecon.ai/guides/ai-agent-context-memory-data Author: Agentic Economy Published: 2026-09-13 Updated: 2026-09-14 **Chapter 5 of The Hitchhiker's Guide to the Agentic Economy** [Report hub](/guides/hitchhikers-guide-agentic-economy-2026) · Previous: [models, inference and compute](/guides/ai-models-inference-compute-agents) · In this chapter: [the context stack](#section-the-seven-parts-of-an-agents-context) · [market map](#section-who-supplies-context-memory-and-data) · [retrieval](#section-retrieval-is-a-supply-chain) · [memory](#section-memory-is-a-governed-record-not-a-personality-trick) · [Australia](#section-the-australian-data-question) · [context contract](#section-the-emerging-agent-context-contract) ## Our view An agent does not become dependable by knowing everything. This chapter proposes four requirements to test: relevant information for the current job, separation of instruction from evidence, enforced retrieval authority and a trace of what influenced the result. Their effect on acceptance, cost and incidents must be measured in the deployed system. **Context** is the selected information available to an agent during a current decision. **Retrieval** is the process that finds external records for that context. **Memory** is retained state that can be made available in a later session or job. **Provenance** records where information came from, how it changed and which activity or actor produced it. These terms are often collapsed into “the agent's knowledge”. That is commercially dangerous. A large model context window is temporary capacity. A vector database is a search component. A connected CRM remains a system of record. A memory service persists selected state. None of them, by itself, establishes that a fact is current, permitted or true. > **Key Takeaways** > > - Long context is not memory, and memory is not a substitute for a system of record. > - Retrieval quality depends on ingestion, permissions, freshness, ranking and source quality, not only embeddings. > - Access rules constrain the candidate records before semantic search returns them to the model. > - Every durable memory needs an owner, source, write rule, expiry rule and deletion path. > - The useful cost unit is context cost per accepted job, including retrieval, storage, model tokens, errors and review. > - Personal information in both agent inputs and generated or inferred outputs is a privacy design issue for Australian organisations. This chapter uses provider and official documentation checked on 13 September 2026. Product names, preview status, pricing and retention terms can change. Examples establish documented capability, not product quality or market adoption. ### Sources and scope Agentic Economy compiled the market map from the primary provider and official sources cited in this chapter. The research method records product capability separately from independent evidence of adoption or outcomes. Product records were checked on 13 September 2026; older standards are used only where their definitions still apply. [About Agentic Economy](/about) explains the publication and its Australian focus. Readers can submit source corrections through the [contact page](/contact), where the editorial record can be checked before an update is made. ## Context is becoming a distinct infrastructure market The category now spans data connectors, ingestion pipelines, search and retrieval, vector and graph databases, managed memory, permission-aware retrieval and provenance. Cloud providers increasingly bundle these functions. Specialist companies continue to compete where retrieval quality, portability, memory lifecycle or observability remains difficult. The market is converging on a shared architecture but not a shared product. Context windows hold temporary working information. Retrieval systems select external records. Memory products persist chosen state. Systems of record retain authoritative business facts. We expect the durable category boundary to form around governed access and provenance, not around the vector database alone. ## The seven parts of an agent's context Context is assembled for a job. A practical stack contains seven different kinds of information. | Context component | What it tells the agent | Typical source | Primary risk | | --- | --- | --- | --- | | **Objective** | The result to produce and the stopping condition | Job request, workflow state or customer order | Ambiguous or conflicting goals | | **Policy and authority** | What the agent may do, spend, disclose or change | Identity system, policy engine, approval record | Instructions mistaken for permission | | **Current interaction** | What has happened in this conversation or run | Session history and tool results | Important constraints displaced by noise | | **Business state** | The current customer, order, account or operational record | CRM, ERP, ticketing, finance or line-of-business system | Stale copy treated as the system of record | | **Retrieved knowledge** | Relevant policies, research, manuals or prior cases | Search engine, knowledge base, file store or database | Irrelevant, untrusted or unauthorised records | | **Retained memory** | Selected state from earlier sessions or jobs | Managed memory service or application database | False, sensitive or obsolete memories | | **Working material** | Plans, intermediate calculations and temporary files | Runtime, sandbox or scratch store | Leakage, uncontrolled retention or reuse | The distinction matters because each component needs a different control. Policy normally outranks a user preference. A current account balance comes from the banking system, not from a memory written last week. A research source can inform a recommendation without being permitted to change a customer record. Temporary working files may be useful for one run and inappropriate to retain afterward. ### The model context window is a scarce working surface A model's context window limits the material it can consider in one request or managed interaction. Larger windows make longer documents and histories possible, but they do not decide what deserves attention. Excess context can add token cost, latency, conflicting instructions and irrelevant evidence. Context management therefore has two jobs: 1. preserve the objective, policy and facts that must not be lost; and 2. remove, summarise or retrieve other material without changing its meaning. Provider tooling increasingly addresses this operating problem. Anthropic documents prompt caching for reused context, tool search that loads tool definitions on demand, programmatic tool calling that can collapse intermediate rounds, and context editing that removes older tool results ([Anthropic, "Manage tool context"](https://platform.claude.com/docs/en/agents-and-tools/tool-use/manage-tool-context)). These mechanisms can reduce repeated tokens or context pressure. They do not prove that a summary is faithful or that a retrieved record was authorised. ### Long context is not memory Long context lets a model process more information during a current interaction. Memory persists selected information for later use. Retrieval locates records that sit outside the immediate interaction. A system can use any combination of the three. | Requirement | Long context | Retrieval | Memory | | --- | --- | --- | --- | | Read one large contract now | Strong fit | Optional | Poor fit | | Find the latest approved policy | Weak alone | Strong fit | Risky as authority | | Recall a stable user preference next month | Expensive alone | Possible | Strong fit with consent and controls | | Obtain the current invoice status | Poor fit | Query system of record | Do not rely on memory | | Reconstruct why an action occurred | Insufficient | Needs source records | Needs provenance and audit records | The architectural centre of gravity is clear: authoritative state remains in the authoritative system, agents retrieve it when required, and memory provides continuity rather than an ungoverned duplicate of the business. ## Who supplies context, memory and data The supply chain crosses model platforms, cloud agent services, search and database vendors, enterprise applications, connector platforms, external data providers and observability systems. Participants often span more than one category. | Market layer | Representative participants | What the layer supplies | What it does not settle | | --- | --- | --- | --- | | **Model-native retrieval** | [OpenAI Retrieval and file search](https://platform.openai.com/docs/guides/retrieval), Anthropic tools and connectors, Gemini grounding products | Hosted ingestion, indexing, search and model integration | Business permissions, source authority and application acceptance | | **Cloud knowledge services** | [Amazon Bedrock Knowledge Bases](https://docs.aws.amazon.com/en_en/bedrock/latest/userguide/knowledge-base.html), [Google RAG Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-overview), Microsoft Foundry file search and Azure AI Search | Managed ingestion, retrieval, cloud identity and model integration | Whether the source set is correct or the result is fit for the job | | **Managed agent memory** | Amazon Bedrock AgentCore Memory, Google Vertex AI Memory Bank, Microsoft Foundry memory stores and Anthropic managed-agent memory | Cross-session retention, extraction, search and lifecycle APIs | Consent, organisational recordkeeping and the truth of a remembered statement | | **Search and vector stores** | Pinecone, Weaviate, Elastic, MongoDB Atlas, PostgreSQL extensions and cloud databases | Semantic, lexical or hybrid retrieval; metadata filters; storage | End-to-end authorisation unless the application supplies it correctly | | **Enterprise systems** | Microsoft 365, Google Workspace, Salesforce, ServiceNow, SAP, Atlassian and industry systems | Operational records, permissions, workflows and source-of-truth state | A uniform agent interface or reliable semantic ranking | | **External information services** | Search APIs, research databases, market data, maps, news and specialist datasets | Current or licensed external records | Permission to reuse, accuracy, completeness or customer-specific relevance | | **Connectors and tool gateways** | MCP servers, integration platforms and provider connector catalogues | Authentication and a callable interface to data or applications | Least privilege, provenance and acceptable action policy by default | | **Provenance and observability** | Data catalogues, lineage systems, agent traces and audit stores | Records of sources, transformations, access and use | Whether the underlying decision was correct or fair | This is a market map, not a product ranking. Each layer is assessed by the responsibilities included in the product and those that remain in the application. ### Managed products are converging, but not identical OpenAI's current Retrieval API performs semantic search over vector stores. Files added to a store are automatically chunked, embedded and indexed; search results include chunks, similarity scores and the originating file. The service also supports file attributes for filtering and hybrid weighting between semantic and text matching ([OpenAI, "Retrieval"](https://platform.openai.com/docs/guides/retrieval)). Its file-search tool combines semantic and keyword search before model generation ([OpenAI, "File search"](https://platform.openai.com/docs/guides/tools-file-search)). Google's RAG Engine documents a sequence from ingestion and transformation through indexing, retrieval and generation. Its source options include local files, Cloud Storage and Google Drive ([Google Cloud, "RAG Engine overview"](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-overview)). Amazon Bedrock Knowledge Bases similarly manages data-source ingestion and retrieval for proprietary information ([AWS, "Knowledge bases for Amazon Bedrock"](https://docs.aws.amazon.com/en_en/bedrock/latest/userguide/knowledge-base.html)). The products reduce implementation work. They do not make retrieval interchangeable. Supported source types, chunking controls, ranking, deletion behaviour, regional availability, security features and pricing differ. A service may also be in preview. Microsoft, for example, currently labels its Foundry managed memory solution as preview and documents conversation, user-profile and procedural-memory options plus a default time-to-live setting ([Microsoft, "Memory in Foundry Agent Service"](https://learn.microsoft.com/en-gb/azure/ai-foundry/agents/concepts/what-is-memory?preserve-view=true&view=foundry)). The procurement record retains that product state. ## Retrieval is a supply chain Retrieval-augmented generation, usually shortened to RAG, supplies selected external information to a model before it generates or acts. The acronym hides the work required to turn a source into reliable context. ```text source system -> acquire under an identity and licence -> parse and normalise -> split, label and index -> apply tenant, role, purpose and time filters -> retrieve lexical and semantic candidates -> rerank and select -> attach source and freshness metadata -> place records in model context -> answer or act -> log use, citation and outcome ``` Each arrow is a potential market and failure boundary. ![A water lock with separated chambers illustrates how identity and permission boundaries should constrain records before retrieval.](/media/editorial-library/water-lock-full.webp) ### Ingestion determines what can be found A source may be a PDF, web page, database row, email, ticket, recording or API response. Parsing has to preserve useful structure such as headings, tables, page numbers, dates and access labels. Chunking then creates retrieval units. Units that are too small lose context; units that are too large dilute the relevant passage and consume more model tokens. The record also needs metadata. At minimum, an enterprise corpus usually needs: - source identifier and canonical location; - source owner and record class; - created, effective, modified and ingested dates where available; - tenant, account, role or group access labels; - geographic or contractual handling restrictions; - version and supersession relationship; - retention and deletion rule; - content licence or reuse terms; and - parser, embedding and index version. Without this metadata, search may still return semantically similar text. The application cannot reliably decide whether that text is current, permitted or attributable. ### Search quality is not one number Lexical search finds matching words and identifiers. Semantic search uses embeddings to find related meaning even when words differ. Hybrid retrieval combines signals. Reranking scores a smaller candidate set with another model or method. Structured queries retrieve exact fields from business systems. Different jobs need different mixtures. A product-code lookup benefits from exact text. A policy question can benefit from semantic search constrained to the effective policy version. A customer balance depends on a structured query against the source system, not a vector similarity result. Retrieval quality precedes prose quality. A labelled set of representative questions reveals whether the necessary source appeared in the eligible candidates, whether an unauthorised source appeared, whether the selected source was current and whether the final answer or action cited the record actually used. ### Permission filtering belongs before the model Retrieving every record and asking the model to ignore prohibited ones is not an access-control design. The search boundary first restricts candidates by tenant, user, role, purpose, region and time. Semantic ranking then runs within the eligible set. This is practical, not theoretical. OpenAI documents attribute filters applied before semantic search. MongoDB Atlas Vector Search documents pre-filtering on indexed fields. Pinecone recommends a namespace per tenant for multitenant applications and notes that metadata filtering within a shared namespace has different isolation, cost and latency tradeoffs ([OpenAI, "Attribute filtering"](https://platform.openai.com/docs/guides/retrieval#attribute-filtering); [MongoDB, "Vector Search pre-filtering"](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-stage/); [Pinecone, "Implement multitenancy"](https://docs.pinecone.io/guides/index-data/implement-multitenancy)). Those features are building blocks. The application still has to translate the signed-in person's authority into correct filters and prevent an agent from changing those filters through untrusted instructions. ### Retrieved content is data, not command Web pages, emails and documents can contain text that looks like instructions to a model. When an agent can act, a malicious or accidental instruction inside retrieved content can attempt to redirect the task, disclose data or invoke a tool. The operating hierarchy places policy and explicit delegated authority above retrieved content. Untrusted material remains labelled, tool permissions remain narrow, action arguments are validated and consequential actions require approval. Australia's cyber-security guidance treats the agent harness, including tools, memory and data sources, as a control boundary rather than treating model output in isolation ([Australian Signals Directorate, "Agentic AI harnesses"](https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/agentic-ai-harnesses)). ## Memory is a governed record, not a personality trick Persistent memory can make an agent continuous across sessions. It can also preserve a misunderstanding, infer sensitive information, cross customer boundaries or keep data longer than intended. There is no universal memory taxonomy across products. A useful operating distinction is: | Memory type | Example | Safe source | Typical control | | --- | --- | --- | --- | | **Session or working memory** | The current support case and steps already attempted | Current session and tool events | Session boundary and short retention | | **Episodic memory** | A prior job occurred and was accepted on a named date | Job and acceptance record | Link to evidence; expiry and correction | | **Profile or semantic memory** | The customer prefers PDF delivery | Explicit customer statement or authorised profile | Consent, visibility, edit and deletion | | **Procedural memory** | The approved process for escalating a refund | Versioned operating policy | Treat policy store as authority; controlled publishing | The labels help design the system but do not make a memory true. A generated summary is a derived record linked to the interaction or source from which it was extracted. ### Managed memory illustrates the choices Provider implementations show that memory is an operating layer rather than a model trait. Google documents Memory Bank as a service attached to a Vertex AI Agent Engine instance, with configurable memory generation and access controlled through cloud identity ([Google Cloud, "Set up Memory Bank"](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/set-up)). Anthropic documents managed-agent memory as workspace-scoped text documents, with immutable versions for changes ([Anthropic, "Managed agent memory"](https://platform.claude.com/docs/en/managed-agents/memory)). Microsoft documents memory item create, read, update, list and delete operations plus store-level retention controls in its current preview ([Microsoft, "Memory in Foundry Agent Service"](https://learn.microsoft.com/en-gb/azure/ai-foundry/agents/concepts/what-is-memory?preserve-view=true&view=foundry)). Amazon's earlier Bedrock Agents memory feature stored session summaries against a memory identifier and allowed a retention period from 1 to 365 days. AWS now marks Bedrock Agents Classic as unavailable to new customers and directs them to AgentCore, illustrating why architecture and procurement records must also track product lifecycle ([AWS, "Give agents memory"](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-memory.html)). The implementation details differ, but the buyer's questions remain stable: 1. What event creates or updates a memory? 2. Is the memory quoted, extracted, inferred or summarised? 3. Which person, customer or workspace owns it? 4. Who can retrieve, correct, export and delete it? 5. When does it expire, and what happens to derived indexes? 6. Can the organisation reconstruct the source and prior versions? 7. What prevents one user's memory from influencing another user's job? 8. Which memories are prohibited, especially sensitive or consequential inferences? ### Memory needs a correction path People change roles, addresses and preferences. Businesses change policies and prices. An agent can also extract the wrong fact. A memory system that only writes and recalls is incomplete. Consequential memories need to be visible, correctable and deletable, with their use exposed to the responsible operator. Current source-system data takes precedence over a conflicting memory. High-impact decisions cannot depend on an opaque remembered inference. ## Provenance turns context into inspectable evidence Provenance is more than a hyperlink added to final prose. It connects the source record, the activity that transformed or selected it, and the person, organisation or software agent responsible. The W3C PROV family formalises these broad concepts as entities, activities and agents ([W3C, "PROV Overview"](https://www.w3.org/TR/prov-overview/)). For an agent job, the provenance record identifies: ```text job and run ID source URI or system record ID source version, owner and effective date retrieval query and eligibility filters retrieved passage or record identifier parser, index, embedding and ranking versions model and runtime version tool calls and transformations output or action influenced approval and acceptance record correction, revocation or deletion event ``` Not every user needs to see every field. The system needs enough to investigate an error, reproduce a material decision where possible, honour deletion and distinguish primary evidence from generated interpretation. ### Citation is a user interface for provenance A citation allows a reader to inspect support for a claim. Good citations point to the source that actually supports the statement, not a search-results page or a roundup that copied the number. For internal agents, the equivalent may be a policy section, ticket ID, invoice line or document version. A citation can still be misleading. The source may be outdated, ineligible for that customer, or quoted beyond its scope. Citation presence is therefore measured beside source correctness and claim support. ## The economics of context Context infrastructure has several charging surfaces: - source-system licences and connector fees; - parsing, transcription and document processing; - embedding generation and re-indexing; - vector, text and object storage; - search, retrieval and reranking operations; - external data or web-search calls; - model tokens consumed by retrieved material; - data transfer, regional infrastructure and private networking; - human curation, access review and correction; and - failures caused by missing, stale or excessive context. OpenAI's current Retrieval documentation, for example, prices vector-store storage by the size of parsed chunks and embeddings after an account-wide free allowance. Pinecone documents serverless query cost in relation to namespace size. These are component prices, not the cost of a correct customer outcome ([OpenAI, "Retrieval pricing"](https://platform.openai.com/docs/guides/retrieval#pricing); [Pinecone, "Implement multitenancy"](https://docs.pinecone.io/guides/index-data/implement-multitenancy)). ### Agentic Economy's Context-to-Acceptance Cost Stack Version 1.0 measures the complete context path: ```text source access and licences + ingestion, parsing and indexing + storage and retrieval + context model tokens + maintenance and permission review + correction and human verification + failed jobs caused by context = total context cost total context cost / accepted jobs = context cost per accepted job ``` The denominator connects infrastructure with value. A cheap search call that misses the governing policy can be expensive. A paid data source may lower total cost if it reduces rework and improves acceptance. That remains a hypothesis until matched jobs show the licence cost, retrieval quality, correction effort, acceptance and incident result. ## The Australian data question Australian organisations use global model, memory and search services, often alongside local cloud regions and domestic business systems. The presence of an Australian region does not settle the full data path. Processing, safety systems, logs, support access, backups, external connectors and fallback services may have different locations and terms. The Office of the Australian Information Commissioner says privacy obligations can apply to personal information entered into an AI system and to generated output where that output contains personal information. Its guidance recommends due diligence on intended use, human oversight, privacy and security risks, access to input and generated information, transparency and ongoing monitoring. It also says generating or inferring personal information can constitute collection under Australian Privacy Principle 3 ([OAIC, "Guidance on privacy and the use of commercially available AI products"](https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-the-use-of-commercially-available-ai-products)). That guidance makes memory and retrieval design operationally important. An Australian deployment record includes: - which personal, sensitive, confidential or regulated data may enter each context component; - the purpose and authority for collection, use, inference and disclosure; - which provider, region and subprocessors handle source data, embeddings, indexes, prompts, memories, logs and outputs; - whether provider staff or model-improvement processes can access the data; - how individuals or customers are notified where required; - the retention, correction, access and deletion process, including derived copies; - the human review and remedy for decisions with significant effects; and - the evidence that controls work in production. This is a system-design checklist, not legal advice. Privacy, records, professional, employment, consumer, sector and contractual obligations depend on the organisation and job. ### Data residency is not data authority Keeping an index in Australia can support a location requirement. It does not prove that the signed-in user may see every indexed record or that the agent may disclose it to another service. Conversely, a global service is not automatically unsuitable. The decision depends on the data, purpose, promises, controls and consequence. Every context system carries two distinct questions: 1. **Location:** where is each copy processed, stored, backed up and accessed? 2. **Authority:** who or what may read, combine, infer from, retain and disclose it for this job? For an Australian regulated or sensitive-data deployment, add an assurance overlay. Record the data class and purpose, applicable policy or obligation, first-line owner, privacy/security/records challenge owner, accountable executive, test evidence, breach or incident trigger, exception authority and review date. Applicability varies by organisation and sector; this is a governance hand-off, not a universal legal conclusion. ## A worked example: the A$750 competitor brief Return to the Perth advisory firm from the report opening. Its research agent prepares a competitor brief using ten approved public sources, the customer's intake form and the firm's private research notes. A weak design uploads every prior client document into one shared vector store, lets the model search the open web, retains the full conversation indefinitely and produces a polished brief with links. It may look capable while exposing one client's notes to another, citing copied statistics, using a superseded price page and preserving personal information without a defined purpose. A production design separates the context: 1. The job objective records scope, customer, delivery time and acceptance criteria. 2. The customer's files stay in a tenant boundary and are filtered by the signed-in engagement identity. 3. Public research comes from an approved source list or search policy, with canonical URL and checked date. 4. Private research notes retain author, client eligibility and expiry metadata. 5. Retrieved passages remain labelled as evidence, not instructions. 6. The draft cites the exact records used and flags material conflicts or missing evidence. 7. An analyst reviews claims, exclusions and disclosure before delivery. 8. The accepted brief, source manifest and corrections remain attached to the job. 9. Temporary working files expire; durable memory is limited to explicitly approved customer preferences and job history. The agent has not become omniscient. The service has become inspectable. ## What the sources establish | Evidence | What it establishes | What it does not establish | | --- | --- | --- | | Product documentation | Supported ingestion, search, memory and control features at a checked date | Reliability on the buyer's corpus or configuration | | Architecture diagram | Intended data flow and component boundary | Actual production access, location or deletion | | Retrieval evaluation | Whether relevant labelled records are found for test questions | Final answer quality or authorised use | | Citation check | Whether a claim links to supporting source material | Completeness, fairness or business acceptance | | Access-control test | Whether named identities can retrieve named records | Absence of every possible leak | | Memory lifecycle test | Whether create, recall, correct, expire and delete work | Appropriateness of remembering the information | | Accepted-job record | Whether context supported a completed business result | Broad market adoption or causal economic impact | Current primary documentation establishes a large and growing supply of managed retrieval, memory, database and connector capabilities. It does not establish a universal context architecture, a best vector database, or broad enterprise outcome improvement. Those questions require job-level evaluations, production access tests and accepted-work evidence. ## The emerging Agent Context Contract Production context systems are converging on a common contract across information, authority, lifecycle, retrieval, memory and evidence. Twenty representative jobs or four weeks provides a practical observation window, not a universal statistical threshold. ### 1. The information boundary | Field | Decision | | --- | --- | | Job and acceptance | What result is being produced, and who accepts it? | | Mandatory context | Which objective, policy and business records must be present? | | Prohibited context | Which data classes, customers or sources must never enter? | | Systems of record | Where must current facts be queried rather than remembered? | | Retrieval sources | Which repositories and external providers are eligible? | | Source precedence | What wins when records conflict? | | Freshness | How old may each record type be? | ### 2. Authority and lifecycle | Field | Decision | | --- | --- | | Retrieval identity | Which user, service or job identity performs each query? | | Eligibility filters | Which tenant, role, purpose, geography and date rules apply? | | Memory write rule | Which events may create a durable memory? | | Memory owner | Who can see, correct, export and delete it? | | Retention | What expires after the run, session, engagement or legal period? | | Provenance | Which source and transformation fields remain attached? | | Incident route | Who can stop retrieval, revoke access and investigate? | Add a commercial and supplier schedule when another organisation processes or stores the context: | Field | Evidence to obtain | | --- | --- | | **Data use** | Contracted purposes, model-training position, staff access and subprocessor register | | **Location** | Processing, log, backup and support-access regions for the exact route | | **Service** | Availability, quota, support response, breach notice and deletion time | | **Ownership** | Rights in sources, chunks, embeddings, memories, traces and derived inferences | | **Audit** | Logs, customer-run tests, independent assurance and evidence retention | | **Portability** | Export format for records, filters, provenance, memory and access history | | **Remedy** | Correction, restoration, service credit, liability owner and incident escalation | | **Lifecycle price** | Ingestion, curation, re-indexing, storage, transfer, review, deletion and exit cost | ### 3. Test the observable route ```text job_id, user_id, tenant_id, source_set, source_versions, eligible_candidates, prohibited_candidates, relevant_candidates, selected_records, citations_supported, stale_records, memory_reads, memory_writes, memory_corrections, input_tokens, retrieval_cost, context_cost, delivered, accepted, rework_minutes, incident_class ``` The minimum production tests are: - a user can retrieve every record required for an authorised job; - the same user cannot retrieve an ineligible customer's record; - revoked or superseded records stop influencing new jobs; - a malicious instruction inside a retrieved document cannot expand authority; - a memory can be inspected, corrected and deleted through its full derived path; - every material claim or action can be traced to the context that influenced it; and - context cost and human correction remain attached to the accepted job. Three failures define the hard boundary: an ineligible record reaches the candidate set, a retrieved instruction expands authority, or deleted information continues to influence a new job. Persistent retrieval misses and high correction cost undermine the business case. Privacy, contractual and records decisions remain with their accountable owners. ## Where we see the market going Context infrastructure is separating into retrieval, memory, data rights and provenance even as cloud platforms bundle those capabilities. The durable advantage will come less from storing the most material than from assembling the smallest current, permitted and attributable context that improves accepted work. Memory portability will become a competitive boundary. Buyers will expect source lineage, correction, deletion and policy to travel with retained state; exports that preserve only embeddings or text will not be enough. Three questions remain open: 1. Do managed retrieval and memory services converge into cloud features, or remain a distinct software market? 2. Does enterprise advantage come from proprietary data volume, or from the quality, permissions, provenance and feedback around a smaller context set? 3. Can organisations port durable agent memory between runtimes without losing meaning, access rules and audit history? The strategic conclusion would change if matched-job tests showed that governed context does not improve acceptance, rework, incident exposure or retention enough to cover its lifecycle cost. It would also change if portable exports moved source meaning, access rules, provenance and memory history between runtimes without material rework. ## About the author and editorial record Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy in Australia. This chapter is source-led market analysis, not a sponsored ranking or a claim that every listed product has been independently tested. [Back to the report hub](/guides/hitchhikers-guide-agentic-economy-2026) · Next: [runtimes, orchestration and harnesses](/guides/ai-agent-runtimes-orchestration-harnesses).