Your Agent Architecture Should Survive a Model Change

An illustrative renewal agent has used the same model for six months. A new model appears with better tool use and a lower price. The team wants to switch. The CRM mappings, support sources, discount policy, approval route, and accepted outcome have not changed.

If replacing the model requires rebuilding all of those parts, the architecture has fused business operations to one provider. If the team can swap the model without rerunning the workflow’s evaluations, it has hidden the risk in the opposite direction.

A model change should be possible, bounded, and observable.

Keep business meaning outside the model contract

The model should not be the only place that knows which CRM field represents the renewal date, which policy has authority, or which action needs approval.

Those facts belong in maintained contracts:

• context contracts define sources, fields, freshness, authority, and permitted use;
• tool contracts define inputs, outputs, side effects, errors, and retry behavior;
• policy checks define action boundaries and required approvals;
• outcome contracts define what “complete” means; and
• evaluation cases define the behavior that must remain acceptable.

The model interprets the request and helps plan the work. It operates through interfaces whose business meaning can be reviewed without reverse-engineering a prompt.

Standards improve portability but do not prove equivalence

Protocols such as the Model Context Protocol can reduce the custom work required to expose tools and context across compatible systems. They help define an interface boundary, but they do not make the behavior on either side interchangeable.

Compatibility does not mean two models will use the same tool correctly. They may choose different tools, construct different arguments, stop at different points, or respond differently to a partial failure.

Portability therefore includes an evaluation obligation. The new model has to run the workflow’s representative cases before release.

Test the decisions that can change the business state

For the renewal agent, the test set should cover more than answer quality:

• select the current contract when CRM disagrees;
• avoid disclosing a restricted support incident;
• identify a missing decision owner;
• stop a concession above the delegated limit;
• retry a safe read but not duplicate a committed write; and
• return an evidence-complete escalation when context conflicts.

Cost and latency also belong in the comparison. A stronger model can be uneconomical if it expands every tool payload or repeats work. A cheaper model can raise cost per accepted outcome if reviewers correct more cases.

The Coryntas agent operating model evaluates context, tools, policy, and outcomes as one system. That makes model selection a controlled release decision rather than a permanent architectural commitment.

Preserve state in formats another component can inspect

Long-running work becomes difficult to migrate when all state lives in a provider-specific conversation. The system should retain stable task identifiers, selected source references, action records, approval status, and unresolved exceptions outside the model’s private context.

This does not require storing hidden reasoning. It requires storing the observable state needed to resume and audit the workflow.

The same principle applies to tools. A function that returns a stable customer identifier and explicit source timestamps is more portable than a tool that returns provider-specific prose for the model to reinterpret.

Openness has an operating cost

Supporting multiple models expands the test matrix. Behavior may drift between releases from the same provider. A lowest-common-denominator interface can prevent a specialist model from using a valuable capability. Some workflows may legitimately standardize on one model until an alternative passes their cases.

Fabria exists to design, validate, and evolve the tools and workflows agents use as the technology changes. Openness is useful when those changes remain governable.

The goal is not to switch models constantly. It is to keep the enterprise’s context, controls, and operating knowledge from becoming collateral whenever a better model arrives.