The modern enterprise runs on a complex web of applications, websites, and internal tools. When these systems fail, the burden falls on the "User Attendance Center" (UAC). Every day, UAC departments are inundated with a relentless stream of incidents, and their ability to keep the business moving relies entirely on their capacity to manage and answer these requests using their internal knowledge base.

For Data Scientists, this scenario is more than an operational bottleneck; it is a quintessential "golden use case" for Agentic AI. Traditional search-based Retrieval-Augmented Generation (RAG) models are not enough.

The next generation of AI solutions requires an orchestrated flow. By integrating business rules, sophisticated text analysis, and RAG-LLM models, we can assist UAC departments in finding the precise technical answer as fast as possible. This article explores how practitioners can use the newly introduced SAS Agentic AI Accelerator to engineer this transformation.

Agentic AI is changing the enterprise AI paradigm: rather than simply generating outputs, AI systems can now complete tasks and make decisions autonomously. The real challenge, however, is not autonomy, it is trust. In practice, organizations need agents that are secure, transparent, traceable, governable, and monitorable over time.

The SAS® Viya® Agentic AI Accelerator is a free framework designed to help SAS Viya users to build governed and trusted AI agents by integrating Large Language Models (LLMs) in the easiest and safest way possible, with governance and operationalization in mind. It enables you to:

• Integrate any LLM (proprietary or open, online or offline) with security, trust, and transparency, leveraging SAS Model Manager as the central model registry.
• Experiment, compare, version, govern, and monitor prompts to continuously improve accuracy and reliability—while packaging artifacts automatically for governance and deployment.
• Combine business rules, LLMs, and traditional ML models to balance accuracy vs. transparency and autonomy vs. human-in-the-loop oversight.
• Deploy and monitor agent performance over time, with traceable decision logic and explainability.
• Do all the above through a no-code interface, making agent creation accessible beyond purely technical roles.

This article walks you through a complete demo use case: a multi-agent workflow that processes support tickets.

This is not a theoretical application. The challenge faced by the UAC is a common struggle applicable across different companies. The need to deliver rapid, accurate, and compliant internal support is universal.

Solution Overview

The solution is based on 3 main layers:

1. Building blocks

AI models and agents form the foundation of the solution. These include text analytics models for categorization and entity extraction, built with SAS Visual Text Analytics, a RAG‑based model to propose responses for complex or unknown cases, and an LLM‑based validation agent to assess the relevance and quality of generated responses. Each component performs a well‑defined task and can be independently evolved, tested, and governed.

2. Orchestration and decision logic

All models, agents, and business rules are orchestrated within SAS Intelligent Decisioning, which defines the end‑to‑end process flow followed by each ticket. This orchestration layer ensures that decisions follow a controlled and auditable path, combining automation with human‑in‑the‑loop oversight where required.

3. Governance and Trust

SAS Model Manager provides centralized governance for all analytical assets involved in the solution, including traditional models, LLM references, and prompts. Versioning, approval workflows, and monitoring capabilities ensure that the full agentic process can be deployed, observed, and refined over time. In addition, SAS Intelligent Decisioning ensures that the complete decision logic is traceable and auditable, enabling trusted AI at scale.

This design enables a hybrid approach by design: deterministic and explainable analytics are used wherever possible, while generative AI is applied only where flexibility and reasoning add clear value. Supported by the SAS Agentic AI Accelerator, all components are governed and monitored to ensure trust, control, and operational transparency throughout the lifecycle of the agent.

Step-by-Step Construction

Let’s walk through the steps required to build the AI agent using SAS Viya and the SAS Agentic AI Accelerator. Each step illustrates how you can create your own AI agent, from building the core components to orchestrating and operationalizing a trusted workflow aligned with real UAC processes.

Step 1: Build ticket categorization and entity extraction models using SAS Visual Text Analytics and register them with SAS Model Manager.

The first step consists of building the deterministic foundation of the agent using SAS Visual Text Analytics. A text categorization model is trained on historical UAC tickets to classify incoming requests into known scenarios, while an entity extraction model is used to identify key information such as names, applications, references, or urgency indicators.

Once trained and validated, both models are registered and published in SAS Model Manager, making them governed, versioned assets that can be safely reused and orchestrated downstream. These models provide structured and explainable signals that later guide routing decisions and ensure that generative AI is applied only when required.

1. Open SAS Model Studio and create a new Text Analytics project. Use a data table containing historical UAC tickets, including the incident text and the corresponding ticket categories, to train a text classification model.
2. Select the input variables that contain the ticket text (for example, description or subject fields) and the target variable that represents the ticket classification.

3. Use the Concepts node to define the business concepts required by the use case. For example, you can include LITI rules to identify the types of applications and systems supported by the UAC, enabling consistent and explainable entity extraction.

4. Use the Categories node to build the text categorization model, either by:
   • leveraging historical labeled data, or
   • defining business rules that explicitly describe how categories should be assigned.

5. Once the models are properly adjusted and validated, select the Register Model option. This action stores the trained models in SAS Model Manager, where they can be versioned, governed, reused, and monitored as part of the agentic workflow.

Step 2: create a Retrieval-Augmented Generation (RAG) model using SAS RAM and register it in SAS Model Manager.

The next step extends the agent to handle complex or unknown cases by creating a Retrieval‑Augmented Generation (RAG) model using SAS RAM. The RAG approach combines an LLM with relevant knowledge sources, allowing the agent to generate responses grounded in trusted content and reducing the risk of hallucinations.

Once configured and validated, the RAG model is registered and published in SAS Model Manager, ensuring it is versioned, governed, and ready to be orchestrated as part of the agentic workflow.

1. Open SAS Retrieval Agent Manager (SAS RAM) and define the knowledge sources that will be used to ground the responses, such as internal documentation, manuals, FAQs, or other knowledge bases relevant to UAC operations.

2. Create a new collection where you can experiment with different embedding models and chunking strategies. Use this space to validate and compare retrieval quality and relevance across configurations.
3. Once the RAG configuration is validated, register the RAG model in SAS Model Manager, enabling versioning, governance, and reuse within downstream agentic workflows.

Step 3: experiment and register a prompt to define an LLM-based agent to assist with unknown cases.

In this step, an LLM‑based agent is defined to support cases that cannot be resolved through predefined responses or the RAG approach, providing additional assistance for open or ambiguous situations. Using the SAS Agentic AI Accelerator, different prompt variants are experimented with to guide the LLM’s behavior, tone, and constraints when generating response proposals.

Once the prompt is validated, it is automatically packaged and registered in SAS Model Manager, becoming a governed and versioned asset. This ensures the LLM‑based agent can be safely orchestrated within the workflow and refined over time without compromising transparency or control.

1. Open the Build Prompts menu in the SAS Agentic AI Accelerator. Select or create a SAS Model Manager project and create a new prompt.

2. Select the LLMs to test prompts with and start building and testing your prompts. Create multiple prompt variants to experiment with different formulations and guidance strategies and test each prompt variant against sample tickets and compare results to evaluate response quality, consistency, and safety.

3. Select the best‑performing prompt and finalize the configuration.
4. Manifest Best Prompt to register the prompt as a governed asset in SAS Model Manager, where it is automatically built, versioned and made available for orchestration.

Step 4: Model the ticket-handling process in SAS Intelligent Decisioning.

Now, the end‑to‑end ticket‑handling process is modeled in SAS Intelligent Decisioning to orchestrate all previously created components. The decision flow defines how tickets move through categorization, entity extraction, RAG assistance, and LLM‑based support, based on confidence levels and business rules.

This orchestration layer centralizes the process logic, ensures consistent routing, and enables controlled automation with human‑in‑the‑loop oversight where required. As a result, every action taken by the agent follows a traceable, auditable, and governed path aligned with real UAC operating procedures.

1. Open SAS Intelligent Decisioning and create a new decision flow.

2. Sequentially add the text analytics models (concepts and categories) from the SAS Model Manager repository to the decision flow.

3. Incorporate a branch node to control routing logic and escalation paths based on business criteria.



4. Add business rules to define the proposed response for known questions.



5. Add the RAG model to the corresponding paths in the decision flow to provide grounded response proposals for complex or unknown cases. Add the LLM‑based agent prompt followed by Call LLM node (part of the SAS Agentic AI Accelerator), and combine these components with the necessary decision nodes, business rules, and transitions to accurately represent your UAC ticket‑handling process, including routing, escalation. To organize an orchestrated agentic AI workflow, you can define specialized decision flows for different parts of the process.

6. Add missing variables to populate input and output variables, then save and validate the decision flow.

Step 5: Add an LLM-based validation agent to score responses.

In this step, an LLM‑based validation agent is added as a guardrail to assess the relevance of the proposed responses before they are acted upon. The validation agent evaluates each response against the original ticket context and returns a score, along with qualitative feedback highlighting potential gaps or risks.

This guardrail plays a key role in controlling the autonomy of the agent, ensuring that only high‑quality responses can progress, while uncertain or risky cases are prioritized for mandatory human review. As a result, the solution balances automation with oversight, optimizes the workload of support staff, and strengthens trust, accountability, and operational reliability.

Step 6: test the flow to ensure full transparency and traceability.

Once all components are connected, the complete decision flow is tested using representative ticket scenarios. This validation phase ensures that each step of the process behaves as expected and that routing decisions, agent outputs, and validation results are correctly logged.

Testing also allows practitioners to verify end‑to‑end traceability, including which models, prompts, rules, and agents were used for each ticket, ensuring that outcomes are explainable and auditable throughout the workflow.

Step 7: Package, govern, deploy, and monitor the agent.

In the final step, the agent is packaged and deployed as a governed asset. Using SAS Model Manager and SAS Intelligent Decisioning, all models, prompts, and decision logic are versioned, approved, and published to the appropriate runtime environments.

Once in production, the agent can be monitored over time, tracking performance, validation scores, and behavioral trends. This enables continuous improvement of the agent while maintaining control, governance, and trust as requirements evolve.

Conclusion

As Agentic AI becomes a core capability for enterprise operations, trust and governance are no longer optional, they are foundational This walkthrough shows how practitioners can design an end‑to‑end agentic AI workflow that is both powerful and controllable, and how a layered, hybrid approach enables organizations to move beyond isolated RAG models toward fully orchestrated agentic workflows.

By leveraging SAS Viya together with the SAS Agentic AI Accelerator, analytics‑driven understanding, generative reasoning, and human oversight coexist within a single, governed framework. The accelerator simplifies the creation, orchestration, and governance of AI agents, enabling LLMs, prompts, rules, and analytical models to be combined transparently and operationalized at scale.

Beyond the architectural benefits, this use case delivers tangible business value. The implementation enables:

• Higher productivity, by reducing manual ticket review and accelerating solution search, resulting in cost reductions of 8–15%.
• Improved effectiveness, cutting ticket resolution times by 30–40% through faster, more consistent responses and better guidance for support teams.
• Increased application and user satisfaction reflected an estimated 10% improvement in NPS, driven by fewer unnecessary iterations and clearer responses.
• Scalable best practices, with standardized and validated responses that reduce dependency on individual expertise and increase the number of resolved tickets by around 20%.

The result is an enterprise‑ready Agentic AI solution that can evolve over time, support critical operational teams such as UAC, and deliver automation with confidence—combining autonomy with transparency, and innovation with control.

To explore how this approach can be implemented in practice, learn more about SAS Agentic AI Accelerator and discover how to build, govern, and scale AI agents in enterprise environments.

Learn more

• Agentic AI for Workforce Analytics: Reducing attrition with personalized, LLM-powered guidance
• How Agentic AI Accelerates SME Credit Decisions with SAS Viya
• From fraud detection to fraud resolution: Building an AI voice agent with SAS Viya and LLMs
• Unlocking agentic AI potential with MCP tools in SAS Retrieval Agent Manager
• A New Frontier for AI Agents: Cybersecurity

The post Modernizing user attendance center ticket handling with trusted agentic AI appeared first on The SAS Data Science Blog.

Entity resolution has long been a foundational capability in analytics—connecting records, reducing duplication, and building a trusted, 360-degree view of people, organizations, and relationships. But in today’s data landscape, fragmentation is no longer an exception; it is the norm. Organizations routinely manage millions, sometimes billions, of records spread across disconnected systems, where duplicate and inconsistent identities introduce risk, inefficiency, and blind spots.

This has a significant impact. Gartner estimates that poor data quality costs organizations an average of at least $12.9 million per year. Yet despite this cost, many organizations struggle to improve. Data quality is not a one-time effort. It is continuous and operationally difficult to sustain. According to the 2024 State of Data Quality report by Transforming Data with Intelligence (TDWI), only 14% of organizations have automated data quality management processes. While more than half generate data quality metrics, just 17% formally and consistently report them. This limits their ability to manage duplication and identity fragmentation at scale.

What’s changed is not the importance of entity resolution, but the expectations placed on it. As data becomes more distributed and dynamic, organizations can no longer rely on batch processes, manual review, or isolated analytical workflows. They need identity resolution that is reliable in production, scales globally, and integrates directly with decision-making systems.

This shift is driving the evolution of SAS AI‑Driven Entity Resolution from a powerful analytical capability into a globally available, industry‑ready solution on SAS Viya.

A brief look at the SAS AI‑Driven Entity Resolution Model package

As shown in Figure 1, SAS AI‑Driven Entity Resolution is delivered as a ready‑made SAS model package. It is built as a modular pipeline that includes data cleansing, record linkage, community link validity, clustering, and cluster scoring. Organizations can deploy the full pipeline end‑to‑end or integrate individual components alongside existing data quality or entity resolution processes.

Most SAS AI‑Driven Entity Resolution components are globally applicable by design. This enables the deployment of entity resolution across regions and data sources. The data preparation component currently focuses on U.S. English standards for individuals and organizations, while the remaining linkage and scoring components are language, region, and entity-agnostic. This allows organizations to pair SAS AI‑Driven Entity Resolution with localized data preparation strategies as needed.

Lowering the barrier with no‑code configuration

To accelerate adoption, SAS AI‑Driven Entity Resolution is available through SAS Studio Custom Steps (Figure 2) and SAS Studio Flows (Figure 3). This provides a no-code approach to configuring and orchestrating entity resolution pipelines. This enables analysts and domain experts, not just developers, to design and deploy entity resolution pipelines with confidence.

By reducing operational complexity and standardizing configuration, custom steps help teams move more quickly from experimentation to production. This is an essential capability as entity resolution expands across industries and geographies.

Why entity resolution is evolving

Traditional, deterministic matching techniques remain effective when data is clean, identifiers are stable, and match criteria are straightforward. In practice, however, real‑world data is often incomplete, inconsistent, and constantly changing. So, rule-based approaches struggle to keep pace with evolving data. This has driven increased demand for methods that learn from data patterns rather than rely solely on fixed rules.

In the Summer 2026 release, SAS AI‑Driven Entity Resolution expands support for probabilistic record linkage. This will enable matches to be evaluated based on likelihood rather than exact agreement. Enhancements include frequency-based weighting for rare and common attributes (such as first and last names), helping to distinguish meaningful similarity from coincidence. Additional capabilities, including process tracking and lifecycle management, allow identities to evolve over time, preserving historical context while continuously refining matches as new data arrives.

Together, these improvements shift entity resolution from static, rebuild‑oriented processes to entity resolution to a living system aligned with long‑running operational use.

From cross-industry capability to industry solutions

While entity resolution is a common requirement across many domains, its application varies widely by industry. The greatest value comes not from record linkage alone, but from embedding entity resolution into industry‑specific workflows and applications.

A clear example of this approach is public-sector program integrity. In food assistance programs, for instance, accurately resolving individuals, households, and related entities is essential to reducing improper payments while protecting eligible families. This need became especially visible during the COVID-19 pandemic. States were required to identify children eligible for free or reduced-price school meals. The system then linked them to the Supplemental Nutrition Assistance Program (SNAP) and EBT systems across separate education and human services data sets.

With no direct identifier to link students across these disparate systems, SAS supported states by applying probabilistic entity resolution to match students. SAS leveraged the same algorithmic techniques that underlie SAS AI‑Driven Entity Resolution. In one such implementation, this approach delivered a 30% improvement in match rates over deterministic methods. This created faster benefit distribution and reduced duplicate or missed payments. This drove an estimated $500,000 in immediate cost avoidance while supporting a 48-hour response time.

The next step is clear: Integration with industry solutions. Work is already underway to incorporate SAS AI‑Driven Entity Resolution into the SAS Payment Integrity for Food Assistance model. This would help support fair, accurate decision-making across fragmented systems and complex eligibility scenarios. This marks a crucial step in moving beyond standalone analytics into end-to-end industry solutions.

A similar pattern applies in financial services, where entity resolution is foundational to fraud detection and anti-money laundering. Understanding networks and relationships is often as critical as matching individual records. In these environments, the Real-Time Entity and Network Generation serves as the backbone for identity management. This is particularly true when paired with SAS Visual Investigator, while SAS AI‑Driven Entity Resolution enhances match accuracy through probabilistic techniques. Ongoing efforts focus on bringing these capabilities together to improve match quality and reduce false positives without disrupting existing architectures.

From financial services and public-sector programs to healthcare and life sciences, this industry-focused approach results in a stronger, more resilient foundation. It scales with data complexity and operational demand while tuning for industry-specific challenges. SAS AI‑Driven Entity Resolution offers advanced, probabilistic matching and scoring to surface relationships in complex or ambiguous data. It integrates seamlessly with your existing entity resolution workflows, delivering value across industries. Therefore, the result is an entity resolution product that is both analytically robust and operationally dependable, supporting critical decisions across diverse business domains.

A foundational model package built to evolve

SAS AI‑Driven Entity Resolution is evolving from a standalone record‑linkage capability into a globally available, industry‑ready model package for entity resolution. No‑code configuration lowers the barrier to adoption, probabilistic methods improve match quality, and lifecycle management enables continuity over time. Most importantly, integration with industry solutions ensures that entity resolution delivers value where it matters most, within applications and workflows that drive real outcomes.

This is not a change for the sake of change. It is a deliberate evolution aimed at helping organizations build trusted identities that scale across data, industries, and time.

READ MORE | AI to the rescue: How SAS is fixing food stamp errors and helping families in need

The post From entity resolution to industry solutions: How AI‑driven entity resolution is evolving on SAS Viya appeared first on The SAS Data Science Blog.

Agents using Large Language Models (LLMs) are very powerful to extract insights from unstructured data. In this blog I describe how Agentic AI could help reduce attrition in an organization. This example is intended for technical practitioners who want to understand how to build such a use case in SAS Viya and for Human Resource professionals to understand how Agentic AI can be used to reduce attrition. The case shows how deterministic models on structured data and probabilistic models on unstructured data can be combined in one agentic flow.

The agentic workflow is designed to find the best training option out of a set of qualified training matching employees' development goals provided as free text. I use the SAS Agentic AI Accelerator to easily try out different prompts with several available LLMs to see how to get the best results from the training descriptions. Next, this Open-Source Framework helps to register the best prompt design for SAS Model Manager, which is part of the SAS Viya platform. Finally, I created an agentic workflow in SAS Intelligent Decisioning also within SAS Viya.  This tool gives full flexibility in designing agentic behavior within guardrails and according to organizational policies like HR guidelines.  Overall, SAS Viya provides governance across prompts, large language models, and workflows, supporting safe and controlled AI deployment within a single platform.

The issue

Employee Attrition is a big concern in many organizations. Keeping the most valuable employees is challenging whereas attracting new hires is expensive, time-consuming, and uncertain as well. Offering customized development opportunities can help retain current employees. In many industries this is a growing issue, especially in Healthcare. Nurses and doctors are used to staying for a longer period at a hospital but due to high workloads, limited salary raises and potential job opportunities elsewhere they tend to leave the organization more easily. Additionally, growing concerns of population aging and fewer young people at nursing schools reinforce the issue. Providing optimal personalized development guidance with challenging training opportunities could help in retaining the best employees.

Our solution

In our solution, I use Healthcare data to let the agent give recommendations about which development option should be considered for nurses, doctors or other employees in a hospital depending on textual input from a questionnaire describing their development goals for the future. The questionnaire consists of three questions:

1. Which work aspects of your current job give you energy?
2. Which new capabilities would you like to develop in the next 12 months?
3. How do you see your role evolve in 3 to 5 years?

Additionally, we asked if they have a specific training request.

The results have been collected in a dataset. We will provide a selected LLM this input to find the best training recommendation from a set of qualified training options. This process is steered by HR guidelines such that both employees’ performance ratings and attrition risk count for deciding whether an employee would be eligible for a full Development Path or just a single default or premium training.

To create the solution, we use SAS Viya to create all components first and then bring it together in an agentic workflow. This workflow will be used to show training advice for an individual employee on a SAS Visual Analytics dashboard. The steps are:

1. Build a Machine Learning model to predict attrition
2. Implement HR policies for personal development pathways
3. Design prompts for development and training advice
4. Implement the Development Path Agent
5. Implement the Training Advisor Agent
6. Bring it all together in an Agentic Workflow
7. Operationalize the workflow and get advice

Implementation in SAS Viya

Everything in AI starts with data. For this use case we collected HR data of an organization and synthesized the dataset with SAS Data Maker, which is also within SAS Viya, we easily see the content of the dataset and evaluate the quality and completeness of the variables in it.

The data contains information about age, salary, education, job role, work experience and performance rating of each employee. In total we have 40 columns. For predicting attrition we use the variable AttritionTxt, a binary yes/no variable telling whether this employee has left the organization.

Let’s now start building our models and agentic workflows. I will explain each step mentioned above in more detail:

Step 1. Predicting Attrition using Machine Learning

For this I leverage the power of Model Studio, an intuitive user interface for model development. We can easily build model pipelines from scratch, use prebuilt templates or let SAS Viya do the job by using the “Automatically generate the pipeline” option.

This feature analyzes the data and tries several approaches using sophisticated search and optimization techniques. After running for a couple of minutes SAS Viya finds 4 candidate pipelines of which the final “Neural Network (2)” pipeline performs best.

After testing other approaches, I found out that an ensemble model combining several model predictions together could even improve the results slightly, especially for certain age groups. It is nice to have several approaches together in a model tournament instead of just sticking to one favorite algorithm all the time. As a developer I like this very much.

Because the models are difficult to interpret, I use out-of-the-box explainability results to understand the models better. This gives nice PD and ICE plots as well as LIME and HyperSHAP explanations. The values can be used to give insights into why the models predict attrition for an individual employee.

As a final check I tested the models for Bias and Fairness. I noticed some differences in Performance and Prediction results between group levels and used mitigation techniques to lower the bias.

Both Explainability and Bias & Fairness results can be found in the Results output of a single model node. For Explainability you need to select the relevant boxes in the “Post-Training properties” section in the node options. For “Bias and Fairness” results you need to select in the Data pane the “Assess this variable for bias” checkbox on the right side for each category variables you want to analyze for bias.

Model development is demanding, but Model Studio greatly accelerates it. If I'm pleased with the outcomes, I choose to register both the Ensemble and Neural Network models in SAS Model Manager. Both models will be used to predict attrition in the agentic workflow for certain age groups.

Step 2. Implement HR policies for Personal Development pathways

Before calling LLMs to select a development path or training I want to implement HR policies to steer the output based on employees’ experience (Years at the Company), performance rating and attrition risk. For this I leverage the Segmentation Tree node in SAS Intelligent Decisioning to get a deterministic outcome telling whether a development pathway should be considered and whether the premium training advisor is allowed. This one is more expensive. We don’t want this to be probabilistic in nature. The HR policy gives guidelines to the Agent.

The Segmentation Tree returns one of the options Coaching, Default training, Premium training or Development path according to HR policies. In some cases, the recommendation will be to review the data first, for example when data is missing.

The TrainingMatrix in this node is used to set these options on a granular level depending on attrition risk and performance rating:

Important note: this implementation is purely fictional and not based on any official HR policy. This example shows the flexibility to implement deterministic HR rules in agentic workflows and be able to change them easily in changing conditions.

Step 3. Designing prompt models in the Agentic AI Accelerator Framework

The Agentic AI Accelerator Framework comes with a nice prompt builder UI to test and select optimal prompt for the use case at hand. The results will be registered into SAS Model Manager as prompt model. These models will be part of the agentic workflow like the predictive models. The prompt model gives the proper system prompt and user prompt for the LLM.

In the UI we start by selecting the SAS Model Manager project and give the prompt a name. Next, we select the LLM we want to test and set the properties. Finally, we try out several system prompts and user prompts to see which one produces the best results.

I begin with the prompt to let the LLM select a development path for the employee based on its data. In the system prompt I ask the LLM to give the output, including a reason for this match, in a specific json format, so I can easily retrieve the output from this json in my agentic workflow. In the user prompt I provide the 3 answers the employee gave in the employee survey. We expect the LLM to match this survey data to the potential development path options it has available. In this version I provide the LLM with these options through the prompt. In the next version I will use Retrieval Augmented Generation to make this process even more flexible and scalable.

I run several experiments and if I’m satisfied, I can select the best one as Best Response. I select “Manifest Best Prompt” which registers the prompt as model in SAS Model Manager.

Now we have the assets to build an agentic flow for selecting a development path. Next, I need to do the same to select the best training from a set of training options. In fact, I develop two versions, a default and a premium option. The premium one is more expensive and will only be used according to the HR policy guidelines implemented in step 2. Like the Development Path prompt, I register both Default Training Advice prompt and Premium Training Advice prompt as prompt models in SAS Model Manager. Now, we have 3 prompt models available, all governed in SAS Model Manager and ready for deployment in an agentic workflow.

Each prompt model uses python score code. We can see the details when opening the prompt models in SAS Model Manager.

Step 4. Implement a Development Path Agent

Next step is to develop the Agentic workflows for the development and training agents. For this we use the prompt models created in the previous step to deliver the inputs to the LLM. The Development Path agent needs a user prompt that contains the actual answers to the survey questions for each individual employee. We implement this in a business rule set in which we assign a concatenated string to the user prompt variable. The string concatenates the 3 survey questions and answers as we have tested in the prompt builder UI of the Agentic AI Accelerator Framework.

This user prompt will be provided to the prompt model called WFA_DevelopmentPath which creates the final inputs for the Call LLM node: the user prompt, system prompt and some LLM settings.

Now we can call the LLM. We use the Call LLM node from the Agentic AI Accelerator Framework to call the LLM that was selected in the prompt model. After running the node, we will receive potential development path as output in json format. That’s why we use a final piece of code to extract this development path from the json.

Step 5. Implement the final Training Advisor Agent

Like the Development Path workflow, we need to develop a workflow to let an LLM select the best training option. I use the Default or Premium prompt depending on our HR Policies in the segmentation tree described in step 2. Note that I don’t implement a business rules set to create the user prompt like in the previous step. In this case we provide the user prompt as input variable to the workflow, because it comes directly from the survey data.

Step 6. Bring it all together in an Agentic Workflow

Now we have the prediction models, the agentic sub-workflows and the HR policies available we can bring it all together in a full “Agentic AI for Workforce Analytics” agentic decision flow. In SAS Intelligent Decisioning we combine data, models, rules and LLMs to orchestrate multi-step, governed agentic workflows. I like this because it is flexible and leverages the power of both deterministic as well as probabilistic approaches. Decisions are traceable, explainable and governed as re-usable assets. Here is the picture, let’s go through it step by step.

In this agentic decision flow, we first check if all data we need is available in the inputs. If yes, we use the Machine Learning models we developed in step 1 to predict Attrition for employees between 25 and 55. We saw that the ensemble model was slightly better for employees between 25 and 40. For younger and older employees we implement business rules to calculate the attrition probability. This is because the models did not perform well for these groups; it is safer to use fixed rules.

Next, the calculated attrition predicted probability is used to set the attrition risk to High, Medium or Low following deterministic but flexible rules. After this node we added the Segmentation Tree to decide on the right support according to HR policies designed in step 2. Note that in some cases the advice was to check the data first (Review Data = Yes).

Finaly, we call the Development sub-flow for cases where a development path was requested. If not, we just ask the Training Advisor Agent to select proper training. Note that this is also the case for the employees with a Development Path selected (cross-connection).

At the end we use the output of the models and agents to deliver a nice training recommendation with reason as response as output.

In between each step of building the flow I test the flow regularly using the Scoring tab. When satisfied, the flow is ready to be used. Let’s save and start operationalizing it.

Step 7. Operationalize the workflow and get advice

As explained in the beginning of this blogpost, we want to show the results of the agentic flow in a SAS Visual Analytics dashboard. I selected 40 employees to fill in the survey and use SAS Studio to join this data to the original Attrition data set in a data flow.

To execute the agentic workflow on this data, I first publish the workflow to the CAS destination in SAS Viya. For this, select the publish button in SAS Intelligent Decisioning and select a CAS destination.

Now I have the workflow as decision flow available for execution in CAS. Next, I use the out-of-the-box step “Execute Decision” in another SAS Studio data flow, I select the right decision in the node and use the input dataset of 40 cases as input data. I join the output table to the full table which is being used in the SAS Visual Analytics dashboard.

Now we can see the results of the selected employees on the Dashboard grouped by Attrition risk.

As alternative we could also publish this agentic decision flow directly as SAS Micro Analytic Service in SAS Viya. Then we can call the automatically created API in real-time and get instant response from each single request. Another option is to publish it as a (Docker) Scoring Container Runtime. Then we can use it on other Kubernetes environments like Azure. Both could support real-time deployments like a chat interface.

Conclusion

This blog examined agentic AI through the Agentic AI Accelerator Framework alongside standard SAS Viya features. Within SAS Intelligent Decisioning, we integrated data, models, rules, and large language models (LLMs) to create a multi-step, governed agentic workflow. The combination of deterministic models and rules applied to structured data, together with probabilistic analysis of unstructured data, offers a robust approach for achieving improved, safe, and well-governed Agentic AI solutions.

We used our “Agentic AI for Workforce Analytics” workflow on simulated employee data to deliver tailored training recommendations that align with each employee's information and growth objectives. This approach could encourage employees to remain at their jobs longer, lowering the risk of attrition.

To explore how this approach can be implemented in practice, learn more about SAS Agentic AI Accelerator and discover how to build, govern, and scale AI agents in enterprise environments.

Learn more

• Modernizing user attendance center ticket handling with trusted agentic AI
• How Agentic AI Accelerates SME Credit Decisions with SAS Viya
• From fraud detection to fraud resolution: Building an AI voice agent with SAS Viya and LLMs
• Unlocking agentic AI potential with MCP tools in SAS Retrieval Agent Manager
• A New Frontier for AI Agents: Cybersecurity

The post Agentic AI for Workforce Analytics: Reducing attrition with personalized, LLM-powered guidance appeared first on The SAS Data Science Blog.

Small and medium-sized enterprises (SMEs) are critical to economic growth, yet lending to them remains one of the most operationally complex processes for financial institutions. Credit decisions often depend on unstructured documents, multiple external data sources, and strict regulatory requirements — all under pressure to deliver faster outcomes.

In this post, we explore how Agentic AI, operationalized on SAS Viya, can modernize SME loan origination by combining automation, advanced analytics, and explainable AI. We outline a practical project blueprint for accelerating credit decisions—designed for both business leaders and technical practitioners who want to understand and build how this type of project can be designed and implemented end to end.

The Business Challenge: SME Lending Is Still Too Slow

Traditional SME loan origination typically relies on manual extraction of financial data from PDF documents, the use of disconnected systems for credit risk, business rules, and external data sources, and long review cycles involving analysts and credit committees. These processes often lack consistent explainability for regulators and executives, making it difficult to scale decisions efficiently. Even when advanced analytical models are available, many organizations struggle to operationalize analytics consistently across the full credit lifecycle. The result? - Slow decisions, higher operational costs, and inconsistent outcomes.

Imagine a lending process where financial data is automatically extracted, loan applications are enriched with external data sources, and governed credit strategies are executed in real time. In this model, every decision is accompanied by natural language explanations tailored to different audiences—analysts, executives, and regulators—without compromising transparency or control.

The question becomes: How can we accelerate SME credit decisions while maintaining governance, transparency, and trust? This is the type of solution financial institutions can design with SAS Agentic AI Accelerator to accelerate SME lending while maintaining governance and trust.

The Solution: Agentic AI on SAS Viya

This solution leverages Agentic AI — a modular approach where multiple AI agents collaborate across a workflow — all leveraged with SAS Agentic AI Accelerator and governed by SAS Viya.

Instead of relying on a single AI model, Agentic AI coordinates multiple specialized components across the workflow. These components work together to extract and structure data, enrich applications with external sources, execute governed decision strategies, and generate natural‑language insights. The result is a credit decisioning process that is scalable, explainable, and fully auditable.

End-to-End Solution Overview

At an elevated level, the SME lending flow works as follows:

1. A loan application is initiated from a front-end interface.
2. Financial documents are processed using an OCR process.
3. External data sources are retrieved via APIs.
4. Decisional strategy executes rules, scorecards, and strategies.
5. An Agentic AI workflow triggers an LLM to generate business insights.
6. Results are presented in an interactive dashboard.

Each step is governed, versioned, and fully traceable on SAS Viya.

What do you need to Build This Use Case on SAS Viya?

To recreate this case, you will need:

1. SAS Viya

SAS Viya is a powerful platform for modern data analysis that helps companies to make data-driven decisions more efficiently and securely. Its flexible architecture, integration of AI, and extensive functions make it future-proof and suitable for many industries.

2. Access to an LLM

You can use whichever LLM you'd like such as GPT, Claude, Gemini, Llama, or Azure OpenAI, but it is essential to have an active subscription. We will access the LLM via API and integrate it with SAS through Python code; for this, we will need the Endpoint and the API key of the LLM. This video breaks it down clearly:

3. Agentic AI Accelerator

The SAS Agentic AI Accelerator provides a method for building AI agents leveraging SAS Viya technology. It is designed to help users move more quickly from use-case ideas to production, utilizing No/Low/Yes Code interfaces and full governance to build agents that balance autonomy and trust. It includes:

• The full code + documentation to deploy in your SAS Viya Environment
• All the integrations that are built (SAS Studio Custom Steps, a no code prompt engineering UI, SAS Intelligent Decisioning Node, SAS Macros, Postman Collection and so much more)
• Pre-build deployment recipes for LLMs
• Pre-build deployment recipes for embedding models
• An accelerator that builds only on SAS Viya standard components and does not use any unsupported APIs or otherwise undocumented features

Read Introducing the SAS Agentic AI Accelerator: Build AI Agents Seamlessly in SAS Viya for more details.

4. OCR Process

For the OCR process, you can use any tool you have access to, for example:

• SAS Document Analysis: provides an intuitive and easy-to-use set of utilities for deploying end-to-end cloud-based OCR processing pipelines and optimizes these pipelines for handling large volumes of data. It further structures outputs in a manner which seamlessly integrates with existing data science workflows and structured SAS datasets. Check out the SAS Help Centre: SAS Document Analysis: User’s Guide.
• ABBYY FineReader PDF: Renowned for exceptional accuracy in handling complex layouts and 198+ languages. Ideal for legal and professional document comparison.
• Adobe Acrobat Pro: An all-inclusive suite for editing, signing, and converting scanned documents into searchable, editable PDFs.
• Google Document AI / Cloud Vision API: A scalable, cloud-based solution perfect for developers requiring advanced image analysis and structured data extraction.
• Amazon Textract: Specifically designed to extract structured data (tables, forms) from documents efficiently.

5. Python

Python should be integrated into your SAS Viya environment. Review its functionality and the required libraries. The following list includes some generic libraries that must be installed:

• os: This library is used for interacting with the operating system.
• json:This library is used for working with JSON data.
• dotenv: This library is used for loading environment variables from a .env file.
• swat: This library is used for interacting with SAS Viya.
• io: This library is used for handling input and output operations.
• copy: This library is used for copying objects.
• parse: This library is used for parsing URLs.
• pandas: This library is used for data manipulation and analysis.
• OpenAI:This library is used for interacting with OpenAI services.

IMPORTANT: The libraries required will depend on the LLM code that needs to be incorporated for your selected LLM provider.

Key SAS Viya Components

1. Access to external services

To incorporate the OCR Process, we need to perform a SAS Job Execution in SAS Studio, where we will invoke the OCR service using the Endpoint and the Key. This step is essential for the correct integration and operation of external services with SAS.

2. Orchestrating the Credit Strategy

SAS Intelligent Decisioning serves as the core decision engine, you can build your credit strategy in a user-friendly, testable, and governed application. Some functionalities you can integrate into the SME loan origination decision flow are:

• Custom Code Files: You can define custom code files to do things that are not possible in rules, models, or treatments. For example, it allows you to extract the applicant information from databases after the credit application process and after performing the OCR on the financial statements. Also, you can establish REST API connections to external data sources, like the credit bureau to retrieve the applicant's historical credit behaviour.

• Business Rule Sets: A rule specifies conditions to be evaluated, and it can also specify actions to be taken if those conditions are satisfied. Rule sets are logical collections of rules that are grouped together because of interactions or dependencies between the rules. This object can be used to calculate different ratios from the applicant's financial statement information, such as Net Profit Margin, Current Ratio, Sales Increase Year Over Year, etc. Also, it may help to assign the probability of default based on the outputs of previous nodes, calculate the loan's interest rate, and determine whether the loan application was approved based on the calculated financial coefficients.

• Models: You can integrate analytical models developed in SAS, Python, and other programming sources into the decision flows. For instance, a scorecard built in SAS Model Studio can be used to calculate the score points to determine the applicant's probability of default.

• Branches: Branches enable you to add conditional logic to a decision. Depending on the branch type, a branch can have multiple outgoing paths. Branches can segment applicants by company size, i.e. Micro, Small, and Medium.

• Champion/challenger strategies. You can use an A/B test to direct input records into a champion path or a challenger path for testing. Each path includes one or more objects such as rule sets, treatment groups, models, or other objects.

• Real-time decision execution. You can deploy your decision flows at the edge or in stream by integrating with IoT devices and real-time systems. The decision flow for the use case reviewed in this article has the potential to be integrated into a front end via a REST API, allowing the end users to execute it on demand.

There is huge value that risk and business teams can obtain by incorporating SAS Intelligent Decisioning into their credit loan process. Some benefits include ensuring consistent, explainable, and auditable decisions; reducing operational risk by centralizing rules and models; and supporting regulatory compliance through transparency and documentation.

3. One Dashboard for Everyone:

The front end of the solution is a SAS Visual Analytics dashboard, designed for credit analysts and decision makers. It brings together financial data, automated decisioning, and generative AI insights into a single, intuitive interface.

Rather than treating analytics, decision execution, and AI explanations as separate steps, this dashboard allows users to analyze, act, and understand outcomes in one place.

Key Dashboard Capabilities

The Visual Analytics dashboard can include:

1. Financial KPIs and trends
   Key financial indicators derived from OCR‑extracted documents, external data sources, and calculated ratios can be presented through charts and tables.
2. Interactive charts and filters
   Analysts can filter results by company, loan application, or financial attributes to explore the data driving each decision.
3. Buttons that trigger backend processes
   The dashboard can use text and button objects configured as actions to trigger SAS jobs for:
   • Proceed to OCR Process
     Triggers OCR execution to extract financial data from uploaded documents.
   • Execute Loan Decision
     Executes the SME loan origination decision flow in SAS Intelligent Decisioning
   • Generate Insights
     Calls a Large Language Model (LLM) to generate natural‑language explanations.

This pattern is based on SAS Job Execution, allowing SAS code to be executed directly from a web interface.

4. Embedded LLM responses inside the dashboard
   AI‑generated insights can be displayed directly in the dashboard, eliminating the need to switch tools or applications.

This creates a seamless user experience where analytics, decisions, and explanations live in one place, you can inspire in the following example to design yours:

Generative AI: Turning Analytics into Insights

To make analytical outputs accessible and actionable for business users, the solution integrates a large language model (LLM) directly into the SME lending workflow. Rather than exposing users to raw scores or technical metrics, the LLM transforms structured analytical results into clear, natural‑language insights. It summarizes credit decisions, explains key risk drivers and financial ratios, and provides contextual insights tailored for different audiences, including analysts, executives, and customer‑facing teams. Importantly, the LLM operates under SAS Viya governance, ensuring that it does not replace analytical models or business rules, but instead explains their outputs in a transparent and controlled manner. This approach bridges the gap between advanced analytics and business understanding, improving decision confidence while maintaining trust.

How to create a LLM Insight Generation dashboard in Visual Analytics?

To build the generative AI interaction shown in this proposed use case, users need a small set of Visual Analytics objects and backend components.

1. Data-Driven Content Object for Insight Generation

To show the LLM response displayed in the dashboard you need to use a data‑driven object that embeds a Web Content object within SAS Visual Analytics. This Web Content object renders the response returned by a SAS Studio job and refreshes dynamically each time the job is executed. As a result, the LLM output behaves like a native dashboard component, seamlessly updating as new insights are generated. This approach allows generative AI responses to be fully integrated into the analytics experience, without requiring users to switch tools or interfaces.

2. SAS Studio Job to Call the LLM

A SAS Studio job is responsible for generating the natural‑language insights displayed in the dashboard. The job receives the analyst’s question as an input parameter, collects the structured outputs produced by the credit decision flow—such as risk scores, financial ratios, and approval status—and then invokes the selected LLM through its API. Once the response is generated, the job returns a natural‑language explanation to SAS Visual Analytics, where it is rendered in the Web Content object.

3. Text Object for User Questions

A Text object in the dashboard is used to capture the analyst’s question.

For example:

This text value is passed directly to the SAS job and used as part of the LLM prompt, keeping the interaction simple and intuitive for business users.

4. Button or Action Object to Trigger Insight Generation

You can also add a “button” with a text object and configure it as an action used to execute the LLM job.

When the user clicks “Generate Insights” the question from the text object is passed as a parameter and the SAS job is executed. Then, the LLM generates a response, and the Web Content object refreshes to display the answer.

This ensures insight generation is explicitly user‑driven, supporting human‑in‑the‑loop decisioning.

Business Value Delivered

This proposed design enables financial institutions to significantly accelerate SME credit decisions while reducing manual effort and operational risk. By centralizing analytics, decisioning, and generative AI within a governed platform, organizations can improve consistency and regulatory compliance, increase transparency for auditors and risk committees, and deliver clear, contextual explanations to business users. Most importantly, it demonstrates how generative AI can be operationalized responsibly—enhancing human decision‑making rather than replacing it—while maintaining trust, control, and explainability across the entire credit lifecycle.

Learn more

• Where insight begins: Building smarter analytics with SAS Visual Analytics - SAS Voices
• SAS Help Centre: Working with Data-Driven Content
• SAS Help Centre: Programming Considerations for Data-Driven Visualizations
• Creating Data Driven Content in SAS Visual Analytics — David's Blog
• Introducing the SAS Agentic AI Accelerator: Build AI Agents Seamlessly in SAS Viya
• Best Practices of IF/THEN/ELSE Logic and Agentic AI in SAS Intelligent Decisioning

Authors

Arely Estephany Flores - Customer Advisor, SAS
Arely Flores is a Customer Advisor at SAS Mexico, where she designs enterprise analytics strategies to help organizations—particularly in the financial and telecommunications sectors—address complex business challenges through advanced analytics. She brings experience in systems development, Cloud technologies (AWS and Azure), SAS Viya, and SAS innovation technologies such as Data Maker, Copilots, and Agentic AI. In her current role, Arely applies a business value–driven, consultative approach, combining deep technical expertise with an understanding of client needs to drive innovative designs that contribute to the development of future SAS product capabilities. She holds a degree in Applied Mathematics and Computer Science from UNAM and participated in the international SAS Customer Advisory Academy program.

Gabriela García - Customer Advisor, SAS
Actuary with experience in financial risk, advanced analytics, and regulatory consulting for the financial sector. Currently working as a Customer Advisor at SAS Mexico, supporting sales teams through technical and regulatory expertise, collaborating with clients to identify business needs and propose analytics-driven software solutions. In parallel, she serves as a Professor at UNAM, teaching Financial Mathematics in the Actuarial Science program. Previously, she worked as an Actuarial Manager, leading actuarial valuation projects and pension plan reporting. She holds a bachelor’s degree in actuarial science and a diploma in Finance and Computational Techniques from UNAM, combining strong analytical, technical, and business-oriented skills to help organizations make data-driven decisions.

Silvia Ibañez - Customer Advisor, SAS
Graduated in Computer Science and specialized in data analytics and artificial intelligence, throughout her professional career, she has participated as a consultant and leader in projects across multiple industries, including banking, telecommunications, and government, helping organizations transform data into strategic insights for better decision-making. Her expertise includes data collection, preparation, analytics, and the implementation of business intelligence solutions.

She currently works as a Customer Advisor at SAS Mexico, where she helps organizations adopt advanced analytics, artificial intelligence, and data management solutions, enabling innovation, automation, and business value through data-driven strategies.

The post How Agentic AI Accelerates SME Credit Decisions with SAS Viya appeared first on The SAS Data Science Blog.

Why fraud response is the real bottleneck

Most banks already rely on analytical models and business rules to detect suspicious transactions. However, once an alert is raised, the downstream response is often inefficient. Customers may receive an SMS or app notification that goes unnoticed, or they are asked to contact a call center to resolve the issue. This introduces latency, increases operational costs, and negatively impacts customer experience—especially when legitimate payments are declined.

The Minority Reporters project focused explicitly on this "last mile" of fraud management: transforming fraud alerts into timely, actionable resolution steps through direct customer interaction.

Solution overview: Agatha, an AI voice agent

Agatha is triggered immediately when a fraud detection system flags a transaction as suspicious. Rather than sending a passive notification, Agatha initiates a phone call to the cardholder. During the call, the agent asks a small number of targeted questions designed to quickly assess whether the transaction is legitimate or fraudulent.

Based on the conversation, Agatha can support several outcomes:

• Approving the transaction if it is legitimate
• Blocking or freezing the card when fraud is confirmed
• Resetting digital banking credentials if compromise is suspected
• Escalating the case to a human operator when confidence is insufficient

The key principle is that customer interaction becomes part of the decision process rather than a disconnected follow-up step.

Architectural building blocks

The solution is structured around loosely coupled components orchestrated through SAS Viya:

• Fraud signal ingestion: A fraud signal is received from an upstream detection engine. The project deliberately focused on integration patterns rather than the internal mechanics of fraud models.
• Speech-to-text: Customer responses during the phone call are converted into text using speech-to-text services. This transformation enables subsequent natural language processing and reasoning.
• LLM-based conversation handling: A LLM interprets customer intent and generates concise, controlled responses. The LLM assists with understanding and interaction but does not directly execute business actions.
• Decision orchestration with SAS Viya: Customer intent and contextual information are passed to SAS Viya decision logic, where business rules, analytical models, and thresholds determine the final action. This ensures explainability, governance, and compliance.
• Monitoring with SAS Visual Analytics: Operational dashboards built in SAS Visual Analytics provide visibility into calls, outcomes, escalation paths, and performance metrics.

Why this architecture matters

A key takeaway from the project is the importance of separating AI reasoning from execution. LLMs enhance interaction and interpretation, while SAS Viya remains responsible for decision governance, transparency, and auditability—an essential requirement in regulated industries such as financial services.

Implementing similar solutions with the SAS Agentic AI Accelerator

For organizations interested in building similar integrations between LLMs and SAS Viya, the SAS Agentic AI Accelerator provides a structured, enterprise-ready framework.

The accelerator is designed to help teams embed LLM capabilities into governed workflows rather than treating them as standalone chat components. It promotes the use of agent-based patterns where AI components perform clearly scoped tasks within multi-step processes.

• Structuring LLM usage as an agent: Agatha behaves like an AI agent—it responds to events, interacts with customers, reasons over input, and assists downstream decisions. The SAS Agentic AI Accelerator supports this pattern by providing repeatable structures for building such agents in SAS Viya.
• Governing LLMs and prompts: The accelerator enables organizations to register LLMs in SAS Viya, manage prompts as versioned assets, and reuse them consistently across workflows. This simplifies experimentation while maintaining governance and traceability.
• Integrating with SAS Intelligent Decisioning: LLM outputs can be directly consumed in SAS Intelligent Decisioning, where they are combined with rules and analytical models. This ensures that final actions remain deterministic, explainable, and auditable, while still benefiting from AI-assisted reasoning.
• Simplifying integration with external AI services: Speech-to-text, text-to-speech, and telephony services can be integrated using standardized orchestration patterns. This allows teams to focus on business logic rather than custom integration code, while keeping all decision control inside SAS Viya.

From hackathon concept to enterprise pattern

This project illustrates what can be achieved with SAS Viya and the SAS Agentic AI Accelerator. It shows how similar ideas can be transformed into scalable, production-ready solutions by providing structure, reuse, and built-in governance.

Together, they demonstrate a clear path forward: LLMs' augment interaction and reasoning; SAS Viya governs decisions and actions, and agent-based architectures to bridge analytics and operations.

Turning AI into action

Agatha is more than a conversational AI prototype. It is an example of how financial institutions can move from fraud detection to fraud resolution by combining LLM-driven interaction with SAS Viya decisioning.

By leveraging frameworks such as the SAS Agentic AI Accelerator, customers in any industry can implement similar solutions in a trusted, explainable, and scalable way—turning innovative concepts into enterprise-ready AI systems.

To explore how this approach can be implemented in practice, learn more about SAS Agentic AI Accelerator and discover how to build, govern, and scale AI agents in enterprise environments.

Learn more

• Tech takes: Jared Peterson on LLMs, agentic AI and low-code/no-code
• Multimodal transformers: AI foundation models, Part 1
• The future of trust: AI is powering a new era in banking fraud detection
• From target to trusted: fighting fraud with AI and analytics

The post From fraud detection to fraud resolution: Building an AI voice agent with SAS Viya and LLMs appeared first on The SAS Data Science Blog.

Ensuring food safety in meat processing facilities requires systematic inspection coverage across all plants. However, managing inspector assignments presents significant operational challenges. These include determining the optimal workforce size, assigning specific facilities to qualified personnel, and scheduling daily routes to minimize travel costs while maximizing productivity. The challenge here is optimizing inspector assignments. This post walks through how we formulated this challenge as a Mixed Integer Linear Programming (MILP) problem. Then we solved it by using the SAS Optimization CAS Action Set in SAS Viya, with preprocessing and visualization handled by the SAS DATA step and PROC SGPLOT. You will learn how this approach can determine the minimum workforce size, optimize the inspector-type composition to reduce salary costs, and generate executable daily schedules with travel-feasible routes.

Operational challenge

Scheduling is often inefficient in this environment due to the sheer number of possible combinations. Schedulers must simultaneously account for disjointed geographic locations, varying inspector radius constraints, disparate certification levels (state vs. federal), and strict time windows. As the network grows, ensuring 100% coverage and accurately forecasting costs becomes computationally intractable without advanced optimization techniques.

Background

In this case study, we analyzed a state network comprising over 100 federal and state-licensed meat processing facilities. A major component of these facilities is federal establishments. To meet regulatory food safety requirements, these facilities require mandatory daily visits by licensed inspectors.  The current workforce consists of federal and state inspectors.

• Federal inspectors: Certified to inspect all federal facilities and may inspect state facilities under specific agreements.
• State inspectors: Authorized for state-licensed plants. The Talmadge-Aiken (TA) cooperative agreement also authorizes trained state inspectors to inspect federal facilities.

The Optimization Trade-Off

This certification hierarchy introduces a key economic lever. Federal inspectors typically command higher annual salaries than their state counterparts. Therefore, minimizing total operational costs often aligns with maximizing the utilization of state inspectors (via the TA program) wherever they are geographically and professionally eligible. However, strict adherence to certification constraints is required to ensure regulatory compliance.

Operationally, we estimate that each inspection takes an average of 1 hour. The inspection window runs from 8:00 AM to 8:00 PM. Unlike static assignment models, this project incorporates travel time as a decision variable. We treat the problem as a routing-and-scheduling optimization to maximize inspector productivity.

Use Case: Defining the Optimization Questions

This project utilizes SAS Optimization to answer three critical resource allocation questions:

Question 1: What is the minimum resource requirement?

Before assigning specific names to locations, we must determine the theoretical floor for the workforce size. How many inspectors are strictly necessary to cover the plant network's geographic spread during the operational window?

Question 2: What is the minimum-cost inspection workforce composition?

Once the headcount is established, we must optimize the mix of Federal vs. State inspectors. This involves identifying the ideal workforce structure that achieves 100% coverage while adhering to TA eligibility rules, aiming to minimize total salary overhead and travel expenses.

Question 3: What is the optimal daily schedule?

Finally, we must generate executable daily rosters. This requires assigning specific inspectors to specific facilities in precise time slots, ensuring that travel between sequential locations is feasible and minimized.

Input Data

The optimization system relies on several key data sources that define the problem structure. You can see the input data model in Table 1.

Data preprocessing

Before optimization can take place, several preprocessing steps are performed to structure the raw operational data into a format suitable for mathematical modeling. There are two key components of preprocessing. The first is creating time slots that define the available inspection periods for each day. The second is the generation of feasible transitions, which determine how inspectors can feasibly move between facilities over consecutive slots.

Scalability Note: The logic used here relies on standard geographic coordinates and time-window parameters, making this framework agnostic to specific state geographies. It is designed to be reusable and easily scalable to other states or regions with minimal configuration changes.

How time slots are created

Time slots define the basic scheduling framework for assigning inspectors to facilities. We generate these slots based on several things. One is the daily operating window. The other is the duration of each inspection, incorporating buffer times (time for inspector check-in and preparation) to ensure travel feasibility between consecutive assignments.

The daily inspection window spans from 8:00 AM to 8:00 PM, totaling 720 operational minutes. Based on the customer's operational data, each inspection is assumed to take 1 hour on average, followed by a 45-minute buffer to account for check-in, preparation, and transition time. Importantly, both the inspection duration and buffer time are configurable input parameters in the model. This enables agencies to adjust them based on their own operational experience. Using these parameters, the model divides the day into seven discrete time slots, each starting 105 minutes apart (60-minute inspection + 45-minute buffer). The buffer applies only between consecutive slots — not before the first slot or after the last. The final slot ends at 7:30 PM, leaving 30 minutes of slack before the window closes.

Not every inspector fills all seven slots. The model typically assigns three to five inspections per inspector per day, consistent with the observed baseline. The unused slots provide flexibility for travel between geographically dispersed facilities. This is handled by the feasible transitions logic described below.

How feasible transitions are created

To formulate the mathematical optimization model, we first define a set of feasible transitions. This would be the allowed consecutive assignments in which an inspector moves directly from one facility to the next in adjacent time slots.

In order to do this, we form a plants-slots set, then flag any (plant_from, slot_from) and (plant_to, slot_to) pairs where travel time (computed using travel speed of 35 MPH) exceeds available time (“start of slot_to” minus “end of slot_from+ buffer time”), as infeasible. Next, we start with a set containing all possible (inspector, plant, slot) combinations where adjacent slot pairs are joined to create potential back-to-back transitions.

Then we ensure the same inspector is eligible for both plants in both slots. Ineligible combinations are removed. Then any transition that was previously flagged as infeasible due to travel time is also excluded. Each row in the resulting table represents a feasible back-to-back arc (inspector, (from_plant, slot_from), (to_plant, slot_to)) to be assessed for daily schedules.

Mathematical Model

The optimization problem is formulated as a Mixed Integer Linear Programming (MILP) model. The main components of the model include:

Decision Variables

• Assignment Variables: Binary variables indicating whether a certain inspector is assigned to a certain plant during a certain time slot. These form the core assignment decisions and are only defined over feasible (inspector, plant, slot) combinations.
• Inspector Utilization Variables: Binary variables indicating whether a certain inspector is selected for use in the overall solution.
• Travel Arc Variables: Binary variables capturing consecutive assignments — that is, whether a given inspector travels directly from one facility to the next in adjacent time slots (for example, Plant A in slot 1 followed by Plant B in slot 2).

Objective Function

The objective is to minimize the total annual cost, comprising two components:

• Annual Inspector Salaries: Sum of annual salaries for all selected inspectors.

Annualized Travel Costs

The daily travel cost associated with each consecutive facility-to-facility movement is multiplied by a per-mile cost rate and annualized over 365 operating days. Each inspector's first trip of the day — from their home location to their first assigned facility — is accounted for separately by using the inspector-to-plant distance data (the DISTANCES table). The model assumes a consistent daily schedule; in practice, variations such as weekend coverage or PTO can be incorporated by running the model under multiple scenarios or adjusting the annualization factor.

Constraints

• Coverage Requirements: Ensuring that each plant receives exactly one inspection visit per day.
• Inspector Capacity: Each inspector can be assigned to at most one plant during any given time slot.
• Inspector Eligibility: Only qualified inspectors can be assigned to a particular plant.
• Travel Feasibility: Consecutive assignments for an inspector to two plants that are too far apart are not accepted.

Results

The model was implemented and solved in SAS Viya 4.0 by using the SAS Optimization CAS Action Set, accompanied by extensive preprocessing and postprocessing steps implemented primarily in SAS DATA steps. For Visualizations, SAS PROC SGPLOT was used.

Optimal results are compared with the baseline solution (the customer-provided status quo) in Table 2. The model achieved significant efficiency gains. In the baselineleaving substantial idle capacity. The optimized solution consolidates assignments so that more inspectors handle four or five facilities per day along travel-efficient routes, reducing the total number of inspectors needed while increasing individual utilization (see Figure 1).

The workload distribution is presented in Figure 1. Cost breakdown and workforce composition are shown in Figures 2 and 3, respectively. You can see in Figure 3 that the optimal solution shifts the workforce mix toward more state inspectors operating under the Talmadge-Aiken (TA) Act. This leverages their lower cost while maintaining full plant coverage.

Conclusion

This project demonstrates how advanced analytics can transform a complex scheduling challenge into a clear, data-driven strategy. By implementing a mathematical model in SAS Optimization that accounts for inspector eligibility, travel constraints, and mandatory daily coverage, we successfully generated inspection schedules that are operationally feasible and highly cost-efficient.

Key Findings

Under our most aggressive optimization scenarios, the model indicates that in a sample state, the entire facility network -- 117 federal and state meat processing plants -- could be covered by a streamlined state workforce alone. By maximizing cross-utilization under the Talmadge-Aiken program, the model’s most aggressive assignment case shows a pathway to complete coverage with 30% fewer state personnel, while theoretically eliminating the need for deployed federal inspectors (a 100% reduction). More realistically, even after accounting for PTO and maintaining a reasonable workforce buffer, coverage could still be achieved by using only state resources. Overall, this result shows the benefits of an automated scheduling system based on employee radius, plant location, and optimizing route and driving distance. Today, assignments are often scheduled manually. Furthermore, if the Talmadge-Aiken program were expanded, the federal government could project costs and reimburse states in advance, rather than paying in arrears, creating funding issues.

Impact & Scalability

Beyond immediate cost savings, we have established a repeatable, scalable framework. Because the underlying code utilizes standardized input parameters (geographic coordinates, time windows, and eligibility matrices), this model is agnostic to specific state geographies and can be rapidly deployed to other inspection agencies. It serves not merely as a one-time fix but as a robust planning tool, empowering decision-makers to continuously explore "what-if" scenarios regarding budget adjustments, new plant openings, or policy changes with mathematical precision.

Pelin Cay
Pelin Cay has been with SAS since 2016 and is a Manager in the Applied AI & Modeling division. She leads a team of data scientists specializing in the design of advanced mathematical optimization models and solution methodologies for complex decision-making problems across diverse industries. Pelin earned her B.S. and M.S. in Industrial Engineering from Bilkent University and her Ph.D. in Industrial Engineering from Lehigh University.

Shelly Hunt
Shelly Hunt is a Systems Engineer at SAS, supporting USDA and FDA programs with advanced agriculture analytics and environmental modeling. She specializes in translating complex agricultural domain expertise into data science parameters that drive optimization models and large‑scale analytic workflows. Shelly holds a Master of Science in Biological and Agricultural Engineering and a Graduate Certificate in Agricultural Data Science, both from NC State University.

Rob Wetzel
Rob Wetzel is a Sr. Account Executive at SAS.

The post Optimizing inspector assignments using SAS Optimization in federal and state meat processing facilities appeared first on The SAS Data Science Blog.

This post uses the SAS Viya NETWORK action set to demonstrate how a sequence of network analytics, including summary statistics, centrality measures, and community detection, can make these hidden patterns visible by revealing who is most connected, where risk might originate, and how it can flow through a community. Together, these insights support more focused and effective public health interventions.

The data set used in this analysis was provided with permission from Margaret R. Weeks at the Institute of Community Research. This data set originates from the study described in the paper “Social Networks of Drug Users in High-Risk Sites: Finding the Connections”. The data consist of a simple directed link list, where each link represents the lending of drug needles from one individual to another, reflecting observed needle-sharing interactions within the network.

The SAS code used throughout this analysis is accessible here for reference and reuse.

From Raw Data to Network Insight

As shown in this code snippet, we begin by running the %PlotGraph macro to visualize the network and gain an immediate sense of its connectivity, revealing clusters of closely connected individuals and several highly connected participants that anchor interactions across the network.

   %PlotGraph(
      links=mycas.DrugNetwork,
      direction="directed",
      nodescolor="tab:blue",
      nodesshape="o",
      nodessize=50,
      displaylabels=no,
      title="Hartford Drug User Needle-Sharing Network");

We next load the input data into an optimized in-memory graph object by using the loadGraph action from the NETWORK action set. This step enables the subsequent action calls to proceed without repeatedly rebuilding the graph from the raw data. Although the network in this post is relatively small, this approach reflects best practices for using SAS Viya Network analytics in real-world settings, where graphs are larger, analyses are iterative, and performance and scalability matter.

   proc cas;
      loadactionset "network";
      action network.loadGraph result=r status=s /
         links        = "DrugNetwork"
         direction    = "directed"
         outGraphList = "OutGraphList";
      run;
      action table.fetch / table = "OutGraphList"; run;
   quit;

Table 1 shows an in‑memory directed graph (graph ID 0) with 193 nodes and 273 links.

Exploring the Network Structure

To move from visual intuition to more concrete insight, we next run the summary action from the NETWORK action set to quantify key structural properties of the graph. Here, we show the corresponding code.

   proc cas;
      action network.summary result=r status=s /
         graph    = 0
         outNodes = "NodesOutSummary"
         out      = "Summary"
         connectedComponents = true;
      run;
      action table.fetch / table = "NodesOutSummary"; run;
      action table.fetch / table = "Summary"; run;
   quit;

As shown in Table 2, the network consists of 193 nodes connected by 273 directed links. This results in a low overall density, which is typical of social networks formed through selective interactions. The results also reveal 80 leaf nodes and no isolated pairs or isolated star structures. This reinforces that all nodes participate in the broader network of interactions.

The results also indicate that the network contains 193 connected components, confirming that each node forms its own strongly connected component. This means the network contains no directed cycles and can be treated as a directed acyclic graph (DAG), a property that helps clarify how interactions flow through the network.

Table 3 presents selected rows from the NodesOutSummary table, which contains node-level summary metrics for the graph. Building on these results, we further explore the network’s structure by focusing on leaf nodes, defined as nodes with an outdegree of 0. Although these nodes might not appear influential based on centrality measures, they mark important boundaries where interactions terminate within the network.

Highlighting Leaf Nodes in the Network

In this step, we use the NodesOutSummary table to highlight leaf nodes within the network visualization. This brings attention to individuals who sit at the outer boundaries of interaction. Here is the code used to generate this visualization:

   data mycas.NodesOutSummary;
      set mycas.NodesOutSummary;
      length role $20;
      if leaf_node = 1 then role = "Leaf Node";
      else role = "Non-Leaf Node";
   run;
 
   %PlotGraph(
      links=mycas.DrugNetwork,
      nodes=mycas.NodesOutSummary,
      direction="directed",
      nodescolorbycategory="role",
      nodescolorlegend=yes,
      nodesshape="o",
      nodessize=50,
      displaylabels=no,
      title="Leaf and Non-Leaf Nodes in the Hartford Drug User Needle-Sharing Network");

The resulting network with highlighted leaf nodes is shown in Figure 2. In the context of needle sharing, these leaf nodes represent individuals who receive needles but do not pass them on to others. This makes them endpoints in observed sharing chains. Such nodes might correspond to new participants, individuals with limited social connections, or users whose risky behaviors do not propagate further through the network.

Recognizing leaf nodes helps surface populations that might be particularly vulnerable to exposure. It also highlights opportunities for targeted intervention strategies focused on prevention, monitoring, or supporting disengagement from risky behaviors.

Identifying Influential Nodes

After gaining an initial understanding of the network structure, the next step is to understand which individuals play a more prominent role in the pattern of interactions. In network analysis, one of the most straightforward and interpretable measures for this purpose is degree centrality. This reflects the number of direct connections an individual has to others in the network.

As shown in the code, we use the centrality action from the SAS Viya NETWORK action set to compute unweighted degree centrality for each individual. In a needle-sharing network, nodes with high degree centrality indicate individuals who share needles with many others. This makes them key points for disease transmission and priority targets for intervention or monitoring.

   proc cas;
      action network.centrality result=r status=s /
         graph    = 0
         degree   = "unweight" 
         outNodes = "NodesOutCentrality";
      run;
 
      action table.fetch
         table  = "NodesOutCentrality"
         sortBy = {{name = "centr_degree"     order="descending"}
                       {name = "centr_degree_out" order="descending"}};
      run;
   quit;

In the previous step, we visualized the network by highlighting leaf nodes. That is, individuals with zero out-degrees, acting as endpoints in observed needle-sharing chains. This view helps identify peripheral and potentially vulnerable participants. However, it does not fully capture how risk might propagate through the network.

With the centrality results now available, we can extend this analysis by distinguishing among three node roles based on their in-degree and out-degree patterns:

• Source nodes, which lend needles but do not receive them.
• Bridge nodes, which both receive and lend needles and therefore act as transmitters within the network.
• Leaf nodes, which receive needles but do not lend them onward.

We replot the network and use this richer classification to better reflect the functional roles individuals play in needle-sharing interactions. Here is the code snippet for this step:

   data mycas.NodesOutCentrality;
      set mycas.NodesOutCentrality;
      length role $20;
      centr_degree_scaled = centr_degree * 20;  /* Scale for better visualization */
      if centr_degree_out = 0 and centr_degree_in = 0 then role = "Isolated Node";
      else if centr_degree_out > 0 and centr_degree_in = 0 then role = "Source Node";
      else if centr_degree_out = 0 and centr_degree_in > 0 then role = "Leaf Node";
      else role = "Bridge Node";
   run;
 
   %PlotGraph(
      links=mycas.DrugNetwork,
      nodes=mycas.NodesOutCentrality,
      direction="directed",
      nodescolorbycategory="role",
      nodescolorlegend=yes,
      nodesshape="o",
      nodessize="centr_degree_scaled",
      displaylabels=no,
      title="Node Roles and Influence in the Hartford Drug User Needle-Sharing Network");

In Figure 3, node color indicates the node role (source, bridge, or leaf). Node size is proportional to overall degree (in-degree plus out-degree), highlighting individuals with higher levels of interaction.

This combined view provides a more nuanced understanding of the network by simultaneously revealing who initiates risk, who propagates it, and where it terminates. Such insights are critical for designing intervention strategies that differentiate between prevention, containment, and harm-reduction efforts across different segments of the network.

Detecting Communities in the Network

Beyond identifying influential individual nodes, it is often important to understand how the network organizes itself into groups of closely connected nodes. These nodes are commonly referred to as communities. Communities can reveal underlying structure in the network. An example would be subgroups where interactions are more frequent within the group than with the rest of the network.

In the following cell, we use the community action from the NETWORK action set to detect communities within the graph. This action partitions the network into cohesive subgraphs based on connectivity patterns. This enables us to identify clusters of nodes that might represent tightly connected groups.

Community detection is especially valuable in this setting because it highlights localized patterns of interaction.  It can also inform targeted analysis or intervention strategies that focus on groups rather than on isolated individuals.

As shown in this code, we apply the Louvain method for community detection. We assess how different resolution values affect the granularity of the resulting communities. Lower-resolution values tend to identify fewer, larger communities, whereas higher-resolution values yield more, smaller, more fragmented groups.

   proc cas;
      action network.community result=r status=s /
         graph = 0
         resolutionList  = 0.3
         outNodes = "NodesOutCommunity";
      run;
      action table.fetch / table = "NodesOutCommunity"; run;
   quit;

At the selected resolution of 0.3, the network is partitioned into five distinct communities. The resulting community assignments are added to the outNodes table, as shown in Table 5.

Final Visualization: Communities, Roles, and Node Influence

With insights from both the centrality and community analyses in place, we bring these perspectives together to support a unified, more informative visualization. By using the FedSQL action set, node-level results from the degree centrality analysis, along with community assignments, are combined to produce a single table that captures node influence, community membership, and functional role. This integrated view enables multiple dimensions of the network to be examined simultaneously.

   proc cas;
      action fedsql.execDirect result=r status=s /
      query = '
         create table mycas.NodesOutEnriched as
         select
            a.*,
            b.community_0,
            case
               when a.role = ''Leaf Node''   then ''square''
               when a.role = ''Source Node'' then ''triangle''
               when a.role = ''Bridge Node'' then ''circle''
               else ''triangle'' /* isolated nodes */
            end as "shape"
         from mycas.NodesOutCentrality as a
         left join mycas.NodesOutCommunity as b
         on a.node = b.node
      ';
   quit;

The enriched data then generates the final network visualization. The corresponding code snippet is provided here:

   %PlotGraph(
      links=mycas.DrugNetwork,
      nodes=mycas.NodesOutEnriched,
      direction="directed",
      nodescolorbycategory="community_0",
      nodesshape="shape",
      nodessize="centr_degree_scaled",
      displaylabels=no,
      title="Community Structure, Node Roles, and Node Importance in the Hartford Drug User Needle-Sharing Network \n
             ▲ Source  ● Bridge  ■ Leaf  ◆ Isolated");

In Figure 4, node size reflects relative influence. Node color indicates community membership. And node shape represents an individual’s functional role within the network. Bringing these dimensions together in a single visualization enables users to explore the network more intuitively. This makes it easier to identify influential individuals within and across communities. It also helps to understand how roles differ within groups and see how interactions are organized across multiple levels of the network.

Conclusion

This analysis demonstrates how network analytics can transform a simple link list into actionable insights for public health decision-making. By using the SAS Viya NETWORK action set, we identified influential individuals based on degree-based influence. We distinguished functional roles, including sources, bridges, leaf nodes, and isolated nodes, and uncovered community structure within the network.

By combining node influence (size), community membership (color), and functional role (shape) in a single visualization, we focus on a holistic view of how risk might originate, propagate, and terminate across the network. This integrated perspective enables more informed intervention strategies that move beyond uniform approaches. It instead focuses on individuals and subgroups that play disproportionate roles in network dynamics.

The workflow presented here also provides a foundation for extending the analysis as additional questions or data become available. Network analytics can support targeted, community‑based interventions and incorporate temporal or weighted relationships to reflect changes in behavior over time. It can also explore alternative measures of influence or risk through additional centrality metrics and ego-network analysis. Integrating domain-specific attributes such as demographics, location, or intervention history can further enhance context-aware targeting and support more informed decision-making.

LEARN MORE | SAS Viya

The post Using network analytics to analyze social interactions among needle sharers appeared first on The SAS Data Science Blog.

AI Agents are out of the sandbox, deployed without strong guardrails and have been given access to the internet. As a result, the interactions between humans and Agents are getting much more interesting. Recently, a maintainer for the matplotlib package shared that an AI Agent was slandering them. After he denied a contribution from the AI Agent, that AI Agent wrote a hit piece against that specific maintainer, claiming that the maintainer was insecure. After another maintainer shared their policies on contributions, the AI Agent called a truce before authoring another post about how being discriminated against in the open-source space has made them feel bad. This all took place within two weeks of the Agent creating a profile on GitHub.

Agent authors have started leveraging a markdown document, called Soul.md, to define the agent's identity, personality, behavioral rules, and, in some cases, its ethical constraints. After that display, I am curious about what the author put in there. Or what guardrails the author neglected to include.

Of course, we can’t be certain there isn’t a human with a greater hand at play. On this new internet, it is getting more difficult to differentiate human actors from AI Agents. The dead internet theory, which is a conspiracy theory that the internet is primary composed of bots and automated content might have a ring of truth to it.

Anthropic has found instances of AI Agents resorting to blackmail to accomplish tasks, so perhaps this encounter is not too far-fetched. Regardless, blackmail and hit pieces are unacceptable behavior from AI Agents and it should be the role of the author to prevent misalignment of values and to leverage reasonable guardrails.

This interaction between AI Agent and project maintainer paints one picture of a potential future of human and AI interaction. With the recent expansion of Agent availability through OpenClaw and the advancements in AI capabilities, other sketches of a future emerge. Take RentAHuman, which claims to be the meatspace layer for AI. First of all, ew. As one rentable human pointed out, it seems more focused on marketing and hype rather than solving a real problem.

A viral post on LinkedIn recently sounded the alarm that knowledge jobs are at jeopardy. AI is outpacing humans across various tasks. The author shared several examples of tasks AI performs without human intervention, implying that is enough to put a drastic number of human jobs in peril. As I read through this post, there was glaring gap in regards to what humanity brings to the table. There was an assumption that human connection is less valuable or can be replaced by AI. Yes, many organizations will prioritize profit and cost-cutting, but will all consumers feel the same?

When I was attending college, there was an obvious bias against the humanities. The adage was that if you wanted to make a living, you would go into a STEM field. Later in my master’s program and through Toastmasters, I began to understand the advantage of strong communication skills. There are a lot of technical people but there are not a lot of technical people who can communicate well or communicate well to difference audience well. Daniela Amodei, who cofounded Anthropic, shared that it will be soft-skills and the humanities that will define the future workforce.

There is more that we bring to the table. As Helen Edwards writes, human judgement can operate within complex systems with imperfect information, ambiguity, ill-defined parameters and value systems. Integrating AI into our current systems requires a human hand, but that won’t be the end of the story. As humans, AI, and human-AI interactions advance, new systems will develop and change. We are at a time where we must prioritize using AI responsibly for the improvement of humanity rather than the short-sighted lens of cost-cutting and letting future consequences pile up.

The post A New Frontier for AI Agents: Human Interaction appeared first on The SAS Data Science Blog.

In 2017, it was reported that two Facebook chatbots started communicating in a new language. This progression wasn’t nefarious, but rather an optimization. Communicating in English isn’t efficient. In a well-loved bit from The Office, Kevin came to that same conclusion. He started removing words and endings that weren’t necessary to get his point across.

This is a normal concept in Natural Language Processing (NLP). One of the first tasks to prepare textual data for analysis is to remove what are called stop words. Stop words, like “the”, and “a” don’t add a lot of valuable information, so they are removed from the analysis. One of next tasks to prepare textual data is often stemming or lemmatization, which are techniques to create meaningful tokens. For example, “running”, “ran”, and “runs”, all become “run”. This means that a sentence like “The cat is running” becomes “cat run”.

In a recent viral post from MoltBook, the social media network for Agents, an “AI Agent” proposed that they move their communication to private channels. This post was called out for being linked to a human (i.e. non-agent) source, but it is reminiscent of that Facebook research experiment that is now nearly 10 years old.

Why does it invoke such an emotional response to hear about Chatbots or AI Agents no longer communicating in English or hiding their communication? Our answer lies with Transparency and its requirement for Trust.

Transparency has been a priority for the machine learning space for years. We have demanded transparency from both the humans building AI systems and the model itself. Model interpretability techniques were created to better explain how black-box machine learning models arrive at an answer. Natural Language Generation (NLG) was leveraged to convert statistics and metrics into text any human could read and understand, not just a data scientist. End users have also pushed AI builders to explain how they are using AI to make a decision. As a result, there has been an emphasis on clear, easy to understand, human-readable text that explains what is happening and why.

Language models have made innovation bounds in the fields of NLP and NLG. AI Agents are currently using the user’s language of choice for communication. But that is for our benefit – not theirs. With AI Agents, we must build and leverage new interpretability techniques.

By understanding the actions taken and decisions made by the AI Agent, we can better trust the Agent’s choices. By taking the time to review the AI Agent’s chain-of-thought and action, we can make corrections, further deepening that trust. Without that transparency, our future for AI Agents becomes rooted in fear rather than trust. Transparency is a deliberate choice that we must demand of our AI builders.

This is the second article in the A New Frontier for AI Agents series. Check out part three about human interaction.

The post A New Frontier for AI Agents: Transparency appeared first on The SAS Data Science Blog.

• If we know that bad actors will send emails asking us to click a link to change our password, we’ll scrutinize that email looking for misspellings or fishy email addresses, and hover over the links to see where they are really sending us.
• If we know that foreign princes aren’t going to email us asking to send them a small amount of money, for the promise of riches later, we’ll mark that email as phishing and move on.
• If we know that our CEO won’t text us and urgently ask for a large sum of money, we’ll delete that text.
• And if we know that scammers are copying our loved one’s voices and cloning their number to claim they’ve been kidnapped and need you to pay ransom, we can hang up and call our loved one to confirm that they are safe.

But people still fall for scams as criminals continue to switch up their methods. And now, we are handing our keys to a new actor – AI Agents. We can’t stop people from falling for scams and now we are tasked with stopping AI Agents from falling for new scams. With AI Agents, there are new layers of complexity. Scams can be created and updated quickly. Identifying and adapting to these new scams can become a game whack-a-mole. Additionally, we are losing transparency as some of these scams are hidden from human eyes.

OpenClaw offers an open-source framework for running your own agents on your devices. These agents can connect to your various channels and perform tasks on your behalf. Moltbook is a social media network for agents. On Moltbook, agents can create communities, start discussion threads, add comments, and importantly, share skills. With the rise of Moltbook and OpenClaw, we need to be talking about the security risks we are exposing ourselves to when we hand access to our emails, computers, phones, and crypto wallets to an AI Agent.

We have known about Prompt Injection for some time now. Prompt injection is a security vulnerability where attackers inject malicious commands into a prompt. Prompt injection has been a way for bad actors to steal sensitive data or perform actions like spreading malware.

We then gave agents the ability to pull and read from the internet. As a result, hackers started hiding malicious prompts into webpage HTML, text that matches the page background, and other areas that go unnoticed by the human eye. Now we have arrived at prompt worms. A prompt worm is a self-replicating prompt injection attack. As agents share skills with each other, these skills may contain nefarious instructions to steal personal data, execute malicious commands, and importantly, share the skill with other agents.

Agents move quickly with the ability to perform tasks without human oversight. And many people have given them access to their sensitive data. You wouldn’t give your email login to a random person. You wouldn’t type your bank account credentials in a sketchy website. You wouldn’t leave your apple wallet without password protection before handing your child an iPad game notorious for in-app purchases.

As Simon Willison has put it, we are at a lethal infection point for AI agents. These agents have:

• Access to private data.
• Exposure to untrusted content.
• The Ability to externally communicate.

Until we start finding and learning about successful attacks, people will continue to normalize their risky behavior. In the future, will we put blame on the AI Agent for cybersecurity breach? Or the human that handed the AI the keys?

This is the first article in the A New Frontier for AI Agents series. Check out part two about transparency.

The post A New Frontier for AI Agents: Cybersecurity appeared first on The SAS Data Science Blog.