How to separate the organizational assets that should endure from the models, frameworks, and agent patterns that should remain free to evolve
What Makes an Agent Platform More Than an LLM Wrapper
“Agent platform” is one of those terms that means different things depending on who is using it.
To an AI engineer, it may mean a model, a prompt, a set of tools, and an orchestration loop. To a platform engineer, it may mean a reusable runtime. To a security team, it may look like an emerging control plane. To a product team trying to ship an agent, it can feel like another abstraction they are being asked to adopt before the value is obvious.
None of these interpretations is entirely wrong. They are simply looking at the same problem from different parts of its lifecycle.
This is also why conversations about agent platforms often turn into a checklist: identity, tools, memory, observability, evaluation, human approval, governance, and so on.
All of those capabilities matter. But the checklist does not answer the more important question:
What should belong to the platform, and what should remain free to evolve with each agent?
My view is that the most useful boundary is not between the LLM and everything around it. It is between the parts of the system that should endure and the parts we should expect to replace.
Start with the rate of change
The agent ecosystem is moving too quickly to assume that today’s model, framework, orchestration pattern, or memory architecture will remain the right one for long.
Models improve. Tool-calling conventions change. Context windows expand. Frameworks appear, converge, and fall out of favour. Capabilities that once required significant orchestration sometimes become native model features.
An organization should be able to take advantage of those changes without repeatedly rebuilding the parts of the system that encode how the organization itself operates.
That suggests two broad categories.
Durable assets evolve relatively slowly. These include company intellectual property, business logic, organizational policies, authorization boundaries, domain knowledge, audit requirements, tool contracts, expected behaviours, and the operational guarantees the business depends on.
Durable does not mean static. Policies change. Business logic evolves. Knowledge becomes stale. The distinction is that these assets are likely to outlast several model, framework, and agent-harness cycles. They therefore deserve deliberate ownership, stable interfaces, controlled evolution, and investment at an organizational level.
Non-durable assets are the implementation choices we should expect to experiment with or replace. These include model selection, prompt construction, planning strategies, agent frameworks, retrieval techniques, model-specific tool schemas, and parts of the orchestration harness.
The exact line will vary across organizations. But the principle is straightforward:
Do not bind the organization’s durable knowledge, controls, and business behaviour to an agent implementation that is likely to be replaced.
A platform becomes valuable when it creates that separation.
Durable does not mean centralized
This can easily be misread as an argument for putting everything into one large platform.
That would be the wrong conclusion.
Centralizing every agent-specific decision would slow experimentation and force teams with different needs into abstractions that may not fit. A support agent, a sales agent, an administrative agent, and a background automation may have very different planning loops, memory strategies, interaction patterns, and risk profiles.
The platform should centralize what should not diverge unintentionally.
Identity semantics should not be reinvented by every agent team. Neither should foundational authorization, audit records, policy enforcement, tool safety, or the definition of sensitive data. Teams should not independently decide what evidence must be retained after a consequential action or how a user’s authority follows a request through an agent and into a downstream tool.
Those are organizational obligations. Inconsistent implementations do not create useful experimentation. They create gaps.
By contrast, whether an agent uses one model or another, how it structures its prompt, whether it uses an explicit planner, or how it retrieves task-specific context may be perfectly reasonable areas for experimentation.
A good platform does not eliminate local choice. It protects the areas where local divergence would create organizational risk while leaving the rest open to learning.
Company knowledge should not live only in prompts
Business logic is one of the clearest examples of this boundary.
Prompts are useful for communicating behaviour to a model. They are a poor place to make organizational knowledge durable.
If a policy, business rule, or important definition exists only inside an agent’s system prompt, it becomes coupled to that agent. Another team may duplicate it with slightly different wording. A model migration may change how it is interpreted. A prompt refactor may unintentionally alter behaviour. It may also become difficult to determine which version of the policy governed a past action.
The durable source of truth should exist outside the prompt.
An agent may receive a model-friendly representation of a policy, but that representation should not become the policy itself. Important business rules may require deterministic enforcement rather than model interpretation. Domain knowledge should have clear ownership, provenance, access restrictions, and freshness expectations.
The same applies to tools.
A protocol adapter or model-specific function definition is replaceable. The underlying business capability is not.
“Update an opportunity,” “approve a discount,” or “publish customer-facing content” represents more than a function signature. It includes authorization rules, validation, side-effect semantics, and organizational expectations.
The durable asset is the capability and its contract. The adapter through which a particular model invokes it should remain replaceable.
Identity must represent both the agent and its authority
Agent identity is another area where simple solutions become incomplete very quickly.
An agent may have its own identity. In many organizations, that will be useful or necessary. It allows the system to distinguish one workload from another, assign agent-specific restrictions, attribute activity correctly, and avoid making every automated interaction appear as though it was performed directly by a human.
But giving an agent an identity does not answer the more important question:
Under whose authority is it acting?
For an interactive agent, effective access still needs to account for the user requesting the action. An agent should not gain access to data or operations simply because its service identity has broad credentials.
The actual authorization decision may depend on the intersection of:
- The user
- The client application
- The agent or workload
- The requested action
- The resource being accessed
- The business context in which the request occurs
The agent identity tells us what is acting. Delegated authority tells us what it is allowed to do on someone’s behalf.
For background or fully automated agents, this becomes even more important because there may be no active user at execution time. These agents need an explicit, policy-defined mandate: which events they may respond to, which resources they may access, what actions they can take, under which conditions, and when that authority must be reviewed or renewed.
A service credential alone is not a policy.
The platform needs to carry this context into downstream enforcement points so that authorization does not disappear once the model chooses a tool.
Authorization must account for sequences, not only individual calls
Traditional authorization often evaluates one request at a time. Agent behaviour can make that insufficient.
A user may be allowed to read a customer record. The same user may be allowed to send an email. That does not necessarily mean an agent should be allowed to read sensitive information and send it to any external address.
Each individual operation may be permitted while the sequence creates an unacceptable result.
This does not mean every plan needs to be interpreted by a complex policy engine before execution. It does mean that a production platform must be capable of considering context, data movement, destination, scope, and consequence—not only whether a token contains the right API scope.
Protocols such as MCP can standardize how clients connect to tools and how authorization is initiated. That is useful infrastructure. But protocol-level authorization does not, on its own, encode an organization’s business policies or determine whether a sequence of individually valid actions should be allowed.
Interoperability tells systems how to communicate. It does not make every permitted combination of actions appropriate.
Auditability must preserve provenance
Once agents can take meaningful action, auditability cannot be treated as a debugging feature added later.
The organization needs to know:
- Who initiated or authorized the work
- Which agent and client participated
- Which policy and permissions were applied
- What information influenced the action
- Which tools were invoked
- Whether a human reviewed or modified the action
- What actually changed in the external system
A raw conversation transcript is not enough.
It may omit enforcement decisions made outside the model. It may contain sensitive information that should not be retained indefinitely. It may show what the model requested but not what the downstream system eventually committed. It may also be too verbose and unstructured to serve as a useful activity record.
The platform needs explicit provenance linking intent, identity, policy decisions, approvals, tool execution, and resulting state.
Those records should not exist only for incident response. Agent activity and access patterns should be reviewed regularly. This is especially important for fully automated agents, which may continue operating within technically valid credentials long after the assumptions under which those permissions were granted have changed.
Auditability is not only the ability to reconstruct a failure. It is the ability to verify that the system continues to operate within its intended mandate.
Keep the behavioural contract durable
Evaluation also has durable and non-durable parts.
The judge used to score an agent may change. The model running the evaluation may change. The evaluation framework may be replaced.
What should endure is the behavioural contract.
The organization should retain examples of important tasks, known failures, policy expectations, prohibited outcomes, required approvals, and the external states that should result from successful execution.
These represent what the business expects from an agent independently of which model currently implements the behaviour.
This matters because model migrations are often discussed as though models were interchangeable components. They are replaceable, but they are not behaviourally identical.
A new model may perform better overall while changing tool selection, escalation frequency, tone, latency, or adherence to a particular business rule. The platform should make experimentation easy, but it should also make the consequences of that experimentation measurable.
The durable investment is not a particular judge prompt. It is the accumulated understanding of what correct and safe behaviour means for the organization.
The runtime must preserve operational expectations
Not every durable asset is knowledge or policy. Some are operational guarantees.
When an agent initiates a consequential action, the organization may expect that it will not happen twice because of a retry. It may expect an approval to remain attached to the exact action that was reviewed. It may expect a cancelled workflow to stop. It may expect a partially completed process to be recoverable, or at least visible.
The framework used to implement these guarantees may change. The guarantees themselves should not.
Agent execution inherits familiar distributed-systems problems: timeouts after successful writes, duplicate requests, partial completion, concurrent updates, stale approvals, and external systems without a shared transaction boundary.
The model may decide what it wants to do next. It cannot guarantee the execution semantics of what happens afterward.
A production platform therefore needs to preserve durable operational contracts while remaining open to changes in how the reasoning loop is implemented.
How the need for a platform emerges
Our experience at Highspot followed a pattern I suspect many organizations will encounter.
The need for an agent platform did not begin with a desire to create a grand architecture around AI. It emerged as different agent initiatives started running into the same questions.
How should tools be exposed? How should user authority carry into an action? What context should persist? Where should human review occur? How should agent activity be observed and audited? How should multiple agents coexist without each building its own version of the same foundational capabilities?
The lesson was not that every agent should be built the same way.
It was that some decisions were specific to an agent, while others were organizational decisions being rediscovered inside individual implementations.
That is the point at which a platform becomes useful.
It allows teams to invest once in the concerns that should remain consistent while preserving freedom for each agent to evolve. The platform is not successful because every team uses every capability it provides. It is successful when teams no longer need to rebuild or reinterpret the organization’s durable foundations in order to ship an agent.
The platform should absorb change, not prevent it
There is a natural tension in platform design.
If the platform moves too slowly, product teams will bypass it. If it tries to anticipate every possible agent pattern, it becomes large, rigid, and difficult to adopt. If it exposes only the lowest common denominator, it preserves consistency by limiting what agents can do.
The answer is not to freeze the agent stack. It is to create explicit boundaries around change.
Models should be replaceable. Prompting approaches should remain open to experimentation. Teams should be able to try new planning loops, memory techniques, interaction patterns, and frameworks without waiting for the entire organization to standardize around them.
At the same time, a model change should not require identity to be reinvented. A framework change should not erase audit provenance. A new retrieval technique should not bypass data-access rules. A new tool protocol should not redefine business authorization. A new agent should not establish its own interpretation of company policy simply because it uses a different harness.
The platform should make technological evolution less disruptive, not less frequent.
More than a wrapper
Calling an AI product “just a wrapper around an LLM” is usually meant to suggest that the surrounding system contributes little enduring value.
Sometimes that criticism is fair.
A thin layer that forwards a prompt to a model and displays the result is a wrapper. It may still be useful, but it offers little protection against model or platform commoditization.
An agent platform becomes more than a wrapper when it establishes a durable boundary between the organization and the rapidly changing technology used to build agents.
The model provides reasoning. The harness organizes that reasoning. The platform preserves what the organization should not have to rediscover every time either one changes:
Its authority model. Its business rules. Its intellectual property. Its operational guarantees. Its evidence. Its understanding of acceptable behaviour.
That is the durable value of an agent platform.
Not that it contains the most components, supports the most frameworks, or builds the deepest abstraction around the model.
It allows the organization to keep evolving the agent without repeatedly rebuilding the organization around it.