Agentic AI workflows

 Agentic AI Design: Why Workflow & Agent Patterns Matter

Agentic AI is changing the game but success is not just about using LLMs. It is about orchestrating them with the right patterns. Frameworks like LangChain and LangGraph make this possible, but understanding these patterns is critical for building scalable, reliable AI systems.

Here are 6 basic foundational patterns every AI practitioner should know:

✅ Prompt Chaining
Break complex tasks into smaller steps.
Example: Summarize → Extract insights → Recommend actions.
Use when: Multi-step reasoning is needed.

✅ Parallelization
Run tasks concurrently for speed.
Example: Fetch weather, stock prices, and news simultaneously.
Use when: Tasks are independent and need better performance.

✅ Orchestrator-Worker
One agent plans, others execute.
Example: Orchestrator assigns marketing copy tasks to sub-agents for tone, SEO, visuals.
Use when: Complex workflows need coordination.

✅ Evaluator-Optimizer
One agent critiques, another improves.
Example: Draft blog → Evaluator checks tone → Optimizer refines.
Use when: This is a good candidate for Quality-sensitive outputs.

✅ Routing
Direct queries to the right chain or agent.
Example: “Weather in London?” → Weather agent; “Stock price?” → Finance agent.
Use when: Useful in Multi-domain apps.

✅ Agent Pattern
Autonomous agents with memory and tools.
Example: A travel agent that books flights, hotels, and suggests itineraries.
Use when: Tasks need autonomy and adaptability.

💡 Tip: Start simple with prompt chaining, then layer in routing and orchestration as complexity grows.
Here summarizing the above foundational patterns for clarity:

Prompt Chaining → Sequential steps
Parallelization → Concurrent tasks
Orchestrator-Worker → Supervisor delegating tasks
Evaluator-Optimizer → Critique and improve
Routing → Direct queries to correct chain
Agent Pattern → Autonomous agent with memory and tools

Tip: It’s essential to learn these foundational patterns first before moving to advanced patterns like ReAct, Reflexion, and Tree-of-Thought, which enable deeper reasoning and adaptability.

Okta - Salesforce Single Sign On Integration

 Hi

We will be integrating the OKTA SSO with Salesforce application for Single Sign On & MFA solution. 

1. Create your Salesforce free trail account. (You can also use your licensed version of Salesforce to Integrate. The steps are same.)
2. Login to https://login.salesforce.com/?locale=au & Click on Try for Free Button. Fill out the form as per your details. 
3. You will receive the Activation Email to activate your account & reset the admin password. do as per steps mentioned in that Email. 
4. Now Click on the setup Icon on the Top Right corner (Near to your Profile). 

1. In the Setup configuration, Goto ---> Settings --->Single Sign On Settings (from the Left side navigation bar)

1. In the Single Sign On Settings, Click on the Edit Button & Enable the SAML as SSO.  You can optionally "Disable the direct login with Salesforce Credential" once the SSO is setup.  Save the settings. 

• To Add the SAML SSO click on the New button. Enter your OKTA ORG IDP details as shown below.  
• Name: Enter a name of your choice.

1. SAML Version: Make sure this is set to 2.0. This should be enabled by default.

• Identity Provider Login URL: Login to your OKTA & get this value from the IDP Metadata. 
• Entity ID:  If you have purchased the custom domain, then Use, use https://[customDomain].my.salesforce.com
•  If you do not have a custom domain setup, use https://saml.salesforce.com
• API Name: Enter an API name of your choice.
• Identity Provider Certificate: Get the IDP certificate from your OKTA Idp Metadata. Save it in a file locally & upload the File. 

Note: The Custom Logout URL  & Custom Error URL is optional, you can specify if you wish to customized. 

Single Logout Enabled: Use this settings only if you wish to have SLO enabled.  

The final settings should like like as shown below. 

Note: Select the SAML Identity Type as "Assertion contains the Federation ID from User object" as shown above. 

• If you wish to Enable the Provisioning also, select the checkbox as "User Provisioning Enabled" In the Just In Time Provisioning section. 
• Finally Click the Save Button. It should save the SAML settings as shown below. 
• After Saving the metadata, Click on the "Download Metadata" button & Save the Metadata file locally on computer. 

• Now Login to your OKTA ORG & Click on Add Applications. Select Salesforce from the search Bar as shown below.  Click on the Add Button on the Left hand side. 

• If you are using Trial version of salesforce then, select the Instance Type as Production as shown below.  Click Next Button. 

• In the Sign On TAB, Go to Advance settings as select "Use Fed ID for SAML" to NO. 
• Provide the Login URL of salesforce from the Salesforce Metadata file. It is actually the Assertion Consumer Service URL in Metadata.  
• As we don't have any custom domain, then Click of Save/Done.  

For the Multifactor Settings, Click on Add Rule as choose the option as per business requirements. 

• Now go to the Assignment TAB & assign this application to People/Group as shown below. 

• Since we have not Enabled the User Provisioning spo we have to create the User Profile in salesforce manually. 

Note: OKTA doesn't support user provisioning with the Trial version but it does support provisioning with Licensed version. It is highly recommended to use User Provisioning with Licensed version. 

• Go to your Salesforce account & click on the User TAB in the Administration section. Add the New User which you have assigned the application in OKTA as shown below. 

Test your application.  Thanks a lot !!!

Okta MFA Push Authentication on Microsoft Remote Desktop Gateway

Okta MFA Push Authentication on Microsoft Remote Desktop Gateway

 I've successfully implemented this using code from Github linked in this Tutorial.

All credits of the code go to the Code Author! This is simply a guide on how to implement this in your environment.

A few things to note before we head down this path:

1) This will only allow for PUSH authentication on the RDG Gateway. I know that RDG Gateway Web Apps portal supports SSO/SAML, however, once the user has access to the RDP file of the application, MFA no longer is required as they can just launch this from their desktop and connect without authentication. In my opinion, this is a FLAW from microsoft.

2) This is somewhat of what Azure or Duo integration for RDG Gateway does, however, as the Remote Desktop client doesn't have any inputs, it doesn't support Call-in or SMS as there is no input fields for the application to submit back data.

Let's begin! 

Github code is found here: https://github.com/bdalpe/RADIUS-to-Okta-MFA

Download the ZIP and save it to a Linux server/system. (You can do this in Docker but I haven't done it). You will need to open ports 1812-1813-1814 inbound and outbound, and 8080, 80,443 and 8443 outbound. (Or you can be lazy and disable the firewall)

Now in terminal, change to the directory of the zip file, extract it, and work in that directory.

Edit the file run.sh using gedit or vi or your favorite flavor of linux editor.

*!/bin/sh

export OKTA_TENANT=yourtenant.okta.com -> Simple, put your okta tenant

export OKTA_API_KEY=XXXXXX -> In Okta, Navigate to Security > Api > Generate Token. Put that value in here.

export RADIUS_SECRET=****** -> Put whatever complex thing you wish here, this is just used to communicate to your NPS server on the RDG Gateway server.

p=$(which python) -> Change this to p=$(which python3) because you should be using python3 in linux in 2020.

$p server.py

Save this file. This is all you have to do.

Back in the command line, run the following command.

pip3 install -r requirements.txt

You will see stuff installing, that is a good thing. If you don't, then install pip3 with yum or apt-get, whatever linux you are using.

Once this is completed installing, just run the command /bin/sh run.sh and leave the terminal open. It will be blank, and you will see nothing.

RDP to your RDG Gateway server, find "Remote Radius Server"

Right click and Create New. Call it OktaRDG or something similar. Add the Linux server's IP Address where you put the script and hit Apply.

Click the OktaRDG object that you just created and click Edit.

Navigate to the second tab and where I pointed the arrows, put in the SAME secret which you put in the run.sh configuration file in the step above.

Under Load Balancing, Change the settings so they look exactly like the ones in the screenshot. This makes it so that a user has 30 seconds to hit the Yes its Me! push on their mobile device before the server drops the attempt. 

Click Okay.

Now, to enable this policy on the Microsoft Remote Desktop Gateway, you will have to navigate to "Connection Request Policies" on the NPS server. 

Create a new one by right clicking and pressing "new".

For General, Makes sure you choose the remote desktop gateway:

(PLEASE DISABLE THE POLICY FOR NOW UNLESS ITS ON A TEST SERVER)

For conditions, put in NAS Port type as VPN which will target ALL Rdp connections. (Or customize them as you wish) 

Under settings, leave everything blank except for the following: 

Forward your requests to the Remote Radius Sever group which you created: (I have called mine as Okta-RDG) 

Under Specify a Realm Name, you must do the following:

Change the Attribute field to User-name, and then MAP each AD-user to Okta account that you need to authenticate.

For example, see transforms below:

The employee's name is John Snow. His username is jsnow.

The user normally logs into the gateway with domainname\jsnow.

In the mapping, you will put in Find:jsnow - Replace With: john.snow@domainname.com

In my example, he logs in with company\jsnow, and his Okta login is john.snow@company.com, so I have made the mapping.

This will work for any mapping! If your users log in with domainname\john.snow, you will Find:john.show - Replace With: john.snow@domainname.com

You can also map random domain accounts to any okta token. Let's say you have a vendor service account, called domainname\vendor3511. You can make a rule to target an okta account for that vendor with the email of cool.vendor@company.com

You can create a rule of Find:vendor3511 - Replace with: cool.vendor@company.com

VERY IMPORTANT: Keep this rule disabled until FULLY TESTED. Once you enable the rule and make it the top priority, ANY connections to this Remote Desktop Gateway server will be forced to use multifactor. They will be re-authenticated ANY time they try to RDP using an RDP file that has this gateway server and the policy enabled.

Please let me know if you have any questions.