# Creating semi-deterministic AI Process Frends supports embedding AI reasoning directly into your integration Processes using the Intelligent AI Connector shape. Unlike a fully autonomous AI agent that can freely decide its own next steps, a semi-deterministic approach keeps the overall Process structure fixed and predictable — the BPMN flow, the number of steps, and the branching conditions are all defined by you. The AI's role is limited to reasoning within each step, producing structured output that the rest of the Process acts upon. This gives you the benefits of natural language reasoning without sacrificing auditability, consistency, or control. This guide walks you through designing a Process that receives an incoming support ticket, uses an AI step to categorize it, and then routes it to the correct downstream system or team based on that categorization. ## Step by Step Tutorial Available If you prefer more visual or interactive guidance on how to create semi-deterministic Processes in Frends, you can find a step-by-step walkthrough from your own environment's home page, under Onboarding by selecting **tutorial path 6: Including AI in my Processes**. ## Prerequisites Before following this guide, make sure you have access to a Frends Tenant with the AI Toolbox enabled and a configured AI service connection (either Frends AI, Azure AI Inference, or an Ollama instance). You should also be comfortable with the basics of the Frends Process editor, including adding shapes and connecting them with Sequence flows. Some familiarity with C# expressions is useful for writing gateway conditions. ## Designing the Process Flow The overall structure of this Process is intentionally simple: a Trigger receives the ticket data, an AI step categorizes it, and an Inclusive Decision shape routes the execution to the right path. Keeping the flow deterministic everywhere except inside the AI step is what makes this pattern reliable and easy to reason about.

### Adding the Trigger Start by opening the Process editor and adding a Trigger. For a support ticket use case, an HTTP Trigger or an API Trigger works well if tickets are pushed from an external system, while a Queue Trigger suits scenarios where tickets are consumed from a message bus. Configure the Trigger to receive at minimum the ticket subject and description — these are the inputs your AI step will need. How you reference the incoming ticket data depends on the Trigger type. For an HTTP Trigger, the body is available via `#trigger.data.httpBody` and individual JSON properties can be accessed from there. For a Queue Trigger, the message payload is available via `#trigger.data.message.Body`. Regardless of the Trigger type, the key is that the subject and description text must be extractable into a form you can embed in the AI prompt. ### Adding the Intelligent AI Connector Add an Intelligent AI Connector shape to the canvas and connect it to the Trigger with a Sequence flow. This shape is the core of the semi-deterministic pattern — it is where natural language reasoning happens, and it returns a structured result that the rest of the Process can act on deterministically.

#### Configuring the System Prompt The System Prompt defines the AI's role and the rules it must follow consistently across every execution. Keep it concise and specific. For ticket categorization, a good system prompt establishes the expected categories, the output format, and any rules for edge cases: ``` You are a support ticket classification assistant. Your task is to analyze the subject and description of an incoming support ticket and assign it to exactly one of the following categories: Technical Issue, Billing Inquiry, Feature Request, or General Question. Always respond with a valid JSON object in the following format: { "category": "", "confidence": } Do not include any text outside of the JSON object. ``` #### Configuring the User Prompt The User Prompt is where you inject the actual ticket data from the current Process execution. Use Handlebars syntax to reference the values you extracted from your Trigger. The exact reference paths depend on your Trigger type and payload shape — for example, if you stored the subject and description in Process Variables named `ticketSubject` and `ticketDescription` earlier in the flow, you would reference them like this: ``` Ticket subject: {{#var.ticketSubject}} Ticket description: {{#var.ticketDescription}} ``` If your Trigger delivers a structured JSON payload directly, you can reference the fields inline using the appropriate `#trigger.data` path for your Trigger type. #### Selecting the AI Service The Intelligent AI Connector shape has an **Service Type** dropdown that determines which AI model and endpoint is used for this step. The available options are the AI service connections configured on your Tenant. You can use the default Frends AI service for most cases, or select a specific Azure AI Inference or Ollama connection if your organization requires a particular model or data residency. Each shape in a Process can point to a different service, so you can mix and match within the same flow if needed.

### Using the AI Output The Intelligent AI Connector returns its result via `#result[Categorize Ticket].Response`, where `Categorize Ticket` is the Display Name you gave the shape. The response is already available as a `JObject`, so you can reference individual fields directly in your decision conditions and downstream steps without any additional parsing or Expression shapes. For ease of use, you can assign the `Response` object into a variable like `#var.ticketClassification`. ## Implementing the Branching Logic With the classification result from the AI shape, you can now add an Inclusive Decision shape to route the Process. ### Routing by Category Add an Inclusive Decision shape after the AI shape. Unlike an Exclusive Decision which follows only one path, an Inclusive Decision evaluates all outgoing conditions and follows every path whose condition evaluates to true. This makes it a natural fit for ticket routing, where a ticket might simultaneously need to be logged in a service desk *and* forwarded to a billing team. Create one outgoing Sequence flow per category, each with its own condition expression. For example: ``` #var.ticketClassification.category == "Technical Issue" ``` ``` #var.ticketClassification.category == "Billing Inquiry" ``` Continue this pattern for `"Feature Request"` and `"General Question"`.

Inclusive Decision branches the execution into multiple branches.

Create also one outgoing flow as the none matched branch — this path should be taken when none of the other conditions match, acting as a catch-all for any unexpected output from the AI step. ``` // Condition where no category matches #var.ticketClassification.category != "Billing Inquiry" && #var.ticketClassification.category != "Technical Issue" && #var.ticketClassification.category != "Feature Request" && #var.ticketClassification.category != "General Question" ``` ### Adding a Low-Confidence Branch The `confidence` field in the AI output is what makes this pattern genuinely semi-deterministic. Rather than blindly trusting every categorization, you can add a second outgoing flow from the same Inclusive Decision that routes low-confidence results to a human review queue in parallel with the normal routing: ``` (double)#var.ticketClassification.confidence < 0.7 ``` Because the Inclusive Decision follows all true paths simultaneously, a low-confidence `"Technical Issue"` ticket can both open a service desk ticket *and* notify a support lead for review — without needing a separate decision shape. High-confidence results satisfy only the relevant category condition, so they follow exactly one path. ## Branch Actions and Process Ending Each branch of the Inclusive Decision should contain the Tasks required to act on the categorization before connecting back to the main flow, and in this case into the same Return shape for successful handling. Alternatively, a branch can end in Throw shape in case of error, to signal support that this Process Instance had an error in the handling. ### Technical Issue Branch Add a Task that creates a ticket in your service desk. Pass the ticket subject, description, and any relevant metadata as inputs. Once the Task completes, connect the branch to a Return shape to signal successful handling. ### Billing Inquiry Branch Add a Task that forwards the ticket to your billing system or creates a case in a CRM. End the branch to the same Return shape as before, once the case is created. ### Feature Request Branch Add a Task that creates an entry in your product backlog or project management tool, such as posting to a Jira project or a dedicated Slack channel. ### General Question Branch Add a Task that routes the ticket to a general support queue or sends an acknowledgement email to the submitter using the SMTP or SendGrid Tasks. ### Low-Confidence Branch Add a Task that notifies a support lead — for example by sending a message via Slack or Teams with the ticket details and the AI's category and confidence values attached. This branch runs in parallel with the matched category branch, so the ticket is both acted on and flagged for review simultaneously. ### Default or 'Unknown' Branch The default branch handles any case where none of the category conditions matched, meaning the AI returned a value outside the expected set. Rather than silently succeeding, end this branch with a Throw shape to surface the failure explicitly. Configure the Throw shape to include a descriptive error message — for example, noting that the AI returned an unrecognized category — and the raw response value for diagnostics. This ensures that unexpected AI output is immediately visible in Frends monitoring rather than being swallowed by a generic Return. ## Monitoring and Auditability Every execution of the Intelligent AI Connector is logged in Frends, including the prompt sent and the raw response received. You can promote the `category` and `confidence` values to the Process Instance list by enabling **Promote result as** on the relevant shape, making it easy to filter and review categorization decisions in the Frends monitoring views without opening each instance individually. ## What's next? While this example used only a single AI Connector with an Inclusive Decision, AI Connectors can be chained together as many times as necessary. For example, for the Technical Support branch in this example, you can also use another AI Connector for detecting tone of the ticket, to determine urgency for the case. Higher urgency ticket can then have additional notification for the support lead that it should be prioritized higher than usually.

Further AI processing for a technical issue.

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.frends.com/guides/ai-features/creating-semi-deterministic-ai-process.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.