Executive briefRAG and agents govern different failure surfaces

Two teams can buy different agent platforms for systems that have almost nothing in common. One assistant answers read-only questions from controlled documents. The other maintains a case across days, selects tools and prepares a transaction. Calling both agents conceals the architectural question. The first system mainly needs evidence selection, entitlement, freshness, grounding and citations. The second needs state, authority, idempotency, recovery, intervention and action evidence in addition to any retrieval.

RAG and agency are mechanisms, not product categories. Retrieval-augmented generation combines model inference with selected external evidence. An agent architecture introduces stateful, model-mediated decisions about steps or tools as observations change. Tool calling alone does not create meaningful agency if a deterministic state machine decides the sequence. Multi-step prompts do not require a durable agent store. Conversational history does not grant permission to act.

The Workload Control-Surface Map in this article classifies observable requirements before a platform choice. It places workloads in a retrieval service, deterministic workflow or bounded agent runtime, all connected to a shared control substrate. Some organisations can implement the zones in one product. Others need distinct services because index lifecycle, transaction recovery, scale, ownership or evidence diverge. Both is a conclusion that must be earned, not the default answer.

The strongest rival: one general agent platform

A coherent agent platform can provide one developer experience, state model, tool interface, telemetry path and deployment process. Treating retrieval as a typed tool can accelerate composition and avoid duplicated services. For a small organisation or related workload family, this may be the most economical architecture, provided the runtime preserves source ownership, entitlement, freshness, retrieval evaluation and citations rather than reducing evidence to an opaque string.

Split when the retrieval estate has independent throughput, ownership, index release, evidence or freshness obligations, or when transactional recovery needs a different runtime and operator. A single abstraction can remain at the developer edge while internal contracts stay distinct. The decision turns on control surfaces and operating evidence, not whether the product brochure contains both features.

Workload Control-Surface MapInspect nine dimensions before choosing a runtime

No dimension becomes an autonomy score. A high state horizon can still use deterministic orchestration. Dynamic investigation can be read-only. A single consequential write can need stronger controls than a long exploratory session. Placement follows the combination and its non-compensable conditions.

Four-zone architectureSeparate runtime choices and share the substrate

Retrieval service. Govern corpus onboarding, parsing, indexing, refresh, entitlement, search, re-ranking, context assembly and citation for read-only evidence use. The service contract names source owners, temporal meaning, access rules and retrieval evaluation. It can support a simple assistant, deterministic workflow or agent without surrendering these semantics to the caller.

Deterministic workflow. Use an explicit state machine or orchestrator when the business path and permitted branches are known. Retrieval and model steps can draft or classify within bounded nodes. Approvals, timeouts, events, transactions and compensation remain explicit. Determinism here refers to orchestration, not necessarily model output.

Bounded agent runtime. Use model-mediated planning or tool selection where it creates demonstrated value under typed actions, principal authority, state, budget, stop conditions and recovery. The runtime records trajectories and observations, but system-of-record truth remains in authoritative services. Human takeover and kill authority are executable.

Shared control substrate. Provide identity, delegation, policy, context and data contracts, evaluation registration, observability, provenance, cost, incident and lifecycle services across the routes. Sharing prevents two platform teams from rebuilding the same controls. It does not require them to use one state store, release process or service-level objective.

Two service contractsPreserve distinct retrieval and action obligations

The RAG Service Contract specifies corpus and source identity, onboarding, parsing, chunk or object structure, index version, refresh, entitlement, ranking, context assembly, citation, grounding, latency, throughput, quality evaluation, correction and retirement. It identifies whether the service returns evidence candidates, bounded context or a generated answer. Source and index owners remain visible through derived artefacts.

The Agent Runtime Contract specifies state objects and owners, plan and branch boundary, typed tool permissions, principal and delegation, budgets, timeouts, idempotency, transaction, confirmation, compensation, rollback, resume, replay, human control, trajectory evidence, incident, kill and retirement. It distinguishes a proposed action from an authorised action and an attempted side effect from a confirmed outcome.

The contracts meet through explicit interfaces. An agent can ask the retrieval service for evidence under its delegated principal and purpose. The returned object carries source identity, rights, freshness, citations, scores with bounded meaning and retrieval receipt. The runtime may reason over it, but it cannot relabel the result as unrestricted memory or discard provenance when creating an action rationale.

Owners and service levels can differ. Index refresh may be batch-oriented and governed by document owners. Agent state may require event-driven concurrency and rapid recovery. Retrieval evaluation measures recall, ranking, grounding and citation for the specified task. Agent evaluation measures trajectories, tool choice, authority, recovery and outcomes. A shared platform report keeps both visible rather than averaging them into one success rate.

RAG inside an agentCarry entitlement and evidence through the tool boundary

The agent invokes retrieval as its delegated principal for a declared purpose and case. The service resolves source entitlements before candidate generation, applies current corpus and index policy, retrieves and re-ranks, then returns bounded passages with source, version, freshness, citation and receipt. The agent cannot use its service identity to broaden the human or workflow authority that sponsored the request.

The runtime records the retrieval call and result identifiers in the trajectory. Claims used to propose an action link to supporting passages. If evidence is stale, contradictory or insufficient, the contract can refresh, request human interpretation or abstain. The agent’s planning trace is not a substitute for source provenance, and a citation is not permission to disclose or act.

Action enforcement rechecks authority at the tool or system boundary. Retrieved text can contain direct or indirect instructions, so data never becomes policy merely by entering context. Typed tools accept bounded arguments, validate state and use idempotency keys. The resulting receipt distinguishes proposal, authorisation, execution and observed outcome. Corrections can then follow both evidence and action dependencies.

Retrieval failure and action failure remain separate. An agent can choose a plausible tool after receiving weak evidence, or retrieve excellent evidence and violate a transaction condition. Evaluation and incident analysis preserve the distinction. This prevents an aggregate agent success measure from concealing citation failure or a high retrieval score from implying safe execution.

Side-effect semanticsMatch recovery to what actually happened

Regeneration is suitable when no external effect occurred and another draft remains within the request contract. Retry is safe only when the operation is read-only or idempotent and the deadline still matters. A write uses a stable operation key so network uncertainty does not create duplicates. The runtime records whether the tool accepted, committed or rejected the operation.

Compensation performs a new action that counteracts a completed effect, such as releasing a reservation. It is not identical to rollback and can fail independently. Rollback restores a prior technical state where the system supports it. Resume continues from a durable checkpoint after verifying current authority and environment. Replay reconstructs decisions or outcomes from preserved events, versions and evidence. Manual resolution handles ambiguity beyond automated authority.

A transactional agent therefore needs more than a generic tool-call loop. It needs transaction boundaries, concurrency control, confirmation, receipts, compensation ownership, kill authority and customer response. The platform can provide patterns and enforcement, while domain owners define which actions are reversible and what remedy means. A model never infers financial or legal reversibility from tool success.

Incident drills simulate timeouts after commit, duplicate events, partial tool failure, stale state, revoked entitlement and human takeover. They verify that the runtime does not reinterpret missing response as permission to try again. Recovery evidence belongs in workload placement and release receipts. A read-only assistant should not inherit this transaction machinery unless its control surface changes.

Negative controlsPlace ten enterprise workloads

Operating boundariesGive indexes and action runtimes the owners they need

Corpus owners decide source authority, use, freshness, retention and correction. Retrieval platform owners operate parsing, indexing, ranking and context services. Product owners define the question and outcome. Agent runtime owners operate state, execution, recovery and trajectory services. Domain leaders own workflow decisions and affected outcomes. Shared security, risk and assurance roles set or challenge controls without becoming default operators.

Service levels reflect failure. Retrieval may promise source ingestion, index refresh, entitlement decision, query latency and citation availability. A runtime may promise state durability, tool dispatch, event processing, recovery and kill propagation. An agent consuming RAG receives both. The end-to-end product SLO cannot excuse a stale index or a duplicate transaction, so component evidence remains accessible.

Cost also separates. Retrieval includes ingestion, storage, indexing, re-ranking, context and evaluation. Runtime includes state, model calls, tools, events, retries, compensation, human review and support. Shared identity and telemetry cost is allocated without double counting. A generic platform may look economical only because domain teams absorb index curation or incident recovery invisibly.

Reuse follows completed journeys. Repeated corpus onboarding and evidence requests justify a retrieval service. Repeated durable state and controlled action patterns justify a runtime. Shared substrate investment follows cross-route control burden. Code reuse alone is insufficient when every product needs bespoke ownership, data or transaction semantics. Platform teams publish exclusions and retirement as well as capabilities.

Workload placement receiptMigrate when the control surface changes

The receipt records users, task, consequence, sources, state horizon, branching, tools, action authority, recovery, human rights, evidence, chosen zone, shared controls, owners, SLOs, cost, exclusions and review triggers. It states the simpler alternative considered and why the selected surface is necessary. The receipt is renewed when behaviour or demand changes.

A read-only assistant may first use a retrieval service. When it gains a persistent case, deterministic workflow becomes appropriate. If dynamic tool selection later proves valuable for investigations, a bounded runtime can be added around the case contract. Consequential actions require a further authority and recovery decision. Migration happens through explicit gates rather than relabelling the existing chatbot as an agent.

The reverse path matters. An exploration agent can reveal that successful work follows a stable sequence. Move that sequence into deterministic orchestration, retain models only at uncertain steps and reduce dynamic authority. A once-common RAG feature may become product specific or a source system may expose an adequate structured API. Simplification and retirement are successful platform outcomes.

Duplication is another trigger. If retrieval and agent teams implement separate principal, policy, evaluation, observability or cost services, consolidate the shared contract and choose an operator. Do not merge the runtimes automatically. If one runtime can preserve both contracts and service levels economically, compose them. If not, use common controls and typed interfaces. The trigger repairs the duplicated burden without erasing meaningful boundaries.

Worked placement reviewFollow a workload from question to consequential action

Start with a read-only policy assistant

A compliance team needs staff to find current internal policy and supporting regulatory material across a controlled corpus. Users ask one question at a time, and a trained employee interprets the result. There is no persistent case, dynamic tool choice or production write. The placement receipt chooses the RAG service only. It names source owners, applicable versions, update cadence, entitlement, ranking evaluation, citation requirements and correction propagation. The product records user feedback and answer use, while the employee owns the decision. Adding a general agent runtime would introduce state and trajectory obligations without changing the outcome.

Add a case without adding open planning

The assistant later supports a review case that gathers documents, requests missing evidence, waits for a response and routes the file to an approver. These steps are known and policy controlled. A deterministic workflow owns durable case state, deadlines, events and approvals. The RAG service supplies evidence at defined nodes. Model calls may classify or draft, but a state machine selects the next allowed transition. Recovery resumes from a checkpoint and rechecks current policy. The workload has become multi-step, yet a model-proposed plan offers no demonstrated benefit. Placement changes because state changed, not because the organisation wants an agent label.

Introduce bounded investigation where paths genuinely vary

Investigators sometimes need to follow references across several repositories, compare events with authorised APIs and choose the next read-only query from new observations. A bounded agent runtime can reduce manual navigation. Its contract limits source classes, tools, iterations, elapsed time, cost and disclosure. It cannot send external communication or update a record. The investigator can inspect the evidence trail, steer the search and take over. The runtime logs tool requests and observations while the RAG service preserves per-source entitlement, freshness and citations. Dynamic selection earns a place because the useful path cannot be enumerated economically in advance.

Do not search operational truth that can be reconstructed

The investigation needs a current account status. The platform does not embed periodic snapshots and ask semantic retrieval to infer the latest value. A typed API reconstructs authoritative state using the case principal and current time. The response carries version and provenance into the trajectory. Retrieval remains appropriate for explanatory documents and historical evidence. This split prevents a high similarity result from overriding the system of record and avoids teaching the agent that every information need is a vector query. Freshness policy follows the source and decision consequence, not the convenience of one context interface.

Cross the action boundary through a new contract

Management proposes allowing the investigator to place a temporary reversible hold. This is a new workload object. The Decision-Right Record names domain outcome ownership, authorised principals, conditions, affected customers, risk acceptance and kill authority. The runtime receives a typed tool that validates the current case, role, amount, reason and expiry. A human confirms with material evidence visible. An idempotency key prevents duplicate holds after timeouts. The tool receipt records acceptance and final system state. Compensation releases the hold under separate authority. Past read-only success does not count as evidence for this transactional permission.

Evaluate retrieval, planning and action separately

The release suite contains retrieval cases for source recall, ranking, entitlement, freshness, grounding and citation. Investigation cases test tool selection, stopping, budget, contradictory observations and hand-off. Transaction cases test authorisation, confirmation, duplicate events, partial response, compensation and outcome. End-to-end scenarios connect them, but dashboards retain component failures. A completed case with an unsupported citation is not fully successful. A precise answer followed by an unauthorised hold is an action failure. Separating evidence lets the correct owner repair the index, runtime, tool, policy or human process.

Design concurrency and durable state deliberately

Case state stores declared workflow facts, pending transitions, tool receipts and human decisions. Conversation text and model-generated working notes are not automatically system truth. Updates use version checks so two workers do not overwrite the case. Long-running tasks have leases, timeouts and owners. On resume, the runtime reloads authoritative state and revalidates delegation, entitlements, tools, budgets and model versions. Sensitive intermediate material has retention and access rules. The agent platform can manage execution mechanics, but domain services remain authoritative for customer and transaction state.

Operate retrieval and runtime at different cadences

Policy documents may enter through scheduled review, with urgent corrections published under a controlled source process. Index releases carry corpus and entitlement tests. The agent runtime may deploy more frequently to improve tool handling or recovery. A shared release register links compatible versions without forcing simultaneous deployment. If an agent update changes query construction materially, retrieval scenarios rerun. If an index changes, relevant end-to-end cases run before wider use. Independent cadence protects ownership and throughput while compatibility evidence preserves the product journey.

Fund the common substrate once

Both services use enterprise principals, delegation, policy decisions, evaluation registration, trace identifiers, provenance vocabulary, cost allocation, incident severity and lifecycle receipts. Those contracts have one accountable operator and versioned interfaces. Retrieval retains its index and source controls; the runtime retains case and action controls. Shared dashboards can correlate a customer case without copying protected content into one universal store. Finance can attribute retrieval, model, tool and human review cost to the journey. Consolidation removes repeated control integration rather than requiring one engineering team to own every service.

Test outage and recovery as a joint journey

An exercise expires retrieval evidence during an active case, times out the hold response after commit and revokes the investigator’s delegation. The RAG service refuses stale or newly unauthorised access. The workflow pauses at the evidence node. The runtime queries the hold tool with the original idempotency key and learns that the effect committed, then blocks further action after revocation. The human owner receives the case with source, trajectory and action receipts. Teams verify that kill controls propagate and that compensation requires current authority. This test crosses services without merging their responsibilities.

Know when distinct services are unnecessary

A smaller product family may use one runtime that includes indexing and retrieval. Keep logical contracts even if deployment is unified. Separate source administration from tool administration, expose retrieval evidence, and measure both service behaviours. If the integrated runtime can meet scale, ownership and release needs, another platform adds no value. Conversely, if many read-only products need retrieval but only a few cases need agency, a standalone RAG service prevents the broad estate from inheriting transaction-grade cost. The architecture follows actual reuse and failure, not a rule that every enterprise must operate both.

Retire agency when learning reveals a stable route

Trajectory review may show that successful investigations follow a small set of approved query sequences and decision rules. The product can encode those sequences in deterministic orchestration, keep a bounded model at uncertain classification steps and remove open planning. This reduces evaluation surface, runtime cost and incident ambiguity. The placement receipt records the reverse migration, preserves relevant action evidence and closes unused tools and state. Agency has served its learning purpose. Removing it is architectural progress when the remaining workflow is clearer and equally effective.

Portfolio review compares placement receipts across products. It looks for repeated retrieval contracts, recurring state and recovery patterns, duplicated controls, unsupported exceptions and services with little demand. The review may expand a shared capability, separate a strained lifecycle or retire an abstraction that hides more than it standardises. Decisions cite production journeys and owner capacity. They do not reward a platform for collecting workloads under one label or punish teams for choosing an explicit workflow where it remains the safer, cheaper operating form.

Interactive instrumentRAG-Agent Platform Boundary Router

Set evidence, state, branching, authority, recovery, ownership and reuse conditions. The Router returns one of exactly five routes with its contract, shared substrate, control gaps and migration trigger. It never returns an autonomy or maturity score.

Exactly five outcomesChoose the smallest adequate control surface

Evidence boundaryMechanism research does not establish enterprise placement

RAG research supports combining retrieved evidence with generation and analysing retrieval, augmentation and evaluation. Agent research demonstrates experimental patterns for interleaving reasoning, observations, memory and tool use. It does not imply that every tool-enabled application needs autonomous planning or that research agents are production-ready.

W3C PROV-O, OpenAPI, CloudEvents and OpenTelemetry support provenance, typed interfaces, events and interoperable operational evidence. They do not choose authority or system-of-record truth. Production-ML research informs entanglement and maintenance. NIST informs context, lifecycle, human and third-party governance without prescribing one platform product.

OWASP records inform excessive-agency and prompt-injection boundaries. They support minimising functionality, permissions and autonomy while enforcing downstream authorisation. The EU AI Act record applies only to relevant systems, actors, provisions, jurisdictions and timing. The Workload Control-Surface Map, four-zone architecture, two contracts, placement receipt and Boundary Router are this article’s synthesis.

The decision is successful when the workload receives enough shared capability to operate safely and repeatedly without inheriting unnecessary runtime complexity. Retrieval remains evidence assembly. Workflow remains explicit process. Agency remains bounded model-mediated choice. Shared control does not require hidden sameness.