Deterministic-Lingual Programming (DLP): A New Paradigm Inspired by Human Decision-Making

Introduction

AI-driven software development is rapidly advancing, with innovations that leverage LLMs to create smarter applications. One significant breakthrough is Retrieval-Augmented Generation (RAG), which combines LLMs with retrieval systems to generate context-aware responses using existing enterprise data1. This enables applications to provide highly specific outputs tailored to the data they access, making RAG a powerful tool for knowledge-intensive tasks.

However, RAG has its limitations. It operates in a read-only mode, focusing solely on retrieving information and generating responses. This means it cannot directly perform actions like invoking APIs or updating databases, which limits its usefulness in scenarios that require automation and real-time interaction with backend systems.

Furthermore, RAG does not fully address the unpredictability and inconsistency issues associated with LLMs. Since LLMs are probabilistic, they can generate varying outputs even when given the same input, which can be problematic in scenarios where consistent behavior is critical, such as customer support or compliance2.

This is where Deterministic-Lingual Programming (DLP) comes in. Unlike RAG, DLP is action oriented. It blends the flexibility of LLMs with the predictability of deterministic programming, allowing systems to not only respond to user queries but also perform actions like processing refunds, assigning tickets, or updating records. DLP is inspired by how humans balance quick, intuitive responses with structured, rule-based processes.

In this blog, we'll explore how DLP works, using a Customer Support Ticket Management System as a running example. Figure below summarizes how different approaches work to handle this case.

The Concept Behind DLP

Humans naturally switch between intuition and structured processes. For tasks requiring quick responses—like answering customer inquiries—we rely on perception and memory. But for tasks that demand consistency—such as financial management—we use structured tools like spreadsheets3. DLP mirrors this approach by dividing software requirements into two categories:

1. Lingual Processing: Handled by LLMs for tasks that require adaptability, such as sentiment analysis or generating personalized responses.
2. Deterministic Processing: Managed by structured code for tasks that need precision, like ticket tracking and enforcing business rules.

How DLP Works: A Two-Phase Approach

Deterministic-Lingual Programming (DLP) is structured around two primary phases: Analysis and Synthesis and Execution.

Phase 1: Analysis and Synthesis

The first phase begins with analyzing the natural language requirements (NLRE) provided by users. An LLM is employed to understand these requirements, distinguishing between tasks that benefit from context sensitivity and adaptability (lingual tasks) versus those that demand precise, rule-based processing (programmatic tasks). For instance, analyzing customer sentiment would be handled as a lingual task, while updating the status of a support ticket falls under the programmatic category.

After categorizing tasks, the system defines the necessary interfaces to ensure smooth communication between the lingual and programmatic components. This involves generating APIs that enable different parts of the system to interact seamlessly, with clear input-output formats to maintain consistency.

Once the interfaces are specified, the system synthesizes the code needed to implement the backend services. This includes creating database models, CRUD operations for managing tickets and user profiles, and setting up schemas to store customer data. The goal is to generate reliable code that handles structured operations efficiently while allowing flexibility in context-driven interactions.

Phase 2: Execution

The second phase focuses on executing the defined tasks. For tasks requiring contextual understanding, such as sentiment analysis or crafting personalized responses, the Lingual Execution Agent uses the LLM. This component can analyze customer messages, suggest context-aware actions for support agents, or generate customized follow-up emails to enhance customer satisfaction.

The Orchestration Agent plays a crucial role in managing the flow between lingual and programmatic components. It starts by executing the lingual tasks to gather insights, such as detecting sentiment from customer tickets. These insights are then passed to programmatic components to trigger structured actions like assigning tickets to the right agents or updating records in the database.

While the current implementation of DLP operates based on predefined decisions about which tasks are lingual or programmatic, continuous monitoring allows the system to improve over time. Future iterations, referred to as Adaptive DLP (ADLP), will dynamically adjust task allocation based on real-time feedback and evolving usage patterns, ensuring even better performance and efficiency.

Applying DLP to a Customer Support Ticket Management System

To demonstrate the practical benefits of DLP, let’s explore a real-world scenario involving a Customer Support Ticket Management System. This example will highlight how DLP's unique combination of flexibility and predictability can optimize customer support processes.

Scenario Overview

Imagine a customer support team that manages incoming tickets from users experiencing issues with a product or service. The team’s goals are to:

1. Allow users to state problems they are facing and take appropriate action to resolve them.
2. Efficiently create, prioritize and assign tickets.
3. Leverage a knowledge base to suggest solutions, reducing response times.

The challenge is to balance the need for context-aware responses (e.g., understanding customer sentiment) with the need for structured, reliable operations (e.g., assigning tickets, managing workflows).

DLP Implementation: How It Works

Let's break down how DLP applies its two-phase approach to optimize a Customer Support Ticket Management System. By splitting tasks between lingual processing and deterministic operations, DLP ensures a balance between context-aware flexibility and reliable, structured actions.

Phase 1: Analysis and Synthesis

This initial phase focuses on analyzing incoming requirements, identifying task categories, and generating the necessary components to handle those tasks efficiently.

1. Requirement Analysis and Decision-Making When a customer submits a ticket, the system uses an LLM to analyze the content and classify the nature of the issue. For example, if the ticket contains phrases like “I’m really frustrated and expect a refund,” the system detects negative sentiment. Based on this analysis, DLP determines whether the task is best handled using context-aware processing (lingual) or structured logic (programmatic). Urgent tickets are flagged and prioritized for quicker responses.
2. Interface Specification After analyzing the requirements, DLP generates APIs to facilitate seamless communication between lingual and programmatic components. For instance, the system creates endpoints like /assign-ticket for structured ticket assignments and /issue-refund for making refunds if needed. This ensures that data flows smoothly between the LLM-driven components and deterministic code.
3. Code Synthesis The DLP system uses the synthesized requirements to automatically generate backend code. For the ticket management system, this includes setting up CRUD operations to create, update, and delete tickets, as well as database models for storing customer interactions and historical ticket data. Additionally, the system generates templates for common tasks, such as assigning tickets based on predefined business rules.

Phase 2: Execution

This phase focuses on running the system, ensuring that the right tasks are handled by either the lingual or programmatic components as needed.

1. Lingual Task Execution The Lingual Execution Agent handles tasks requiring flexibility and contextual understanding. For example, when a new ticket is submitted, the LLM analyzes its content to determine the sentiment and urgency. If the sentiment is negative, it prioritizes the ticket. Additionally, the LLM can search the knowledge base for similar past issues to suggest potential solutions to support agents, reducing resolution times.
2. Programmatic Task Execution For structured tasks, the system relies on deterministic code. This includes automatically assigning tickets to the most suitable support agents based on availability and skill level. For example, if issuing a refund makes sense based on analyzing communication history and order status, the /issue-refund is called to take the appropriate action.
3. Orchestration and Workflow Management The Orchestration Agent ensures that lingual and programmatic components work together seamlessly. After the LLM analyzes a ticket’s sentiment, the insights are passed to the programmatic side to trigger specific actions, such as assigning the ticket to an agent or scheduling follow-up emails. The orchestration layer ensures a smooth flow of tasks, with the flexibility to handle multi-step processes where outputs from one task inform the next.
4. Automated Follow-Up and Continuous Monitoring Once a ticket is resolved, the LLM generates personalized follow-up emails tailored to the customer’s experience. The programmatic component schedules and sends these emails based on predefined templates. The system also continuously monitors performance, gathering data to optimize task allocation over time.

Note that while the current implementation uses upfront task definitions, future iterations of DLP (Adaptive DLP) will dynamically adjust based on real-time feedback and user behavior.

Comparison of Different Approaches

Now that we’ve explored how DLP works, let’s compare how different paradigms handle the same customer support scenario:

The table illustrates how different approaches address key aspects of a Customer Support Ticket Management System, each adding incremental value but with varying limitations.

• Just a Program offers the highest specificity and predictability, but it severely lacks flexibility. It relies on rigid, hard-coded rules, which means it can efficiently handle routine tasks but cannot adapt to changing contexts or customer needs. This approach is limited to structured actions, making it suitable only for well-defined processes but not for dynamic scenarios where context matters.
• Just LLM brings high flexibility and empathy-driven responses by analyzing customer sentiment. However, it lacks the ability to perform structured actions like assigning tickets or issuing refunds. Its responses are also less predictable since it relies on probabilistic language models, making it difficult to consistently meet specific business rules.
• RAG improves on the LLM approach by leveraging external data sources to provide more accurate and contextually relevant responses. It excels at retrieving the latest information to inform its outputs, making it highly specific and context aware. However, it still suffers from unpredictability due to the probabilistic nature of LLMs and remains limited to read-only interactions, with no capability to take direct actions or update backend systems.
• DLP emerges as the ultimate solution, combining the best of both worlds: the flexibility and contextual understanding of LLMs with the consistency and reliability of deterministic programming. DLP not only analyzes sentiment and determines claim credibility but also automates concrete actions, such as processing refunds or updating records. By integrating context-aware, adaptive responses with rule-based automation, DLP achieves high flexibility, specificity, predictability, and actionability. This makes it ideal for complex, real-world scenarios where both nuanced understanding and precise execution are crucial.

In essence, while each approach offers value in certain areas, DLP stands out as the most comprehensive, providing a balanced solution that addresses the limitations of the others. It ensures that businesses can adapt to customer needs in real-time while maintaining the structured, reliable processes necessary for operational efficiency.

Conclusion

Deterministic-Lingual Programming (DLP) provides the best of both worlds: the flexibility of LLMs for understanding and context, combined with the reliability of deterministic code for structured operations. By leveraging both approaches, DLP ensures efficient, scalable customer support solutions that adapt to user needs while maintaining consistency and predictability.

Note: I am currently implementing the example scenario under different approaches and will soon publish a website that allow you to try them out to experience the differences for yourself!

References

1. Lewis, M., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv preprint arXiv:2005.11401 (2020). ↩
2. Bommasani, R., et al. "On the Opportunities and Risks of Foundation Models." arXiv preprint arXiv:2108.07258 (2021). ↩
3. Kahneman, D., "Thinking, Fast and Slow." Farrar, Straus and Giroux, 2011. ↩
4. Gulwani, S., et al. "Program synthesis." Foundations and Trends in Programming Languages 4.1-2 (2017). ↩