The foundation model is only one dependency in an agentic system

Model choice dominates many agent architecture discussions because it is visible, comparable and easy to name. Production incidents rarely respect that boundary. An outdated policy retrieved from the wrong index, an over-scoped credential, a changed tool schema or an unsafe retry can determine the outcome even when the model behaves exactly as tested.

The foundation model is an important dependency. It is not the system. An agentic system is a dependency graph that turns objectives and context into actions and effects. Every node in that graph can change what the system knows, what it may do, what it believes happened and whether an operator can recover.

The architecture decision is therefore not “Which model wins?” It is “Which combination of components produces acceptable outcomes under known operating conditions, and how will we know when that combination changes?”

Draw the path from intent to effect

Start with one business action rather than a vendor diagram. Suppose an agent prepares and executes a supplier onboarding step. The path may include:

1. a request enters through a user interface or event;
2. an identity layer establishes the requesting principal;
3. retrieval assembles policy, supplier and contract context;
4. a model proposes a plan and tool arguments;
5. orchestration checks preconditions and sequences calls;
6. an authorisation service decides whether the operation is permitted;
7. a connector changes the procurement system;
8. a verifier reads back authoritative state; and
9. logging and monitoring make the trajectory reviewable.

The model participates in planning and interpretation. It does not independently establish identity, make policy authoritative, commit the transaction or prove success. NIST’s tool-use work distinguishes perception, reasoning, resource management and action tools and highlights that access patterns, environment trust and observability all affect risk. That is a system view, not a model leaderboard.

Treat every behavioural input as a dependency

A useful dependency map has at least eight domains:

Domain	What can change behaviour	Typical failure
Model	version, provider settings, decoding, fallback	capability shift or inconsistent output
Instructions	system prompts, policies, examples	conflict, omission or unreviewed update
Context	sources, retrieval logic, ranking, freshness	missing, stale or poisoned evidence
Tools	definitions, schemas, adapters, endpoints	wrong operation, semantic drift or partial success
Authority	identities, tokens, scopes, approvals	excessive privilege or confused delegation
State	workflow record, memory, checkpoints, queues	duplicate effect, lost progress or false completion
Verification	assertions, evaluators, human checks	self-confirmation or weak oracle
Operations	limits, monitors, incident and rollback paths	uncontrolled degradation or slow detection

Research on foundation-model agent architecture catalogues choices across design-time and runtime operations, while a broader survey of emerging agent architectures describes planning, execution and reflection patterns. Neither implies that one architecture is universally superior. The decision depends on the workflow’s quality, latency, security, cost and accountability constraints.

Component quality does not add up to system quality

A model can pass a tool-use benchmark while the deployed connector maps its argument to the wrong field. A retrieval system can return relevant documents while the agent treats a superseded version as current. An authorisation service can make a correct decision while the runtime reuses an approval after the plan changes.

This is composition risk: individually plausible components create an unsafe interaction. It appears at interfaces, timing boundaries and shared state. Three checks expose it:

• Semantic contract: Do both sides attach the same meaning to an input, status or error?
• Authority contract: Does the called component verify who is acting, on whose behalf and within which grant?
• State contract: Can the caller distinguish proposed, accepted, committed, rejected, unknown and reversed outcomes?

Schema validation covers shape, not meaning. A tool may accept customer_id as a string while the runtime supplies an account reference from a different tenant. A response may say success: true when it means “accepted for processing,” not “completed.” End-to-end tests should assert the business state and prohibited side effects.

Version the system, not just the model

Reproducibility requires a release manifest that names all behaviourally material dependencies. At minimum, capture:

• model identifier, provider, endpoint configuration and fallback policy;
• system instructions, task templates and policy rules;
• retrieval index snapshot, embedding model, ranking logic and source versions;
• tool catalogue, definitions, adapter versions and endpoint contracts;
• identity provider, scopes, policy version and approval rules;
• orchestration code, state schema, retry and timeout configuration;
• verification rules, evaluators and human-review instructions; and
• feature flags, budgets, rate limits and operational thresholds.

“Same model” is not a valid regression claim if the tool catalogue, prompt or retrieval corpus changed. Equally, a model update does not always require a full redesign. The manifest lets the team identify affected paths and run proportionate tests rather than either ignoring the change or retesting everything blindly.

The NIST AI RMF Core calls for regular monitoring of pretrained models and third-party resources, production behaviour and post-deployment change management. A system manifest supplies the object being monitored.

Design replacement and degradation paths explicitly

Treating the model as a dependency makes substitution conceivable, but not automatically safe. A replacement may format tool calls differently, respond to uncertainty differently, use more context, refuse different tasks or exploit a larger step budget. Portability requires a stable system contract and workflow-level evaluation.

Define three modes before production:

1. Normal mode: the approved component set and authority envelope.
2. Degraded mode: narrower tools, read-only operation, stronger approval or a simpler model when a dependency is impaired.
3. Stop mode: no further action when identity, policy, authoritative state or verification is unavailable.

A model-provider outage should not silently trigger an untested fallback with different behaviour. A retrieval failure should not invite the model to fill gaps from general knowledge. A tool timeout should not become an automatic duplicate. Each dependency needs a declared failure posture.

The UK NCSC secure-design guidance recommends making model choices through a threat model and reassessing them as security understanding changes. Apply the same discipline to every surrounding component.

Evaluate the graph at three levels

Use three complementary test layers:

• Component tests establish a narrow property: retrieval recall, policy decision correctness, adapter idempotency or model instruction following.
• Contract tests exercise an interface: error meanings, identity propagation, version compatibility and state transitions.
• Workflow tests run representative and adverse tasks through the whole action path and inspect authoritative outcomes.

Workflow tests should vary more than the user prompt. Change policy freshness, tool latency, partial failure, permission scope, conflicting context, interrupted state and fallback availability. Record the trajectory and the final environment state. If the agent says it completed an operation but the business record did not change, the workflow failed.

This layered approach supports diagnosis. A failed workflow can be traced to model choice, context assembly, tool semantics, policy enforcement or operations instead of being recorded vaguely as “the agent hallucinated.”

Assign owners to dependencies and decisions

No single team necessarily owns the whole graph. Platform engineering may own runtime and observability; security may own identity policies; a domain team may own business rules and test cases; procurement may own provider terms. Shared ownership is workable only when decision rights are explicit.

For each dependency, name:

• an owner for acceptable configuration and change approval;
• a source of truth for version and health;
• a monitoring signal and escalation threshold;
• a replacement or recovery procedure; and
• an owner for end-to-end release acceptance.

The final owner cannot outsource the system decision to a model provider. Provider documentation can support a component assessment, but the deployer chooses tools, data, authority and operational context.

The foundation model deserves careful evaluation. So does everything that gives its output context, permission and consequence. Map the dependency graph, version it as a system and test the effects at its edge. That is where an agent architecture becomes reviewable.