How Azeon Achieves a 90% Resolution Rate for L1 Tickets?

Improving L1 ticket resolution is often treated as a language model problem.

In practice, most failed resolutions have little to do with response generation. They occur because the system operates with incomplete customer context, inconsistent enterprise data, ambiguous requests, or workflows that cannot safely execute the required actions.

During the early iterations of Azeon, we observed the same pattern.

Replacing one model with another produced marginal improvements in response quality, but it rarely changed whether a customer’s issue was actually resolved. The bottlenecks existed elsewhere in the pipeline.

That observation changed how we approached the architecture.

Instead of optimizing prompts or continuously upgrading foundation models, we focused on the systems surrounding them.

This article walks through the engineering decisions behind that architecture. Rather than focusing on model selection, it explains how we redesigned the resolution pipeline to consistently deliver verified outcomes at enterprise scale.

We Never Reason Over Raw Customer Messages

Customer conversations were never designed to become machine-readable inputs. The same issue can arrive through email, live chat, voice transcripts, Slack, APIs, or messaging platforms, each carrying different structure, metadata, and levels of ambiguity.

Asking every downstream service to interpret those variations independently quickly leads to inconsistent reasoning and duplicated preprocessing across the platform.

Our earliest prototypes passed customer messages directly to the reasoning engine. While this worked for straightforward requests, performance degraded as conversations became more complex.

Customers combined multiple issues into a single message, referenced previous interactions, attached screenshots without explanation, or relied on context that existed only in enterprise systems. The reasoning engine spent a significant portion of its inference budget interpreting conversations instead of deciding how to resolve them.

We moved that responsibility into a dedicated normalization layer.

As shown below, every request follows the same preprocessing pipeline before it reaches the reasoning engine.

Regardless of the communication channel, the pipeline extracts entities, identifies products, segments multiple intents, parses attachments, enriches metadata, and links related customer sessions.

The output is a canonical request object shared across the entire platform.

From this point forward, no service consumes raw customer conversations.

Retrieval, planning, workflow orchestration, and telemetry all operate on the same structured representation, eliminating channel-specific processing throughout the pipeline.

The reasoning engine no longer determines what the customer meant – it receives a normalized request and focuses exclusively on selecting the most appropriate path to resolution.

Standardizing requests at the boundary also simplified the rest of the architecture.

Improvements to entity extraction, intent detection, or metadata enrichment automatically benefited every downstream subsystem without requiring changes to prompts, planning logic, or execution workflows.

Instead of solving the same interpretation problem repeatedly, the platform solves it once and carries a consistent request representation through the remainder of the resolution pipeline. 

Context Assembly Became More Important Than Model Size

Customer requests rarely contain enough information to determine the correct resolution.

Account details live in the CRM, billing status in payment systems, product state in internal services, previous interactions in the ticketing platform, and operational procedures in the knowledge base.

Treating the customer message as the primary source of truth forced the reasoning engine to make decisions with only a partial view of the customer’s state.

Our initial approach was straightforward: retrieve everything that might be relevant and forward it to the planner.

Recall improved, but planning quality did not. Duplicate records, outdated documentation, conflicting account data, and low-value search results increased inference time while making workflow selection less reliable.

The reasoning engine spent more time deciding which information to trust than determining how to resolve the request.

To address this, we introduced a dedicated context ranking layer between retrieval and reasoning.

Retrieval fan-outs execute concurrently across connected enterprise systems to assemble customer context within the latency budget of an interactive support session.

Instead of forwarding every retrieved artifact, the platform evaluates each result using multiple ranking signals – including semantic similarity, source reliability, freshness, and customer relevance – before constructing the final context package delivered to the planner.

The ranking layer establishes another architectural boundary within the resolution pipeline.

By the time the reasoning engine begins planning, duplicate records have been removed, conflicting information has been prioritized, and low-confidence artifacts have been filtered out.

Rather than searching for context during inference, the planner operates on a concise representation of the customer’s current enterprise state.

Moving context evaluation ahead of reasoning changed the role of the language model.

The planner no longer resolves conflicting enterprise records or determines which data source should be trusted.

Its responsibility begins only after enterprise context has been assembled, ranked, and validated, allowing inference to focus exclusively on selecting the most appropriate execution plan.

We Designed Reasoning to Produce Execution Plans, Not Responses

Our earliest implementations treated the language model as both the decision maker and the responder.

While conversational quality improved, workflow execution remained inconsistent because the model was responsible for deciding what to do and communicating it at the same time.

The two responsibilities evolved independently but were tightly coupled within the same inference step.

We separated them.

Instead of producing conversational responses, the reasoning engine produces a structured execution plan. Using the normalized request and ranked enterprise context, the planner identifies the customer’s intent, evaluates operational risk, estimates execution confidence, and determines the systems required to resolve the issue.

The output is not natural language – it is a machine-readable plan that defines the objective, required validations, execution sequence, dependent systems, and fallback strategy.

This architectural boundary separates decision-making from execution. Once an execution plan has been generated, the reasoning engine’s responsibility ends. The plan is handed to the orchestration layer, which independently validates business policies, coordinates enterprise workflows, manages retries, and records every operation required to complete the resolution.

By reducing the planner to a single responsibility – determining what should happen next – we removed execution logic from the reasoning layer entirely.

Planning can improve as reasoning models evolve, while workflow execution, enterprise integrations, and operational controls continue to evolve independently behind a stable execution interface.

Execution is Deterministic by Design

Customer support workflows frequently involve actions that cannot rely on probabilistic behavior.

Resetting a password, processing a refund, updating customer records, modifying subscriptions, creating service requests, or triggering downstream workflows all require predictable execution, auditability, and compliance with business policies.

Even when the reasoning engine identifies the correct action, execution itself must remain deterministic.

Rather than allowing the reasoning engine to interact directly with enterprise systems, every execution plan passes through a dedicated orchestration layer.

As illustrated below, this layer acts as a controlled execution boundary where business policies are enforced, retries are managed, and every operation is recorded before requests reach connected enterprise systems. The reasoning engine determines what should happen, while the orchestration layer ensures it happens consistently and safely.

By isolating execution behind this boundary, the platform shields the reasoning engine from operational complexity.

Transient API failures, retry logic, idempotency, long-running workflows, and audit requirements are all handled independently by the orchestration layer. This allows reasoning models to focus solely on decision-making while execution remains resilient under production workloads.

The separation also makes the platform easier to evolve.

Improvements to reasoning models can increase planning quality without affecting workflow reliability, while enterprise workflows, integrations, and business policies can evolve independently without modifying the reasoning layer.

Each subsystem has a clearly defined responsibility, making the overall architecture more reliable, observable, and maintainable.

Every Resolution is Verified Before It’s Counted

A completed workflow does not necessarily mean the customer’s issue has been resolved.

• A password reset can complete successfully even if the customer never signs in again.
• A refund request may be submitted but remain pending approval.

Measuring automation by completed workflows consistently overstated the platform’s effectiveness.

Our initial metrics reflected the same limitation. Workflow completion was easy to measure but provided little insight into whether the intended outcome had actually been achieved.

High completion rates often concealed failures that occurred after execution, making it difficult to identify where the resolution pipeline had broken down.

We introduced a dedicated Resolution Verification Layer to evaluate the outcome of every completed workflow.

Rather than relying on a single success signal, the verification engine aggregates multiple indicators – including enterprise system state, customer responses, repeat requests, workflow status, and business rules – to determine whether the original customer issue has actually been resolved.

This architectural boundary also became an important source of engineering feedback.

Every unverified resolution exposes a specific failure within the pipeline.

Some originate from incomplete enterprise context, others from incorrect execution plans, downstream integration failures, or business policy constraints.

Instead of treating these outcomes as isolated incidents, the platform records them as structured feedback that improves retrieval, planning, orchestration, and workflow design.