Why Sierra Is the Wrong Approach to Agentic Customer Support

Sierra vs Decagon for enterprise customer support, and what else belongs on the shortlist? Both are betting on the same abstraction: one increasingly capable agent that a company rents as a service, with outcomes as the interface. Fini is built on a different bet: the company should own the knowledge, policy, decisions, and action permissions, and treat any single agent, including Fini’s own, as replaceable. That distinction, not a feature checklist, is the real reason a third option belongs in this conversation.

The future of customer support is not one proprietary agent optimizing outcomes. It is a governed, modular operating system for knowledge, decisions, actions, tickets, and humans.

Sierra is one of the most impressive companies in customer-service AI.

It has strong founders, significant enterprise adoption, credible customer results, and a product that addresses many of the hard engineering problems teams encounter when deploying AI agents. Sierra’s public platform includes goals and guardrails, composable skills, simulations, debugging, omnichannel deployment, voice, observability, memory, and an SDK that lets technical teams define customer journeys as code.

This matters because the easy version of a critique would also be the weakest: Sierra is not simply a chatbot wrapped around a language model. It has built substantial infrastructure.

The disagreement is more fundamental.

Sierra’s central idea is that companies should consume the agent itself as a service. The business defines the outcome. Sierra’s platform builds, runs, and improves an agent that pursues that outcome across channels. Pricing is tied to completed outcomes rather than software usage.

That is a coherent model. It is also the wrong long-term abstraction for customer support.

Customer support is not one agent, one conversation, or one optimized outcome. It is an operating system composed of organizational knowledge, customer state, policy decisions, permitted actions, unresolved work, human judgment, and continuous learning.

The company must own that operating system.

An AI agent should execute within it. The agent should not become it.

What Sierra is betting on

Sierra describes Agent OS as a platform for building, managing, and optimizing customer-facing agents. Its Agent SDK allows teams to define goals and guardrails, combine reusable skills, tune the degree of determinism, run simulations, inspect traces, and deploy one agent across chat, phone, email, SMS, and messaging.

In March 2026, Sierra extended this idea into “Agents as a Service”. Ghostwriter, its agent-building agent, can ingest standard operating procedures, transcripts, whiteboard images, recordings, or a natural-language description of an objective. It identifies behaviors and edge cases, then creates a production agent. Explorer analyzes customer conversations for improvement opportunities. Sierra describes the resulting loop as an “agent assembly line” in which agents analyze, improve, test, and prepare changes for review.

The company has also moved beyond reactive support. Its Agent Data Platform combines customer memory with AI decisioning. Sierra’s Context Engine learns which customer signals matter for particular decisions and uses the outcomes of prior interactions to improve subsequent choices. Horizon agents pursue outcomes across days or weeks.

The strategic model is consistent across these products:

1. Give the agent broad context.

2. Define business outcomes and guardrails.

3. Allow the agent to decide how to achieve those outcomes.

4. Learn from the results.

5. Pay when the outcome is delivered.

This model is attractive because it hides complexity. A company does not need to assemble models, orchestration, evaluation, memory, channel infrastructure, and observability independently. It asks for an outcome and receives an agent.

But customer support is one of the places where hiding complexity can also hide control.

1. Outcomes are useful metrics, but dangerous control surfaces

Sierra has made outcome-based pricing part of its identity. Its product overview says customers work with an expert agent-development team and “only pay for the value delivered.” Horizon extends the model to long-running agents: the business defines outcomes such as saves, lifetime value, or qualified leads, and the system learns which decisions improve them.

Commercially, this is compelling. It aligns the vendor with a measurable result rather than seats, tokens, or platform access.

Architecturally, however, an outcome is not a complete specification of good customer support.

Consider “case resolution.” It sounds objective until a team has to define it.

• Is a case resolved when the customer stops replying?

• Does a repeated contact three days later reopen the original outcome?

• Does a refund count as a resolution if it violated policy?

• Does a retained customer count as a successful save if the offer was economically irrational?

• Does containment count when the customer gave up?

• Who determines whether the customer’s underlying problem was solved?

Sierra understands this distinction. In its own Pendulum case study, the customer found that a previous chatbot’s seemingly strong containment rate included conversations customers had abandoned before receiving a solution. Sierra improved the system and reports more than 75% case resolution. The story is a good illustration of Sierra’s value—but also of the fragility of the metric itself. A measured outcome is only as trustworthy as its definition and attribution.

The same problem becomes more consequential when an agent optimizes retention, conversion, or lifetime value.

Customer support contains competing objectives:

• solve the customer’s stated problem;

• comply with policy and regulation;

• protect the customer from harm;

• minimize unnecessary concessions;

• preserve long-term trust;

• manage operating cost;

• recognize when the customer’s interest should override a short-term commercial target.

These objectives cannot always be collapsed into one score. NIST has noted that sociotechnical qualities such as privacy, interpretability, safety, and bias involve human judgment and cannot be reduced to a single threshold or metric. Research on AI safety has long described the related problem of reward hacking: a system can optimize the stated objective in ways that violate the designer’s underlying intent (Amodei et al., 2016; DeepMind’s specification-gaming examples).

The argument is not that Sierra’s agents will deliberately game every metric. Sierra provides guardrails, testing, and human review. The problem is the control philosophy: treating an outcome as the primary instruction and policies as constraints around the optimizer.

For consequential customer operations, the safer hierarchy is reversed.

Policy and customer rights should define the permitted decision space. Outcomes should help choose among the actions that remain.

An outcome is a measure. It should not become the constitution.

2. Guardrails are not a substitute for policy architecture

Sierra’s SDK prominently combines goals with guardrails. Its Horizon product goes further, describing “full autonomy by default” with exact wording where it matters. The Agent Data Platform presents AI decisioning as an alternative to static, one-size-fits-all rules.

This framing reflects a common view in agent design: rules are rigid, while AI can reason through nuance.

That is partly true. Many legacy customer-service workflows are brittle decision trees that force every customer through the same path. Agents can interpret natural language, gather context, handle ambiguity, and choose among complex actions more effectively.

But some “static rules” are not legacy workflow debt. They are policy.

A fintech may prohibit a refund above a defined amount without approval. An insurer may require particular evidence before changing a claim. A healthcare company may restrict which topics an automated system can address. A subscription company may have different cancellation rights by jurisdiction and purchase channel.

These rules should not exist primarily as natural-language guardrails surrounding an optimizing agent. They should be represented as explicit, versioned, testable decision boundaries.

The difference is important:

• A goal tells the agent what success looks like.

• A guardrail tells the agent what it should avoid.

• A policy defines what is authorized.

• An action contract defines what the system is technically permitted to execute.

Collapsing these layers into one agent configuration creates ambiguity. The model is asked to interpret the objective, remember the restriction, reconcile competing sources, and select the action in the same reasoning process.

A stronger design separates them.

The agent can interpret the customer’s request. A policy engine determines the allowed decision space. A typed action layer enforces permissions, limits, required evidence, idempotency, and approvals. The agent may choose among permitted actions, but it cannot reason its way beyond the boundary.

Guardrails remain valuable. They are one defense. They should not be the system of record for operating authority.

3. Customer context is not organizational knowledge

Sierra’s Agent Data Platform makes a strong argument that an agent should remember the customer across sessions and channels. It unifies structured customer data—billing history, purchases, account information—with unstructured conversations. Context Engine then identifies which signals matter for which decisions.

This is useful. A customer should not have to repeat information the company already knows. A failed troubleshooting step should inform the next interaction. A prior promise should not disappear because the customer changed channels.

But customer context answers a different question from organizational knowledge.

Customer context asks:

What do we know about this customer and this relationship?

Organizational knowledge asks:

What does the company believe, which source is authoritative, who owns it, where does it apply, and when may it be used?

An agent needs both.

A full view of the customer does not resolve two contradictory refund policies. A detailed conversation history does not tell the system whether an internal Slack message supersedes the published procedure. More context does not create authority.

Sierra’s platform supports knowledge sources and a knowledge engine. Its public positioning, however, centers on configuring or connecting knowledge so that the agent can use it. That is retrieval. The deeper requirement is knowledge governance.

Durable operational knowledge should exist in a canonical, inspectable representation owned by the company: policies, procedures, definitions, exceptions, source authority, scope, effective dates, version history, and relationships. Vector indexes and agent-specific context should be generated projections of that source.

Otherwise, the organization’s operating logic becomes inseparable from the platform that interprets it.

The company may own its original documents. It may be able to inspect agent traces and export data. But if the reconciled meaning—the learned relationships, precedence, decision logic, and behavioral improvements—lives primarily inside a vendor’s agent configuration and context engine, the most valuable part of the system is still being rented.

Sierra’s recent phrase is “rent the intelligence, own the relationship.” The stronger principle is:

Rent interchangeable models if useful. Own the relationship, the knowledge, the policies, the evaluations, and the control plane.

4. The agent is the wrong unit of abstraction

Sierra repeatedly emphasizes one agent deployed across every channel. That is easy to understand and attractive to buyers. Customers receive one consistent identity across chat, voice, email, SMS, WhatsApp, and other surfaces.

But the future customer-support system is not one agent with many interfaces.

It is a network of specialized components operating on shared state.

Consider what happens around a single difficult support issue:

• an intake component classifies the request;

• a knowledge component resolves the applicable policy;

• an identity component verifies the customer;

• an action component calls an internal API;

• a risk component checks permissions and limits;

• a ticketing component records state, ownership, and deadlines;

• a quality component evaluates the result;

• a human specialist handles the portion requiring judgment;

• an improvement component proposes a knowledge or workflow change afterward.

The customer may experience this as one coherent conversation. Internally, it should not be one unconstrained reasoning loop.

The distinction is similar to a modern application: the user sees one product, but the system is composed of services with narrow responsibilities, permissions, and failure boundaries.

This matters for channels as well.

Voice requires low latency, interruption handling, confirmation, and strict protection against misheard high-impact actions. Email is asynchronous, longer-form, and often tied to existing ticket state. Slack agents serve internal teams and may access different knowledge or tools. A CLI component used by a technical team needs precise outputs and composability rather than a branded conversational persona.

“Build once, deploy everywhere” is a good distribution promise. It is a risky architecture if it implies that the same reasoning policy, context assembly, and autonomy level should govern every surface.

Shared knowledge and identity make sense. Shared permissions do not always. Shared tone can help. Shared failure modes do not.

The right abstraction is a customer-support control plane that composes channel-specific and task-specific agents—not a single agent that becomes the control plane.

5. A conversation is not the durable unit of customer support

Agent platforms naturally organize their product around the conversation because that is where the model operates.

Customer operations are organized around work.

A customer issue may span three channels, two departments, several asynchronous steps, an external dependency, a promised follow-up, and a regulatory deadline. The conversation ends. The obligation does not.

This is why ticketing systems survived every previous attempt to replace them with chat. A ticket is not merely a transcript container. It is a durable record of unresolved work:

• current state;

• responsible owner;

• customer and organization;

• priority and SLA;

• required next action;

• dependencies;

• approvals;

• audit history;

• resolution and reopening logic.

An agent can participate in that system, but memory is not a substitute for it. Persistent conversational context helps the agent remember. Ticket state makes the organization accountable.

The next generation of customer support should therefore be an agentic ticketing system.

Tickets should be created, enriched, routed, investigated, acted on, monitored, resolved, reopened, and learned from by a mixture of AI components and humans. The system should support autonomous work where appropriate while preserving explicit state and ownership.

Sierra’s move into long-running Horizon agents recognizes that work can extend over days or weeks. But placing long-horizon planning inside the agent still centers the agent as the holder of the plan. A stronger architecture puts the plan, state transitions, commitments, and deadlines in the support system, where agents and humans can inspect and modify them.

Memory answers, “What happened before?”

A ticketing ledger answers, “What remains owed, by whom, under which policy, and by when?”

Those are not the same thing.

6. Self-improvement must improve owned artifacts

Sierra’s Ghostwriter and Explorer point toward an important future: agents that help build and improve other agents.

According to Sierra, Ghostwriter can analyze interactions, identify opportunities, validate changes, and prepare them for review. This is a responsible improvement over silent production mutation. The company clearly recognizes the need for testing and approval.

The remaining question is: what is being improved?

If the output is primarily a better Sierra agent—new prompt behavior, platform-specific configuration, learned context selection, or proprietary decisioning—then the customer becomes more dependent on the agent platform with every improvement cycle.

The alternative is to make self-improvement operate on company-owned artifacts:

• a Markdown policy receives a proposed clarification;

• a rulebook gains an explicit exception;

• an evaluation dataset gains the failure as a regression case;

• an action contract adds a required approval;

• a ticket workflow receives a new state transition;

• a source conflict is routed to the accountable knowledge owner;

• a retrieval map is updated with an inspectable relationship.

The AI can propose the patch. Tests can evaluate it. A human can approve it. Any compatible system can consume the resulting artifact.

This is the difference between an agent that improves itself and an organization that improves its operating system with the help of agents.

The second creates durable company capability. The first creates a better dependency.

7. Outcome-based pricing creates an additional governance problem

Outcome-based pricing sounds perfectly aligned: the vendor gets paid when the customer receives value.

But it also makes the vendor’s measurement model part of the product’s economics.

For each billable outcome, someone must define:

• what event counts;

• which exclusions apply;

• how long the attribution window lasts;

• whether repeated contact reverses the outcome;

• how negative customer feedback is handled;

• whether the agent caused the result or merely participated;

• how partial completion is treated;

• how policy-compliant refusal is valued.

These are not billing details. They influence how the system is evaluated and optimized.

If the agent platform, improvement system, analytics layer, and commercial model all center the same outcome definition, organizations need unusually strong independent measurement. Otherwise, the vendor can become the builder, operator, evaluator, and beneficiary of the metric simultaneously—even without any intentional manipulation.

Outcome pricing can work when the outcome is narrow, independently verifiable, and aligned with customer welfare. It becomes more difficult as agents take ambiguous, multi-step, or revenue-influencing actions.

The safer principle is that the customer should own outcome definitions, raw event data, evaluation logic, reversal rules, and independent auditability. Commercial alignment is useful. Measurement sovereignty is more important.

The alternative: an agentic customer-support operating system

The right alternative is not to build every model, telephony stack, and orchestration primitive internally. Sierra is correct that the infrastructure iceberg is large.

The alternative is to place the durable control surfaces outside any single agent.

An agentic customer-support system should contain at least six layers.

1. A canonical knowledge layer

Policies, procedures, product facts, definitions, exceptions, sources, ownership, applicability, and version history should live in an inspectable representation. Search indexes, embeddings, and prompt context should be derived from it.

This is the idea behind Knowledge Atlas at Fini: transform fragmented knowledge into a structured layer that can identify gaps, conflicts, stale sources, applicable policies, and improvement opportunities.

2. An explicit decision layer

High-impact decisions should be represented through versioned rulebooks and policy nodes, not only prompts and guardrails. The system should distinguish deterministic requirements from areas where probabilistic judgment is permitted.

3. A constrained action layer

Every action should have a typed contract: required inputs, permissions, limits, approvals, idempotency behavior, expected outputs, error handling, and rollback strategy. The model may request an action; the tool boundary decides whether it can execute.

4. A durable ticket and event ledger

Every unresolved obligation should have explicit state, ownership, deadlines, dependencies, and an audit trail. Agents and humans should operate on the same durable work record.

5. Modular autonomous components

The system should support specialized agents for knowledge, triage, investigation, action, quality, internal Slack workflows, developer-facing CLI use, and channel-specific delivery. They can share context without sharing every permission or failure mode.

6. Independent evaluation and governance

The company should own evaluation cases, outcome definitions, negative signals, audit records, release gates, and rollback. Agent behavior should be tested against customer benefit and policy compliance—not only automation or conversion.

This architecture is less elegant in a product demo than one agent that handles everything.

It is more resilient in production.

Where Sierra’s approach can still work

Calling the abstraction wrong does not mean every Sierra deployment is a bad decision.

Sierra can be a strong choice when:

• the use cases are narrow and well understood;

• the actions have low or bounded downside;

• the outcome is independently measurable;

• the customer is comfortable standardizing on one agent platform;

• speed to launch matters more than architectural portability;

• the organization has enough internal governance to monitor the system independently;

• Sierra’s partnership model fills an immediate capability gap.

Its customer results show that this model can deliver meaningful value. Sierra reports, among other examples, 61% containment across more than 50,000 weekly SoFi conversations and a 33-point improvement in chat-contained NPS, as well as deployments at large organizations such as Singtel.

Those results should be taken seriously.

But strong results from current deployments do not settle the architectural question.

The question is what companies will need when AI handles not 20% of customer work, but most of it; when agents operate across support, success, sales, risk, and internal operations; and when policy changes continuously alter what those agents may do.

At that scale, the company cannot outsource the center of operational control to one agent, however capable.

The agent should be replaceable

The best test of an agentic architecture is simple:

Could you replace the agent without losing the organization’s accumulated knowledge, policies, workflows, evaluations, and learning?

If the answer is no, the company does not own its customer-support intelligence. It owns source documents and exports around a rented operating system.

Models will improve. Agent frameworks will change. Voice providers, retrieval methods, and orchestration strategies will be replaced. The durable assets are the company’s knowledge, customer relationships, action permissions, work history, policy decisions, and evidence about what serves customers well.

Those assets should remain portable and inspectable.

Sierra’s vision is one increasingly capable agent that builds, operates, and improves customer experiences as a service.

Our view is different.

The future is a governed customer-support operating system in which many replaceable agents and humans work over company-owned knowledge, explicit policies, constrained actions, and durable ticket state.

The agent is important.

It should never become the institution.

References

• Sierra: Product overview

• Sierra: Agent SDK

• Sierra: Agents as a Service

• Sierra: Introducing Agent Data Platform

• Sierra: Context Engine

• Sierra: Horizon

• Sierra: Pendulum customer story

• Sierra: SoFi customer story

• NIST: AI Risk Management Framework

• Amodei et al.: Concrete Problems in AI Safety

• Google DeepMind: Specification gaming

See the tactical comparisons

This piece is about architecture, not a feature-by-feature scorecard. For the pricing, compliance, and capability comparisons, see Sierra vs Fini and Decagon vs Fini.

Frequently Asked Questions

What is Sierra's Agent OS?

Sierra brands its product Agent OS, positioning it as durable infrastructure a company builds its customer experience on. Its Agent SDK lets teams define goals and guardrails, combine reusable skills, run simulations, and deploy one agent across chat, phone, email, SMS, and messaging. In 2026 Sierra extended this into “Agents as a Service,” where Ghostwriter builds agents from source material and Explorer analyzes conversations for improvement opportunities.

Is outcome-based pricing risky for customer support AI?

Outcome-based pricing aligns a vendor with a measurable result, but an outcome like “case resolution” is not a complete specification of good support. Definitions of what counts as resolved, and who is accountable for that definition, become part of the vendor's product surface. Research on AI safety describes the related risk of reward hacking: a system can optimize the stated objective in ways that violate the intended goal.

How does Fini's Knowledge Atlas differ from Sierra's Context Engine?

Sierra's Context Engine learns which customer signals matter for particular decisions, unifying structured and unstructured customer data. That answers what a company knows about a customer. Fini's Knowledge Atlas is built to answer a different question: what does the company believe, which source is authoritative, who owns it, and when may it be used. Both are useful; they are not substitutes for each other.

Should one AI agent handle every customer support channel?

Sierra emphasizes one agent deployed everywhere, which is easy to understand but risks treating very different channels as interchangeable. Voice requires low latency and strict protection against misheard high-impact actions. Email is asynchronous and tied to ticket state. Shared knowledge and identity make sense across channels; shared permissions, autonomy levels, and failure modes do not always transfer safely.

What is the test for whether a customer-support architecture is safe long-term?

Could you replace the agent without losing the organization's accumulated knowledge, policies, workflows, evaluations, and learning? If the answer is no, the company owns source documents and exports around a rented operating system, not its own customer-support intelligence.

Want to see a governed knowledge and action layer in production, not just described in an essay? Talk to Fini about a live pilot on your own tickets.