Decagon gives customer-service teams a system for building and improving AI agents

Decagon builds AI agents for customer service, with a platform for defining their behaviour, connecting business systems and improving performance after launch. The distinctive part of its offer is the development process around the agent: customer-experience teams work with Agent Operating Procedures, while technical teams retain responsibility for integrations and guardrails. A buyer should therefore evaluate both the customer conversation and the internal process used to change it. Those are separate experiences, and both need to work.

01 / ProductWhat are Decagon’s Agent Operating Procedures?

The product overview¹ presents Agent Operating Procedures, or AOPs, as the way teams express agent logic in natural language. Decagon pairs them with integrations, testing, versioning and observability. This is a broader proposition than a chatbot trained on help articles. A knowledge article can explain how a subscription works; an AOP describes the sequence for handling a customer who wants to change it, including which account data or tool calls are required.

Decagon’s AOP explainer² describes translating standard operating procedures into executable agent workflows. The useful concept is shared ownership of intent and implementation. A service manager should recognise the business process in the procedure, while an engineer can inspect the operations that touch external systems. Natural language makes a rule easier to express, but the underlying rule still needs to be precise enough to distinguish eligible and ineligible requests.

An AOP is consequently best understood as maintained product logic. It has dependencies on policy, data and customer behaviour. When a business changes its return terms, that can affect source material, procedure branching, confirmation wording and the expected results of tests. Treating the change as a coordinated release is more likely to preserve a coherent customer experience than editing a prompt in isolation.

02 / AudienceWhich organisations should consider Decagon?

Decagon is most relevant to customer-service operations with enough process complexity to benefit from a dedicated agent-building workflow. Examples include account management across several products, subscription changes with eligibility rules or travel support that depends on live booking information. These environments need people who understand the service policy and people who can expose the necessary system operations. The platform’s promise is to help those groups collaborate, not to make business-system ownership disappear.

If your requirement is a compact public-answer widget, our Chatbase profile is a useful adjacent starting point. If the priority is choosing a human support inbox together with the AI, our Intercom guide examines that integrated route. Decagon’s procedural development model is a particularly relevant comparison when an organisation expects to keep its existing support estate and make the agent a substantial product within it.

A practical readiness question is whether the team has representative cases and clear success criteria. Without those, a sophisticated simulation interface can still produce a reassuring result for an unrealistic task. The implementation should begin with a process that already has an accountable owner, an authoritative system of record and a useful set of resolved and unresolved examples.

03 / WorkflowA proposed subscription-change implementation

Imagine a customer who wants to move from an annual subscription to a different product tier. The agent needs to identify the account, retrieve current terms, explain available choices and distinguish a permitted change from an exception requiring approval. This is an illustrative evaluation scenario. We did not run it in a private Decagon workspace, and it should be adapted to the actual subscription system and policy before implementation.

Start by writing the intended AOP with the service owner. It should explain which request triggers the process, what the agent must learn and which outcomes are allowed. Separate a quote from a committed change. The customer should be able to ask about a different tier without the system assuming consent to modify billing. The corresponding API operations should make that distinction explicit: retrieve options, prepare a proposed change and apply a confirmed change.

The engineering team should make the system of record authoritative for eligibility and transaction state. If a subscription update succeeds but its response is lost, a retry must not create a second change. The agent’s conversation history alone cannot settle whether an external transaction happened. This is a property to verify at the integration boundary, using a durable request reference and a way to inspect the final account state.

What should simulations cover?

Decagon’s Simulations explanation³ describes generated mock conversations evaluated against defined success criteria, including procedure selection, knowledge and guardrails. For the subscription example, useful cases would vary the intent rather than merely the wording: a pricing enquiry, an immediate change request, an ineligible account and a customer who withdraws consent. Add unexpected tool responses and an unavailable billing service. Each case needs a business-defined expected outcome.

Simulation results become more useful when failed cases can be traced to the responsible part of the system. A wrong tier recommendation may come from outdated knowledge. An unauthorised change may come from an overly permissive endpoint. A repeated clarification may come from an ambiguous procedure. Fixing the right layer avoids rewriting the conversational instructions to compensate for a defect elsewhere.

How does Duet change the maintenance work?

The current Duet product page⁴ describes an assistant that analyses conversations, proposes AOP improvements and generates tests. Its Autopilot workflow stages updates for human review with a health report. The important distinction is between producing a candidate improvement and deciding to adopt it. A procedure that passes a generated test may still express the wrong commercial policy, so the reviewer needs to understand the intended behaviour as well as the reported result.

A useful operating rhythm would be to turn recurring production failures into a small, reviewed change, run the relevant tests and then observe a limited release. Keep the original case linked to the change. That gives the team a practical answer to “why does this rule exist?” and makes it easier to reverse a well-intentioned edit that affects a different customer journey.

04 / PricingWhat is publicly known about Decagon pricing?

The public product page¹ directs buyers towards a demo. The materials reviewed on 15 September 2026 did not provide a complete numerical list price suitable for an independently reproducible cost comparison. It would be misleading to attach a generic enterprise price range to the product. Instead, bring a defined deployment to the commercial discussion and request the charging model in writing.

The most important commercial distinction is the denominator. Ask whether the proposed agreement counts conversations, completed outcomes, channel activity or a combination, and how it treats escalations, repeated contacts and failed external operations. Also clarify the implementation scope and which team maintains integrations. These are questions for the proposed contract, not assertions that Decagon charges separately for every activity listed.

For an internal business case, value the specific work removed or improved. A subscription agent might reduce lookup and explanation work while leaving approvals with a specialist. That can be a valid benefit without claiming complete automation. Compare the cost of the proposed service with the remaining human workload, ongoing procedure maintenance and the consequences of incorrect account changes. A headline deflection target does not capture all of those effects.

05 / DistinctionsExperiments make changes assessable

Decagon’s experimentation announcement⁵ describes comparing changes to logic, tone, knowledge and tools against a control group, with gradual traffic rollout. This is useful when a proposed improvement involves a tradeoff. For example, a shorter cancellation explanation may reduce reading effort but leave customers less clear about the effective date. A controlled comparison can examine both behaviour and customer understanding rather than relying on a preferred writing style.

The buyer’s contribution is deciding what success means before seeing the result. For the subscription example, the primary question might be whether the intended account change completes correctly; secondary questions might concern recontact and human effort. An experiment should not reward an agent for keeping a conversation away from a teammate when the correct outcome is specialist help. The platform supplies measurement machinery; the service owner supplies the objective.

06 / QuestionsSecurity and quality questions with concrete boundaries

Decagon’s security page⁶ describes role-based access, short-lived scoped API tokens, provider retention controls and its Watchtower quality monitoring. These are vendor-described controls. For an actual deployment, examine how they apply to the account operation you intend to expose. Staff administration, end-user identity and a tool’s authority are separate boundaries, even when they appear in the same overall security review.

Ask to inspect a representative trace from conversation to tool result and final response. It should be possible to identify which procedure ran, what data informed the decision and what happened in the external system. We have not independently measured Decagon’s answer quality or operational outcomes. The strongest evidence for your decision will be a narrow implementation whose difficult cases are visible, explainable and correctable by the people who will operate it.

07 / DecisionChoose Decagon for an agent you plan to develop continuously

Decagon’s proposition is most coherent when the agent has a continuing product owner, not merely a launch deadline. Evaluate whether your service team can understand and improve its procedures, whether engineering can control the integrations and whether changes can be tested meaningfully. A successful first project should leave you with a maintainable customer journey and an evidence trail for improving it.