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.

Retrieval-Augmented Generation (RAG) has moved quickly from experimental AI architecture to a foundational enterprise capability. However, as organizations adopt RAG at scale, a new need has emerged: AI must be able to do more than retrieve information. It must be able to trigger workflows, interact with systems, produce structured outputs, and participate in real business processes.

The Model Context Protocol (MCP) is the technology that enables this shift. MCP allows large language models to interact with tools, services, and APIs in a secure, governed, and predictable way. With MCP server capabilities built into SAS Retrieval Agent Manager (RAM), we unlock a new class of retrieval agents capable of reasoning, retrieving, and taking meaningful action.

This blog explains how MCP enhances the SAS Retrieval Agent Manager and why this combination is a game changer in delivering safe, scalable, and operational AI for enterprises.

Why MCP matters for enterprise RAG systems

The Model Context Protocol defines a standard interface for how LLMs discover, understand, and call external tools. This addresses one of the biggest challenges in enterprise AI: how to make AI systems interact with live operational environments without sacrificing governance, safety, or clarity.

MCP gives AI agents:

• A list of tools they can safely use
• Clear schemas describing each tool’s expected inputs and outputs
• Mechanisms for executing actions through controlled tool servers
• Predictable failures, logs, and structured error handling
• A standard interface for integrating with enterprise systems

Instead of relying on long prompts or unpredictable natural language instructions, MCP gives agents explicit, machine-readable instructions about what they can do and how they should do it.

Inside SAS Retrieval Agent Manager, this foundation elevates agents from passive assistants to reliable operational agents.

What MCP Enables Inside SAS Retrieval Agent Manager

SAS Retrieval Agent Manager delivers strong agentic retrieval capabilities today, and MCP integration elevates it from providing insights to empowering agents that can act on them, bridging retrieval with real operational processes across the enterprise.

Turning retrieval agents into action agents

SAS Retrieval Agent Manager capabilities currently include:

1. Unstructured data processing & intelligent retrieval: RAM handles data ingestion, vectorization, and optimal RAG pipeline selection, enabling high-quality querying and reliable agent interactions over unstructured content.
2. No-code automation: RAM connects data sources, embeddings and agents through a drag-and-drop user interface to automate complex end-to-end workflows in a seamless and a consistent way.

By integrating MCP, RAM moves from insight to action, allowing agents to:

• Trigger enterprise APIs and service endpoints
• Initiate workflows and business processes
• Make database calls and automatically discover schema
• Update or query internal applications
• Perform multi-step tasks requiring tools and decisions

Strengthening governance, auditability, and trust

Enterprise AI must be safe. MCP ensures every action an agent takes is governed and traceable. Key safeguards include:

• Full observability for each tool invocation
• Transparent inputs and output schemas for every action
• Granular, role-based permissions that explicitly control agent tool access

This governance-first design aligns perfectly with RAM’s focus on trustworthy AI and evidence-based reasoning.

Scalable, modular architecture through MCP tool servers

MCP tool servers allow organizations to wrap internal logic, systems, or processes in reusable, discoverable interfaces. These servers can expose capabilities such as:

• Data lookups
• Business process triggers
• Internal system updates
• Metadata and knowledge services
• Custom decision rules or validation steps

Because tool servers are modular and standardized, they can be reused across many agents and teams inside RAM, reducing integration costs and accelerating development.

Performance and efficiency Gains

MCP allows retrieval agents to avoid overloading prompts with unnecessary context. Instead of embedding explanations of how to call an API, agents simply invoke a tool with the required structured parameters.

This leads to:

• Lower model token usage
• Faster task execution
• Predictable output formats
• More deterministic behavior
• Reduced risk of hallucinations

MCP improves both speed and reliability without increasing model size.

Enterprise-ready deployment options

SAS Retrieval Agent Manager supports flexible deployment in cloud, hybrid, or fully air-gapped environments. MCP tools follow the same model.

Organizations can deploy MCP tool servers:

• As containers from private registries
• As code-based lightweight services
• Behind secure firewalls
• With isolated secrets and environment variables
• Without reliance on external networks

This allows enterprises to operationalize RAG and agentic workflows even under strict regulatory or security constraints.

RAM powered by MCP: How it works

SAS Retrieval Agent Manager currently supports two primary categories of MCP tools enabling seamless integration with enterprise systems

Code-based MCP servers

These are ideal for small utilities, fast iteration, or department-specific automations. They provide:

• Simple configuration with environment variables
• Clearly defined input/output schemas
• Fast deployment and testing
• Easy adaptation for evolving requirements
• Low overhead for developers

Containerized MCP servers

Typically used for integrations with core internal systems and are perfect for high-scale or mission-critical integrations. Benefits include:

• Strong isolation and security controls
• Reuse across multiple teams and workflows
• Ability to package complex dependencies or language requirements
• Consistent runtime environments
• Support for enterprise container registries

The full workflow of how MCP Tools execute inside SAS Retrieval Agent Manager

1. Tool servers are deployed inside of RAM.
2. RAM ingests each tool’s JSON schema.
3. Agents analyze tasks and select the appropriate tools.
4. Tool calls are executed with structured inputs.
5. Responses, logs, and errors are captured.
6. The agent synthesizes the final grounded output.

This creates a unified flow where reasoning, retrieval, and action reinforce each other.

Use case for MCP in SAS Retrieval Agent Manager

Why MCP + SAS Retrieval Agent Manager is transformational

By integrating MCP capabilities, RAM evolves into a powerful agentic AI solution that is:

• Actionable: Agents can complete tasks, interact with systems, and generate operational outcomes.
• Governed: Every action is visible, logged, and governed by schema-defined protocols.
• Modular: Tool servers encapsulate logic into reusable, shareable integrations.
• Performant: Structured tool calls reduce latency and improve predictability.
• Deployment-Ready: The architecture works seamlessly across cloud, hybrid, or offline setups.

This combination enables organizations to shift from informational AI to operational AI turning insights into execution.

Conclusion

Integrating MCP into SAS Retrieval Agent Manager enables the next generation of enterprise AI, with agents that can retrieve, reason, and act. By combining structured tool execution, reliable governance, and flexible deployment, organizations gain a scalable and trustworthy foundation for operational AI. RAM’s MCP enabled retrieval agents go beyond simple workflows to automate real-world business processes, interact seamlessly with enterprise systems, and deliver consistent, explainable results that drive tangible business outcomes.

The post Unlocking agentic AI potential with MCP tools in SAS Retrieval Agent Manager appeared first on The SAS Data Science Blog.

The Artificial Intelligence (AI) era is here. To prevent harm, ensure proper governance and secure data, we need to trust our AI output. We must demonstrate that it operates in a fair and responsible manner with a high level of efficiency. As builders of AI, you need to not only trust your AI but also convince others to trust it as well, including:

• AI Regulators: Various agencies propose, adopt and enforce a growing number of AI standards and regulations across the global market. Penalties for non-compliance can run into millions of dollars.
• Consumers and end users: An ability to transparently explain the use and maintenance of AI solutions not only enables and educates your consumers, it shows them you care. It also projects confidence and capability. If your AI is transparent and trustworthy, AI Governance becomes a competitive advantage.
• Employees: Top talent demands governed and trustworthy AI. No one wants to build tooling that hurts others.

Data is central to AI, so the first step in building trust in your AI and AI Governance is to establish trust in your data. Organizations face privacy, compliance, and data robustness issues in trusting their data.

Preserving Privacy & Compliance

Organizations have a duty to protect private and sensitive information in their custody. This includes Personally Identifiable Information (PII), which is any data or combination of data values that can be used to identify a person. Failure to protect PII can lead to fines and loss of trust.

Personally Identifiable Information (PII) is any data that can be used to identify a specific individual, either directly or indirectly, including: names, email addresses, Social Security numbers, and addresses, but also sensitive data like health records or financial information.

Unfortunately, you can’t simply remove all personal characteristics from your data. Interesting relationships between individual characteristics and outcomes might add value to your analysis. For example, in health care, symptoms of a heart attack differ between men and women. Removing sex or gender from your data hides a key insight that saves lives.

To retain this information, organizations tend to follow practices such as anonymization or masking of other identifiable characteristics. But those practices tend to be weak forms of anonymization because a combination of traits like sex, race, zip code, or age, when used together, can still identify an individual.

Building Representative & Robust Data

Improving the generalizability of machine learning models helps build a more accurate model and requires training data that represents the wider population. Accuracy is important because incorrect predictions by your model can result in tangible costs that may include potential revenue loss, increased operational expenses, or adverse impacts on users.

You need data for testing in addition to training a model. Test data should enable rigorous tests of a trained model against edge cases and potential scenarios so that you can adjust your model accordingly. Robust test data should include previously unseen values, extreme values, and data quality issues than can be expected in real data such as missing values. For example, when you buy a car, you hope the auto maker tested that model in all conditions—snow, rain, heat, sharp turns, sudden stops, city streets, and highways—to ensure reliability. Similarly, you need accurate data to rigorously test your models.

Synthetic Data for Trustworthy Data

Synthetic data can mimic patterns found in real world data while reducing privacy concerns by minimizing data leakage risks. This can reduce the risk of penalties or loss of trust while enabling model development and research. This is also helpful when real representative or comprehensive data isn’t available. It’s fast and easy to generate what you need.

Using a representative training data set to build your model or AI system means more accuracy in production. Using a robust testing data set consisting of edge cases, extreme values, and unseen conditions can help you understand and address where you model or AI fails before it’s used to make business decisions. Synthetic data can be used to generate cost-effective sets the protects sensitive information yet still mimic real-world patterns.

To help organizations and data science teams generate high-quality synthetic data for any scenario, SAS recently released SAS Data Maker. SAS Data Maker is a low-code/no-code tool for generating high-quality synthetic data that mirrors real-world data sets. It lets you augment existing data or create entirely new data sets, reducing the cost of data acquisition, protecting sensitive information and accelerating AI and analytics development. SAS Data Maker is available globally in the Microsoft Marketplace with consumption base pricing so teams can start generating trusted, representative and production-ready data fast. To learn more about SAS Data Maker, check out this short demo.

In short, synthetically generated data can build more representative and robust data while also protecting your data, which leads to improved security and more accurate modeling against your target population. Better security and better models mean better AI Governance. This all means stakeholders and users can trust your AI systems.

Learn more

• Make a Difference With SAS Data Maker
• There is yet another AI productivity gap
• No one wants your AI Slop

The post AI governance in practice: How synthetic data prepares you for what’s next appeared first on The SAS Data Science Blog.

Earlier this year, research from MIT found that 95% of GenAI investments have a 0% return on investment. When you take into consideration that the enterprise investments into GenAI projects have been to the tune of $30 - $40 billion, you realize just how much money gets thrown into GenAI haphazardly. MIT has called this new gap “The GenAI Divide.” I call it “Yet Another AI Productivity Gap” or YAAPG for short.

But within the YAAPG, there is a paradox. Personal GenAI tools are improving personal productivity. Anthropic recently reported that Claude says it speeds up individual tasks by about 80%. Yes, Claude, the LLM. The LLM that also said that it could deliver products in person at one point, so I won’t fault you if you take Claude’s statements with a pinch of salt. Yet, when used thoughtfully, many individuals report productivity gains from GenAI. Power users understand how to use GenAI in their personal work to create value and avoid AI Slop. In fact, All Things Open released a whole guide that features tips and use cases for improving personal productivity using GenAI.

As we look across the GenAI Divide, what prevents organizations from seeing a return on their investments? Is it poor data processing capabilities? Is it GenAI systems that can’t learn? Is it a lack of trust in these systems? Is it a lack of AI Governance? Or is this just the same problems we’ve always seen when organizations are operationalizing AI? And what can we learn from personal productivity gains?

Lessons from Russian Novelists

In the opening line of Anna Karenina, Leo Tolstoy wrote, “All happy families are alike; each unhappy family is unhappy in its own way.” This led to the Anna Karenina principle in that success relies on several key factors coming together correctly, and failure can occur in any number of ways. Operationalizing AI requires a lot of things being done correctly.

All happy families are alike; each unhappy family is unhappy in its own way.

And when we look at power users of GenAI for personal productivity, they’re often doing several things right. First, they know what problem they’re trying to solve. Second, they understand the benefits of solving that problem. They find the right tool for the problem, make adjustments to the tool, and understand how to feed their inputs to that tool. They observe the outputs, judge their quality, and make adjustments. They’ll try new things, learn how best to work with the tool, and trust their usage of the tool.

Let’s start with a personal productivity example to demonstrate those points. Many people use generative AI tools as coding assistants. These assistants may write comments to document code, answer questions, debug problems, suggest changes, write unit tests, and more. Each time a software developer uses their coding assistant, they use it to address a specific problem — and they understand the time-saving benefits of the tool. Software developers may be limited to using the tools their organization purchases, but these tools are often vetted and provided context through the organization’s code base. The input to the tool is often just the developer’s questions and relevant code. Importantly, the programmer is in the loop. The software developer sees what the coding assistant suggests, determines if it is satisfactory, and either approves it or makes adjustments. And, over time, the developer learns the ins and outs of using the coding assistant. The programmers begin to understand how they can ask better questions or create better prompts to get more satisfactory answers from the coding assistant. Through this experimentation, the software developer learns how to better use the GenAI tool, and not just trusts the tool, but trusts their use of the tool.

Scaling to Enterprise Problems

How does this scale to enterprise projects? First, before any project starts, you should know what you’re trying to accomplish. Many organizations see GenAI as a hammer where everything is a nail. I’ve spoken with individuals across organizations that were tasked with creating a project where they could use an LLM, GenAI tool, or Agent. An indiscriminate use of AI does not create ROI. A better approach would be to find a pain point or something the organization can do better. If you don’t know what your pain points or gaps are, ask. Employees, customers, or users are a great place to start.

By having a clear problem to solve or an outcome you’re trying to achieve, you can next state the benefits of solving that problem. If you can prevent customers from abandoning their carts in your online store, you can increase your revenue. If you can help customers answer simple questions or perform basic tasks using an online chatbot, you can give your employees time to work on more productive tasks, improving output. Now that you know the benefit of solving the problem, you can create a metric to measure project success. At this stage you can estimate if this problem is worth solving by weighing the expected benefit against the estimated costs.

If you’re ready to move forward, now you need to find the right tool for the job. Sometimes this is a shiny new AI tool, but sometimes it’s just an ETL pipeline feeding to a dashboard. Sometimes you need to look at the simplest solution that will get the job done. AI is more expensive and less predictable than business rules and code. If this problem truly is best solved using AI, next determine which AI tool is best for the job. There are many choices among AI tools with options like building in-house, getting access to a generalized model, acquiring a model fine-tuned for a specific task, or even getting a tool that wraps a model and other enhancements. Here you have to weigh the purchase cost, hosting costs, and employee time to implement the tools, with the expected benefit of the model towards the task.

Before you can productionalize your new tool, you need to understand and set up the downstream processes that feed data to the tool and upstream processes to monitor and observe the tools outputs. For some use cases, the user will provide their prompts or questions directly to the tool. In others, the tool may be operating as a part of an automatic pipeline. In that case, your organization may provide the tool access to a variety of documents, data files, or a fine-tuned specific prompt. Additionally, if any information is collected from a user, you may need to clean that input to remove instances of Personally Identifiable Information (PII), Intellectual Property (IP), toxic input, or attempts of prompt injection.

Beyond downstream data, the tool’s outputs should also be monitored, with guardrails in place to evaluate, approve, reject, or adjust outputs from the GenAI tool. Again, you want to ensure that the tool doesn’t return PII, IP, or toxic responses, but you may also want to review if the response is formatted correctly, is on task, and references accurate information. If a response has a flaw, perhaps there is logic to provide why the response was incorrect and let the GenAI tool try again. Downstream and upstream processes can be performed manually, as a part of an automated pipeline, or as a hybrid approach where manual intervention can take place when specific conditions are met. But before investing into a GenAI project, it’s important to have some idea about the level of effort to integrate the tool into a wider production pipeline.

Finally, you should encourage teams to experiment with their tools in a responsible manner. By having a safe space to experiment, teams can learn, see what works, see what doesn’t work, what can be adjusted in their user input, report problems, and trust their usage of the tool to improve outcomes for the organization.

Conclusion

In conclusion, before enterprises can see ROI on their GenAI investments, they must master the following:

1. Know what problems they’re trying to solve
2. Understand the benefits of solving that problem
3. Find the right tool for solving the problem
4. Know their data pipeline
5. Monitor, observe, and adjust outputs from the tool
6. Experiment, learn, and trust their usage of the tool

Traversing the GenAI divide will take a deliberate and thoughtful approach to solve a real problem rather than an indiscriminate use of AI.

The post There is yet another AI productivity gap appeared first on The SAS Data Science Blog.