AI agent context, memory and data infrastructure

On this page

Chapter 5 of The Hitchhiker's Guide to the Agentic Economy

Report hub · Previous: models, inference and compute · In this chapter: the context stack · market map · retrieval · memory · Australia · buyer worksheet

Context engineering and enterprise governance

An autonomous software agent operates strictly across the information assembled for its current execution turn and the persistent state retrieved from prior runs.

This defines the operational ceiling of its judgment. A foundation model can reason across text and code, but it cannot know that an internal price sheet was superseded yesterday, that a retrieved PDF belongs to a different corporate tenant, or that an instruction embedded in a scraped web page represents a malicious prompt injection. Operational dependability is determined by the quality, freshness, and permission boundaries of the context pipeline, not by the sheer size of the model's context window.

Deploying agent systems requires isolating four distinct data concepts:

• Context: The specific payload of instructions, business state, and retrieved records placed into the model's active working window for a single execution step.
• Retrieval: The automated pipeline that queries external systems, databases, or document stores to identify relevant candidate records.
• Memory: State written to persistent external storage that survives process restarts and can be loaded into subsequent sessions.
• Provenance: The immutable audit trail recording where data originated, which identities accessed or transformed it, and which actions it influenced.

Treating these layers as generic "agent knowledge" creates substantial commercial and security risk. An expanded context window provides temporary scratchpad memory, not persistent corporate memory. A vector database is an approximate search index, not an authoritative enterprise system of record. An ERP or CRM maintains legal financial and customer truth, while a managed memory service stores extracted summaries. None of these components automatically ensure that retrieved data is current, legally permitted, or accurate.

Enterprise context architectures require four properties: task-specific relevance, strict separation of system instructions from untrusted data, pre-retrieval permission filtering, and verifiable provenance linking every action to its source.

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.

The emerging market for context infrastructure

Context management has expanded into a specialized infrastructure market spanning document parsing, chunking pipelines, hybrid search engines, vector and graph databases, managed agent memory services, and data provenance ledgers. Cloud hyperscalers are bundling basic vector search into managed services, while specialized vendors compete on multi-tenant access control, hybrid search accuracy, memory lifecycle governance, and audit observability.

The market is converging around a layered operational architecture: active context windows hold short-lived working state, retrieval pipelines select external records, memory services persist user and task context across sessions, and enterprise systems of record retain authoritative business history. Long-term enterprise differentiation will concentrate around permission governance, automated provenance, and verifiable data rights rather than raw vector database hosting.

The seven layers of enterprise agent context

Context assembled for a production agent combines seven distinct information layers, each requiring different security and update controls:

Context component	Information provided to the model	Authoritative source	Primary operational failure mode
Objective	The target deliverable, constraints, and stopping condition	User request, workflow orchestration state, customer order	Ambiguous goals leading to infinite loops or off-target outputs
Policy and authority	Explicit constraints on spending, data access, and write actions	Enterprise IAM, policy engine (Cedar, OPA), approval records	Treating unverified user instructions as contractual authority
Current interaction	In-flight execution history, intermediate thoughts, and tool returns	Ephemeral session memory, execution trace logs	Accumulating noise that displaces core instructions in the window
Business state	Current account balances, customer records, and inventory counts	Enterprise systems of record (CRM, ERP, core banking)	Operating against stale cached copies rather than querying live state
Retrieved knowledge	Relevant operational manuals, research archives, and documentation	Semantic vector search, hybrid document indexes, API search	Ingesting obsolete, irrelevant, or tenant-ineligible documents
Retained memory	Long-term preferences, user interaction patterns, and prior job outcomes	Managed agent memory stores, key-value state databases	Persisting hallucinated, outdated, or sensitive personal data
Working scratchpad	Intermediate calculations, draft artifacts, and temporary files	Ephemeral execution sandbox, local scratch filesystem	Data leakage across runs or uncontrolled retention of sensitive data

These distinctions dictate architectural precedence. Corporate policy must always override a user's conversational preference. A customer's current credit balance must be fetched via a structured query against core banking ledgers, never inferred from a memory note written last week. External research informs recommendations, but must not be permitted to alter production databases directly.

Context window management as a cost and attention constraint

The context window limits the volume of text an agent can evaluate during an execution step. Expanding context windows allow models to ingest entire codebases or lengthy financial reports, but larger windows do not ensure effective reasoning. Overloading the context window increases per-turn token costs, elevates latency, dilutes model attention, and increases susceptibility to conflicting instructions.

Effective context management requires two operational mechanisms:

1. Ensuring that system policies, critical constraints, and current task state remain pinned in the window.
2. Dynamically pruning, summarizing, or evicting non-essential intermediate tool outputs without altering core semantic meaning.

Hyperscaler platforms provide specific optimizations: Anthropic supports prompt caching for static system prompts, dynamic tool discovery that loads JSON schemas on demand, and context editing that prunes verbose intermediate outputs (Anthropic, "Manage tool context"). These techniques reduce token burn and latency, but verifying whether a summarized document remains faithful to the original source remains the developer's responsibility.

Long context versus persistent memory

Large context windows, retrieval systems, and persistent memory serve distinct technical functions:

Requirement	Long context window	Retrieval pipeline (RAG)	Persistent memory store
Analyze a 300-page contract during a single run	Optimal solution	Redundant	Inappropriate
Query the latest company leave policy	Inefficient alone	Optimal solution	Risky (policies become stale)
Recall a customer's UI preferences across months	Cost-prohibitive	Complex	Optimal solution (with consent controls)
Verify current account balance or inventory level	Prohibited	Query live system of record	Prohibited (must query source of truth)
Audit why an autonomous action was taken	Ephemeral	Requires source links	Requires immutable provenance logs

Authoritative data must live in dedicated systems of record. Agents retrieve live records on demand, while persistent memory provides workflow continuity rather than acting as an ungoverned shadow database.

Who supplies context, memory and data infrastructure

The vendor ecosystem spans foundation model providers, managed cloud services, specialized search databases, enterprise software suites, and observability platforms:

Infrastructure layer	Representative vendors	Supplied technical capability	Operational gaps left to the customer
Model-native retrieval	OpenAI Retrieval and file search, Anthropic tool connectors, Google Gemini Grounding	Integrated document ingestion, vector chunking, and managed semantic search	Enforcing fine-grained enterprise permissions and validating source authority
Cloud knowledge platforms	Amazon Bedrock Knowledge Bases, Google RAG Engine, Microsoft Foundry AI Search	Scalable document ingestion, vector storage, IAM integration, and hybrid search	Ensuring ingested document corpora are verified, current, and legally permissible
Managed agent memory	Amazon Bedrock AgentCore Memory, Google Vertex AI Memory Bank, Microsoft Foundry Memory, Anthropic Managed Agent Memory	Multi-session state persistence, automatic entity extraction, and semantic memory querying	Managing user privacy consent, regulatory deletion mandates, and memory accuracy
Vector and hybrid search engines	Pinecone, Weaviate, Elasticsearch, MongoDB Atlas Vector Search, PostgreSQL pgvector	High-performance vector indexing, semantic search, hybrid keyword matching, and metadata filtering	Translating end-user access privileges into pre-execution query filters
Enterprise systems of record	Microsoft 365, Google Workspace, Salesforce, ServiceNow, SAP, Atlassian	Authoritative operational records, transactional databases, and established corporate IAM	Providing standardized agent interfaces and semantic ranking across legacy silos
External information providers	Tavily, Exa, Brave Search, AlphaSense, specialized financial and legal feeds	Fresh web search indices, commercial market data, and licensed news streams	Verifying third-party copyright licenses, data accuracy, and commercial reuse rights
Connectors and tool gateways	MCP servers, enterprise iPaaS (Workato, Zapier), cloud integration platforms	Pre-built authentication and API abstractions to enterprise databases and SaaS tools	Enforcing least-privilege scoping and preventing unauthorized write side-effects
Provenance and observability	OpenLineage, Arize, LangSmith, Weights & Biases, enterprise audit platforms	Structured execution traces, data lineage mapping, and prompt-to-output attribution	Determining whether an autonomous decision satisfied legal or business standards

OpenAI’s Retrieval API automatically chunks, embeds, and indexes uploaded files, providing hybrid search that blends semantic vector matching with keyword scoring (OpenAI, "Retrieval"; OpenAI, "File search"). Google’s Vertex AI RAG Engine coordinates ingestion from Google Drive and Cloud Storage through embedding generation and model grounding (Google Cloud, "RAG Engine overview"). Amazon Bedrock Knowledge Bases manages automated synchronization between proprietary S3 data repositories and managed vector indexes (AWS, "Knowledge bases for Amazon Bedrock").

These managed cloud services abstract low-level vector infrastructure. However, they do not resolve enterprise data governance: chunking strategies, indexing latency, deletion synchronization, regional residency, and role-based access filtering remain customer engineering responsibilities.

Retrieval as an operational supply chain

Retrieval-augmented generation (RAG) is not a single database query. It is a multi-stage operational supply chain transforming unstructured source material into verified model context:

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 transition represents an operational and security boundary:

Ingestion pipelines determine data utility

Source data arrives in diverse formats: PDFs, scanned documents, database rows, email threads, chat transcripts, and API payloads. Parsers must extract semantic structure—headers, tabular data, footnote citations, and access tags—without corruption. Chunking algorithms then partition documents into discrete retrieval units: oversized chunks dilute relevant information and consume excessive tokens, while undersized chunks strip necessary context.

Every indexed chunk requires structured operational metadata:

• Canonical document URI and unique record identifier.
• Document ownership, classification level, and business domain.
• Effective, modified, and ingested timestamps.
• Multi-tenant boundary labels and role-based access control (RBAC) tags.
• Jurisdictional data residency and contractual handling restrictions.
• Version history and document supersession status.
• Mandatory data retention schedules and purge rules.
• Explicit content licensing and commercial reuse rights.
• Ingestion parser version, embedding model identifier, and vector index date.

Without this metadata, semantic search may identify conceptually related text, but the system cannot confirm whether the information is legally accessible, currently effective, or attributable.

Hybrid retrieval and semantic reranking

Lexical search matches exact words and database keys. Semantic search uses high-dimensional vector embeddings to match conceptual intent regardless of vocabulary. Hybrid retrieval combines dense vector embeddings with sparse keyword algorithms (BM25). A secondary reranking model then scores the top candidates against the specific query context.

Production systems match retrieval strategies to task types:

• Looking up a product SKU, invoice number, or contract clause requires exact lexical search.
• Interpreting ambiguous corporate policy questions requires semantic retrieval filtered by document version.
• Determining an account balance requires an authenticated SQL query against a transactional database, not a vector similarity lookup.

Enforcing permission boundaries before model exposure

Retrieving all matching corporate documents and instructing the model to ignore confidential records is an unacceptable security failure. Enterprise access boundaries must be enforced at the database layer before candidate records enter model context.

Search pipelines must apply deterministic filters restricting candidate records by tenant ID, user identity, security clearance, and time window. Vector similarity calculations run exclusively across the pre-filtered subset of permitted documents.

OpenAI supports attribute filtering applied prior to semantic search (OpenAI, "Attribute filtering"). MongoDB Atlas Vector Search provides pre-filtering stages within its search pipeline (MongoDB, "Vector Search pre-filtering"). Pinecone documents dedicated namespace partitioning for multi-tenant isolation, contrasting namespace separation against metadata filtering across cost, latency, and security dimensions (Pinecone, "Implement multitenancy").

Treating retrieved content as data, not instruction

External web pages, customer emails, and third-party documents can contain text that models interpret as system instructions. When an agent holds tool permissions, indirect prompt injection can hijack execution, exfiltrate data, or initiate unauthorized transactions.

Production architectures enforce a strict structural hierarchy: system prompts and enterprise policies govern execution, while retrieved content is treated strictly as unverified data. Untrusted inputs must be clearly tagged, tool calling permissions tightly restricted, and high-consequence write actions gated behind human approval. Guidance from the Australian Signals Directorate highlights that an agent's harness—including its context retrieval pipeline and tool permissions—is the primary defensive perimeter against prompt injection attacks (ASD, "Agentic AI harnesses").

Persistent memory as an enterprise record

Persistent memory gives agents continuity across distinct sessions. However, without strict governance, memory can store hallucinated assumptions, leak sensitive information across users, or retain personal data beyond statutory limits.

Enterprise memory structures map into four operational tiers:

Memory classification	Operational example	Authoritative data source	Governance control
Session scratchpad	Intermediate calculations and active task state	In-flight execution logs	Ephemeral; purges upon task completion
Episodic memory	Record of past completed jobs and delivery dates	Verified job logs and acceptance receipts	Cryptographic links to evidence; explicit expiration
User profile memory	Individual delivery preferences and formatting rules	Explicit user consent and profile settings	User-editable; full export and deletion rights
Procedural memory	Standard operating procedures for handling refunds	Version-controlled corporate policy stores	Read-only; strict version pinning and audit controls

Managed memory services reflect these operational requirements. Google’s Memory Bank integrates with Vertex AI Agent Engine, managing entity extraction and memory retrieval via IAM roles (Google Cloud, "Set up Memory Bank"). Anthropic provides managed agent memory structured as workspace-scoped documents with immutable version histories (Anthropic, "Managed agent memory"). Microsoft Foundry documents memory item CRUD APIs and store-level time-to-live policies (Microsoft, "Memory in Foundry Agent Service").

AWS Bedrock Agents previously supported session summary memory with 1-to-365-day retention limits, but AWS has designated the classic interface unavailable to new customers, directing builders to AgentCore (AWS, "Give agents memory"). Managing memory infrastructure requires tracking vendor service deprecations.

Operational governance for agent memory

Enterprise memory implementations require answering eight governance questions:

1. What specific business event authorizes the creation or modification of a memory?
2. Is the memory a direct quote, a structured extraction, or an unverified model inference?
3. Which legal entity, customer account, or employee owns the stored memory?
4. Who maintains administrative authority to inspect, update, export, and delete memories?
5. What automated time-to-live (TTL) expiration schedules apply?
6. Can the organization audit the original source interaction that generated the memory?
7. What technical boundaries prevent memories from leaking across tenant boundaries?
8. What policy rules prohibit the persistence of sensitive personal, health, or financial inferences?

Memories must remain visible, editable, and purgeable. When stored memory contradicts live data in an enterprise system of record, the live transactional database must always take precedence.

Provenance and auditability

Data provenance connects an agent's final output to the source documents, tool outputs, and model reasoning steps that produced it. The W3C PROV specification establishes a vendor-neutral standard for modeling these relationships across entities, activities, and software agents (W3C, "PROV Overview").

A production provenance record captures the complete chain of custody:

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

Provenance logs provide the audit trail necessary to investigate regulatory failures, reproduce contested decisions, comply with statutory deletion requests, and defend business outcomes to clients and insurers.

Citations as an audit interface

Citations allow users and auditors to inspect the factual basis of a claim. Robust citations link directly to canonical source records—specific policy sections, database primary keys, or immutable document revisions—rather than linking to search-result summaries.

However, the presence of a citation does not guarantee factual validity. An agent can accurately cite an outdated policy, quote text out of context, or misinterpret an exception clause. Evaluating context quality requires verifying source freshness, semantic relevance, and permission eligibility.

The unit economics of context infrastructure

Context infrastructure introduces multiple operational cost drivers:

• Commercial software licenses and connector subscription fees.
• Document parsing, OCR processing, and transcription compute.
• Embedding model token consumption and index recalculation.
• Continuous vector, document, and object storage fees.
• Query execution, hybrid search, and semantic reranking fees.
• External search API and premium data vendor query fees.
• Model input token burn consumed by long retrieved passages.
• Cross-region data egress and private networking bandwidth.
• Human data curation, tagging, and permission maintenance.
• Operational waste caused by retrieval misses, prompt retries, and manual correction.

OpenAI meters vector-store usage by storage volume following an account allowance, while Pinecone prices serverless vector queries relative to namespace size (OpenAI, "Retrieval pricing"; Pinecone, "Implement multitenancy").

The Context-to-Acceptance Cost Stack

Calculating the true cost of context requires tracking expenditure across the entire pipeline:

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

Unit economics are measured against accepted deliverables. An inexpensive retrieval setup that repeatedly fetches outdated context is commercially expensive if it forces human analysts to spend hours correcting errors. Paying for premium search APIs or dedicated rerankers is economically justified if it eliminates retries and drives high first-pass acceptance rates.

The Australian privacy and data governance environment

Australian businesses operating context pipelines must reconcile global cloud infrastructure with domestic privacy and corporate recordkeeping obligations. Maintaining a cloud database within an Australian data center does not automatically ensure legal compliance; prompt processing, security evaluation, telemetry logging, support access, and fallback endpoints may traverse overseas jurisdictions.

The Office of the Australian Information Commissioner (OAIC) states that Australian Privacy Principles (APPs) govern both personal information entered into AI systems and personal information generated or inferred in model outputs (OAIC, "Guidance on privacy and the use of commercially available AI products"). The OAIC emphasizes that generating or inferring personal information constitutes collection under APP 3, requiring explicit lawful purpose, transparency, and ongoing governance.

Australian production deployment requires formalizing an operational data record:

• Explicit identification of personal, sensitive, or confidential records permitted within each context store.
• Validated lawful basis for collection, automated processing, and third-party disclosure.
• Documentation of cloud providers, physical regions, and sub-processors handling raw data, embeddings, prompts, and logs.
• Contractual verification that cloud providers exclude enterprise context from foundation model training.
• Operational mechanisms for notifying affected individuals and processing statutory access and correction requests.
• Enforceable data retention limits and auditable disposal procedures across raw sources and derived vector indexes.
• Designated human review channels and dispute remediation paths for consequential decisions.
• Documented testing proving that multi-tenant isolation and permission filtering function in production.

Data residency versus access authority

Maintaining an indexed database within Australia satisfies geographic storage rules. It does not establish that an agent is legally authorized to access every indexed file, or permitted to transmit derived insights to third-party APIs. Geographic residency and operational authority represent distinct security requirements:

• Residency: Where data is processed, indexed, backed up, and accessed by technical support staff.
• Authority: Which specific software workloads, user identities, and business tasks are authorized to read, transform, persist, and disclose that data.

Applied walkthrough: the A$750 competitor briefing

The reference competitor briefing (AE-JOB-001) illustrates how context governance separates an uninsurable demonstration from an enterprise service.

An unhardened prototype loads past client briefings into a shared vector index, permits unconstrained web browsing, retains all session transcripts indefinitely, and generates a formatted brief. This design exposes severe failure modes: client research leaks across tenant boundaries, the agent cites unverified blog aggregators, recommendations rely on expired pricing, and confidential business data persists without clear retention policies.

A production-grade implementation isolates context systematically:

1. The job objective formally binds research scope, customer ID, delivery deadlines, and acceptance criteria.
2. Client-provided intake files are stored in an isolated tenant boundary, accessible only via authenticated credentials tied to that engagement.
3. External web research is restricted to an approved list of verified primary sources, logging canonical URLs and retrieval timestamps.
4. Internal research notes maintain author attribution, client confidentiality tags, and expiration dates.
5. Ingested passages are tagged as unverified external data, preventing indirect prompt injection from altering system instructions.
6. The draft briefing cites exact source documents, flagging factual gaps or conflicting evidence for human review.
7. An industry analyst reviews all cited claims, exclusions, and competitive recommendations before client transmission.
8. The final deliverable, source manifest, and analyst sign-off are archived as an immutable job record.
9. Ephemeral scratch files are purged upon delivery, while persistent memory is restricted to authorized customer delivery preferences.

Evaluating context and memory evidence

Analyzing context infrastructure claims requires matching evidence types to the operational conclusions they support:

Evidence source	What it establishes	Unresolved operational question
Provider documentation	Supported ingestion formats, search features, and API interfaces	Retrieval accuracy and latency across messy enterprise corpora
Architecture diagram	Intended data flows, system boundaries, and network topology	Production security posture, access isolation, and deletion controls
Retrieval benchmark	Precision and recall scores against synthetic test question sets	Real-world reliability when handling ambiguous enterprise queries
Citation tracking	Verification that model outputs generate source hyperlinks	Factual accuracy, source freshness, or commercial fair-use compliance
Access-control test	Evidence that specific credentials can query designated document sets	Guarantee that unpredicted prompt injections cannot bypass query filters
Memory CRUD audit	Verification that memory records can be created, updated, and deleted	Long-term accuracy, relevance, and appropriateness of stored state
Job-level production log	Empirical evidence that context pipeline supported accepted deliverables	Broad cross-industry applicability and financial return

Vendor documentation proves the existence of managed retrieval tools. However, enterprise reliability is determined by task-level evaluation, rigorous pre-retrieval access testing, and verifiable delivery records.

The Agent Context Contract

Production systems require an explicit operational contract governing data boundaries, authority limits, and lifecycle rules:

1. Information boundary

Specification field	Architectural requirement
Task scope	The exact deliverable produced and the designated business authority who inspects it
Mandatory context	Explicit system prompts, corporate policies, and transactional records that must be loaded
Prohibited context	Restricted data classes, unauthorized tenant files, and unverified web domains
Authoritative records	Specific transactional databases that must be queried live rather than inferred from memory
Approved sources	Explicit registries, document repositories, and search endpoints authorized for the task
Precedence hierarchy	Definitive rules establishing which document version controls when sources conflict
Freshness ceiling	Maximum acceptable age for each class of retrieved document

2. Authority and data lifecycle

Specification field	Architectural requirement
Query identity	The specific service account, user role, or task credential executing retrieval
Pre-search filters	Mandatory tenant IDs, user roles, classification levels, and date ranges enforced at the database layer
Memory write criteria	Explicit operational events authorized to commit persistent records to long-term memory
Memory governance	Designated administrative roles permitted to audit, edit, export, and delete stored memories
Retention schedules	Automated expiration schedules for session scratchpads, intermediate drafts, and long-term profiles
Provenance tracking	Required source URLs, document IDs, timestamps, and parser versions attached to outputs
Incident protocols	Operational procedures to halt retrieval, purge corrupted vector indexes, and revoke compromised tokens

When context is processed or stored by third-party cloud vendors, enterprise contracts must specify vendor obligations:

Contractual parameter	Enterprise verification requirement
Data utilization	Explicit contractual prohibitions against using customer context or prompts for foundation model training
Geographic routing	Exact regions where data is processed, embedded, stored, backed up, and accessed by support personnel
Service availability	Uptime SLAs, query rate limits, support escalation paths, and breach notification windows
Intellectual property	Unambiguous customer ownership of raw data, embeddings, custom memories, and derived inferences
Audit transparency	Customer access to query logs, penetration test summaries, and independent security certifications (SOC 2, ISO 27001)
Data portability	Open, non-proprietary export formats for vector embeddings, metadata schemas, and memory histories
Remediation terms	Contractual liability, service credits, and breach indemnification for unauthorized data disclosure
Total lifecycle cost	Clear pricing covering ingestion, embedding updates, index storage, search queries, and data extraction

3. Production verification metrics

Operating an enterprise context pipeline requires tracking performance across production jobs:

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

Production systems must pass seven non-negotiable operational tests:

1. Authorized users consistently retrieve all necessary documents required to complete the task.
2. Users can never retrieve documents belonging to another tenant or classification level.
3. Superseded or revoked policies immediately stop influencing model generation.
4. Adversarial prompt instructions inside retrieved documents cannot alter system execution policies or expand tool access.
5. Stored memories can be inspected, updated, and purged across all downstream index copies.
6. Every material claim or business action maps to verifiable context in provenance logs.
7. Context ingestion and storage costs remain economically viable relative to gross margin per accepted job.

The trajectory of context infrastructure

Context infrastructure will continue separating into distinct operational layers: document parsing, high-speed hybrid retrieval, governed agent memory, and data provenance ledgers. Defensible enterprise advantage will come not from storing massive, uncurated document archives, but from engineering tightly bounded, current, permissioned, and attributable context that maximizes first-pass task acceptance.

Data portability will emerge as a critical procurement boundary. Enterprises will reject proprietary memory and vector stores that trap corporate context, demanding portable standards that allow state, access policies, and provenance histories to migrate cleanly across different foundation models and execution runtimes.

Context is assembled for an execution run, and that run must survive long enough to complete its work. Chapter 6 examines the runtime layer: orchestration state machines, checkpointing, retries, and failure recovery when a business job outlives a single process.

Sources and method

• Primary sources: Technical documentation, API specifications, and service architectures from OpenAI, Google Cloud, AWS Bedrock, Anthropic, Microsoft Azure, Pinecone, MongoDB Atlas, Hugging Face, and W3C checked as of 13 September 2026.
• Analytical frameworks: The seven-part context stack, the Context-to-Acceptance Cost Stack, and the Agent Context Contract are original analytical frameworks developed to structure enterprise context management.
• Evidence boundaries: Provider documentation establishes declared feature sets, storage pricing, and API structures. Retrieval accuracy, multi-tenant isolation, and production reliability require empirical testing across customer-specific document corpora.
• Institutional context: Regulatory publications from the Office of the Australian Information Commissioner (OAIC) and the Australian Signals Directorate (ASD) provide Australian privacy and cyber-security governance context.
• Editorial record: Published by Agentic Economy, Perth, Western Australia. Updates and corrections are logged via the editorial record.

Back to the report hub · Next: runtimes, orchestration and harnesses.