For many users, these skills, running locally on individual machines, are considered “agents.”

In reality, many of these are closer to AI-powered workflows than enterprise-grade agents. While they excel at automating operational activities, they often lack centralized governance, orchestration, observability, and lifecycle management.

As a result, organizations face agent and skill sprawl, along with a growing challenge: how to govern an increasingly fragmented landscape of local skills, cloud-hosted agents, AI applications, and non-human identities.

This post outlines three AI workflow orchestration patterns of increasing maturity that organizations can adopt as they progress through their agentic journey.

Pattern 1: MuleSoft “Between”

Here Claude or ChatGPT serves as the primary engagement surface. These AI apps also orchestrate with tool calling via MCP or APIs to backend systems, while workflows are encapsulated as local skills or plugins running on user devices.

These local skills provide flexibility and a low barrier to entry. Users can rapidly build and customize workflows to suit their needs.

However, the tradeoff is governance.

Because the skills reside on local machines, they are difficult to centrally manage, can be modified by users, and often lead to inconsistent implementations across teams.

In this pattern, MuleSoft Omni Gateway can sit in between the engagement layer and enterprise apps, providing:

• Governance of backend access
• Security controls
• Policy enforcement
• Trust boundaries
• Visibility into tool usage

This creates a safer foundation while still allowing users to leverage local AI-driven workflows.

Pattern 2: MuleSoft “Around”

The second pattern extends the first by shifting portions of the orchestration logic into the MuleSoft Agent Broker, a key component of the centrally managed Agent Control Plane.

Now, workflow/orchestration logic exists in both places:

• Local AI applications continue to provide user-driven workflows and flexibility
• A centrally managed broker orchestrates more critical business processes

The broker effectively sits around enterprise tools, providing orchestration, governance, control, and visibility.

Unlike local skills, centrally managed workflows cannot be modified by individual users and are governed consistently across the organization.

This hybrid model is particularly useful during transition periods when organizations need to support both employee-created workflows and enterprise-managed automations.

For example, an employee might use a personal AI assistant to prepare a customer briefing, while a centrally governed workflow handles approval processes, compliance checks, and updates to systems of record.

Organizations gain flexibility without sacrificing control.

Pattern 3: MuleSoft “Over”

In the most mature pattern, orchestration is fully centralized, no more local skills.

A broker or orchestration platform owns the coordination of tools, workflows, and managed agents. Engagement channels become interchangeable interfaces rather than the source of orchestration logic.

Users can interact through:

• Slack
• Claude or ChatGPT
• Custom applications
• Internal portals
• APIs

Regardless of the entry point, orchestration remains centralized.

This approach provides:

• A single point of access
• Consistent business logic
• Centrally governed workflows
• Full visibility
• Enterprise-grade security and compliance
• Coordinated multi-agent execution

This is where true multi-agent orchestration emerges, with agents, tools, and workflows operating under a centrally managed control plane rather than as isolated, disconnected implementations.

The Path to Governed Orchestration

These three patterns represent stages of maturity and are not competing architectures.

Many organizations start with local AI skills because they are fast, accessible, and deliver immediate value. Over time, governance, security, consistency, and scale become increasingly important, driving a gradual shift toward centrally orchestrated workflows and managed agent ecosystems.

The key is recognizing where you are today and building an architecture that allows you to evolve without forcing a complete redesign.

The future is unlikely to be entirely local or entirely centralized.

Instead, successful organizations will strike a balance between user flexibility and enterprise governance, creating a clear path from AI-powered workflows to orchestrated multi-agent systems.

Special thanks to Chuck Hirstius, Distinguished Solution Engineer at MuleSoft, for the technical leadership and architectural thinking that shaped the Between, Around, and Over maturity patterns described in this post.

From Local Skills to Governed Orchestration: Three Patterns of Agentic AI Maturity was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the ever-expanding software application landscape you may not find an out-of-the-box Connector for your favorite application. Not to worry…

This post will walk you through how MuleSoft enables connectivity with any and all applications — with or without Connectors.

For simplification, let’s divide the application landscape along two axes and four quadrants — application category (modern and traditional) and usage (common and niche):

• Modern applications are cloud/SaaS based that typically expose individual APIs or complete API specifications.
• Traditional applications are mainly on-premises and could use SOAP service, messages, files, SDKs, or some legacy approach for integration.

With the above context let’s see how MuleSoft supports integration with modern and traditional applications in common and niche cases.

1. Common modern applications

For commonly used modern applications (top right quadrant), the MuleSoft Anypoint Platform provides out-of-the-box Connectors. The benefits of using Connectors include reduced code complexity, simplified authentication, inferring metadata, and easier code maintenance.

Example Connectors for modern enterprise applications include: DocuSign, Salesforce, Workday, and Zoom and for infrastructure services include Azure Data Lake, Amazon S3, and Google Pub/Sub from major cloud providers. Browse MuleSoft Exchange for the full list.

There are four categories of Connectors — Premium, Select, MuleSoft Certified and Community; see description and support policy for details.

Typically Connectors in this quadrant fall under Select category that are included as part of the Anypoint Platform subscription.

2. Common traditional applications

Similar to modern applications, MuleSoft Anypoint offers Connectors for commonly used traditional applications including SAP ERP, Oracle ERP, IBM CICS, and Microsoft Dynamics. In addition, Connectors are also available for common standards like X12, EDIFACT, AS2, and HL7.

One key difference compared to the modern category is some (not all) Connectors in this quadrant fall under the Premium type requiring an additional license.

See link for list of Premium Connectors.

3. Niche modern applications

While Connectors are a great way to integrate with your applications MuleSoft may not have a Connector for your favorite application.

When there is no out-of-the-box Connector available you can use one of the two options: a) Connector Generator and b) HTTP Connector.

The Connector Generator, as the name suggests, generates an Anypoint Connector from an API specification in OAS (aka Swagger) or RAML format. The Connector can then be downloaded into Anypoint Studio and be used to connect to the target application.

Several vendors publish API specification for their applications making it easy to consume. For example, Avalara AvaTax and Pricefx publish OAS specifications. If the vendor doesn’t provide then you can write an OAS/RAML specification for the operations you are interested in which can then be used to generate a Connector.

Using the Connector Generator is easy; just upload the API spec into Anypoint Design Center and publish it to Anypoint Exchange. Now from Exchange you can browse all the REST API operations, view documentation, and download a Mule Connector as seen below. See the documentation on REST Connector Generator for further details.

The second option is to use Anypoint HTTP Connector to call the individual REST APIs directly; typically application vendors document APIs in a Developer portal if they are not publishing the OAS specification.

4. Niche traditional applications

This fourth quadrant represents niche legacy applications that doesn’t expose APIs. Such applications typically provide one or more approaches for integration including SOAP-based web service, file, message, database call, or script (to call a function) and MuleSoft has Connectors for all of these approaches.

For instance, Mule Scripting module enables the execution of custom logic written in a scripting language, the Java module for integrating with custom Java code, and Microsoft .NET Connector enables the execution of native .NET code.

Can I create my own custom Connector?

Yes, you can if none of the above options work and you have a special case.

The REST-based and traditional integration approaches work fine for application-oriented use cases but infrastructure services like AWS S3 or Google BigQuery will require more nuanced integration for file and network management or for performance optimization. For such cases, Java-based connectors work much better and Mule SDK for Java enables you to create a custom connector. See the list of certified connectors published in Exchange by the MuleSoft implementation partners.

Conclusion

MuleSoft Anypoint Connectors are a big part of enabling application connectivity to deliver with speed and agility. MuleSoft Exchange provides 250+ connectors for commonly used modern and niche applications.

When a Connector is not available for your application there are options including Connector Generator, calling REST APIs using HTTP Connector, or building your own custom connector. With a wide range of options MuleSoft enables you to connect to any application rapidly and create innovative solutions.

MuleSoft Connectors and beyond: Enabling connectivity with a variety of applications was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Commerce platforms — past, present, and future

Today, I listened to the Jason & Scot Show Episode 270 — Microservice based commerce platforms with Kelly Goetsch, an insightful podcast on a topic that is near and dear to my heart.

The podcast touched on the past and current trends around the [enterprise] Commerce platforms; I believe it is evidence to the thesis that

Business used to drive technology but now technology is driving the business.

Thanks, Kelly for sharing your expertise and Jason & Scot for covering this important topic.

Below are my three key observations:

1. Commoditization: Commerce platform core features are unbundled, commoditized, and available as modular building blocks (think Legos) in a SaaS model. This allows retailers to choose best-of-the-breed components off the cloud and combine them with their brand secret sauce to compose unique shopper experiences i.e., composable commerce. This is the present state, but how we got here is #2 below.

2. Packaged application to components

• The enterprise Commerce platform market was essentially a three-horse race between IBM, Oracle, and SAP hybris roughly till 2015, give or take (and I was fortunate to be riding two of them during their glory years.) These platforms are packaged applications with guard rails and require SIs to customize and implement brand-specific processes. Several large retailers in the Internet Retailer Top 500 list drove billions of dollars in GMV each year. The platforms were successful but their time has come.
• The cloud happened! There is an old saying in the cloud world —

Either you’re born in the cloud or not :)

• Very few software platforms successfully made the transition from on-premise to cloud.
• The cloud revolution was followed by microservices, APIs, headless, and now composable. The platform capabilities got decomposed into API-first, stateless and scalable components following MACH principles which are built bottoms-up by several newer Commerce platforms and component vendors that specialize in one thing really well that is antithetical to the notion of platform as offered by the enterprise vendors.

3. Competing on architecture, not on capabilities

• The newer platform/component vendors are now competing on the underlying architecture vs capability. This is an important shift! In my view, this is the shift of power from CMO to CTO and a driving force behind the above two points.
• Online commerce is roughly a 20-year-old market with most of the features and processes well-defined to be commoditized. The idea of cart, catalog, content, campaigns, payments, returns, and so on are commoditized and are not expected to change. What will change though is how they will surface in the shopper experience and where it will interface with the backend business processes enabling retailers to innovate new experiences rapidly. Naturally, the focus now is on agility and not on functionality.

Now, where this is all going is even more interesting. With major cloud vendors already offering some of the Commerce components, it may not be surprising if they expand to offer full platform capabilities.

In the early days of Commerce, retailers built custom applications, then came enterprise platforms, and now retailers into “composing” custom platforms but using well-defined, off-the-shelf SaaS components. The cycle reminds me of the following quote by T.S. Eliot,

We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time.

A 250 year old British auction house sold digital ownership i.e. Non-fungible Token (NFT) to a collage of 5,000 digital pictures for $69M. The digital was created by a random artist in North America and bought by a South Asian dude. And when America’s longest running TV show CBS 60 minutes features that story, you know what the average Joe is thinking. “How can I create and sell my own NFT?”

Are retailers and consumer brands riding the trend?

Read on for some analysis, business benefits, examples, and a 1-min demo video.

The non-fungible what?

First, what is a token? A bunch of numbers that uniquely identifies a digital asset. For a good intro, see these posts on NewStack and CNBC.

Second, what is fungible (interchangeable) about these tokens?

Let’s talk business

Now that you are an NFT expert, let’s see why a Retail or Consumer Goods brand should care.

NFT offers the following useful attributes around marketing and selling:

Two attributes stand out — Marketing currency and Programmable.

Marketing currency

NFT is without a doubt a new marketing currency. Yes, the hype may fade, but there is a good possibility that the concept of digital ownership will survive.

What is fascinating about NFTs is that it could be both a product and a marketing tool.

The product is a digital asset that encapsulates some form of creativity or a moment in time. The idea of owning digital (bragging) rights to that moment is marketing on its own.

See example below before you think I am crazy!

Programmable

For techies, this idea of programming via Smart Contracts opens a world of possibilities.

Smart Contracts make NFT dynamic, monetizable, and serendipitous.

For example, you could tokenize your 1969 Mustang and give driving rights to token owners for a day at random. No, I didn’t make this up on the spot.

Another good example is Two Degrees — an NFT that will self-destruct if global temperatures rise 2°C. Ouch, that’s ironic in the context of crypto energy use and global warming.

Are brands dropping NFTs?

You bet!

Today, you can buy Nike shoes you can’t wear, tacos you can’t eat, and Pringles you can’t bite.

Just Food published an article titled, Why NFTs can offer marketing opportunities for FMCG brands where they discuss ideas on how brands can leverage NFT pheno-mania.

NFTs essentially offer three areas of utility for CPG brands: as part of overall long-term brand building (marketing); for short-term promotional use (promotion); and to generate immediate awareness for a company and its brand.

Just Food — Why NFTs can offer marketing opportunities for FMCG brands

What does a good NFT look like?

NFT is about creating buzz…I mean creating unique value that resonates with the brand, timed for market events, and that which makes it stand out. Then make it digitally scarce, i.e. mint only limited copies of it. For example, if you sell apple pies, limit it to 314 to make it subtly meaningful, or not.

To get immediate attention you have to be a brand, a celebrity, an artist, or an innovator (e.g. solve world hunger, cure cancer).

Brands have an easy start — they have both market awareness and an audience. All they have to do is redirect their marketing prowess to creating digital assets.

Timing is key. One great example is Charmin toilet paper NFtP.

Here is the excerpt from the Just Food article:

Now, did you notice the above excerpt starts with, “The NFT must make sense.” Not sure I agree, as it can limit creativity.

Another good example is CNBC’s Haines Bottom that sold for $61,000. It’s a short video clip of Mark Haines calling the market bottom during the 2009 stock market crash.

The key attribute of a good NFT is the ability to capture an important message or moment in history.

To memorialize moments, mint NFTs!

I think that is a cute line, can I NFT that? Well, not so fast, I ain’t no celebrity

But what if you are a celebrity?

Well, then anything goes, mostly. You can literally state a fact like “Time is irreversible” or draw a picture and create an NFT out of it.

On a serious note, one great example is VeeFriends by Gary Vaynerchuk: “the main ambition of this project is to create meaningful intellectual property and create an extraordinary community. All tokens are a three-year admission token to VeeCon, an annual super-conference.”

Gary, a social marketing guru said,

“I know that NFTs will be here for the rest of my life.”

Gary Vee

If you are still not bought into NFTs…

Check out this $50 painting at Etsy which comes with a NFT to prove authenticity. If you are asking, “What do I do with this NFT,” it is the wrong question.

The point is, the market is willing to buy, and now the question is, are you selling it or not?

So should brands create NFTs?

Absolutely!

NFTs are

• New marketing currency
• Product + marketing medium
• Useful to create brand awareness
• Important to attract newer demographics (crypto gen…is that thing?)
• Inexpensive and no supply constraints
• Limited only by creativity

So what are you waiting for? Go forth, and mint-away!

How about a demo?

This 1-min demo video provides a simple NFT ownership experience.

For the techies, here is how I implemented it.

If you’re wondering how to connect your Web 2.0 application to Web 3.0/DApps, MuleSoft can help as we connect anything and change everything.

A recent blog post on navigating financial uncertainty with connected digital banking offered three guiding principles that will empower banks during this trying time. Of those three, the first principle is to leverage API-led connectivity to digitize and scale lending operations.

In this post, we offer a solution to an example use case in support of that first principle. The example highlights the benefit of APIs to rapidly integrate disparate systems and the power of artificial intelligence (AI) in automating mundane tasks to accelerate the lending process.

Sample use case: The loan application

Let’s take the SBA loan application process. According to the Small Business Administration site, the life of an SBA loan has 17 steps, many of them require some kind of document processing and verification. Specifically, the front-end of the process, loan origination step, involves handling various forms and documents. For example, the PPP application requires 12 different documents including proof of payroll, ownership (Schedule K-1), rent, utility bill, and so on.

A simplified workflow of the loan application process is as follows:

• The loan applicant fills the web form on the bank’s site then uploads/email various documents.
• The uploaded documents typically are stored in some kind of cloud storage solution, like Box or an email server, in the case of emailed documents.
• The staff extracts, reviews (e.g. validate for local jurisdiction requirement and regulation), and saves the documents along with the customer record in a CRM system, like Salesforce.
• The officer then validates the document, evaluates risk, and submits the application to a back-end system for underwriting and decision.

While some of the workflow steps — like risk evaluation and decision making — may require loan officer intervention, most of the other steps involving document review and validation can be automated which the majority of lenders perform manually today.

How do we scale this process quickly? The volume of applications makes it impossible to scale with manual operations. The number of different systems involved in the process makes it hard and time-consuming to automate the process using the traditional point-to-point integration.

A better and strategic approach to integration is needed where we use consumable building blocks (i.e., APIs) representing various process elements that can be composed (as opposed to building from scratch) to serve the dynamic business demands i.e., an API-led approach.

Composing the process using APIs

Now let’s take a section of the loan application use case and apply an API-led approach to compose the process steps below. The APIs supporting the following steps are available in the Github project.

The API-led connectivity uses a methodical approach to connect data to applications through reusable APIs promoting consumption and self-service.

The first step is creating a system layer to unlock access to key applications. Here we use out-of-the-box connectors for Box, Salesforce, and the MuleSoft REST Connect to access data without worrying about the complexities of the underlying systems. The result is a set of reusable building blocks that can now be consumed over and over and composed into different business processes.

The second step creates the middle layer, also known as the Process Layer, that uses the System APIs to compose the following two processes:

1. Document management Process API to extract and attach the loan documents uploaded from cloud storage to the corresponding account record in the CRM or a Content Management System (CMS).
2. Document validation process API to automatically transform the document from a PDF or image format to machine-readable data using GLYNT, an AI solution. Then the data can be processed, validated against the business rules, and submitted to the Loan Origination System.

The Process Layer APIs are built to eliminate the manual steps so the bank staff can focus on high-value tasks like risk evaluation and handling special cases or exceptions. The result is the ability to handle high volumes at scale without errors and respond faster to customer needs.

Finally, the Experience Layer at the top can consume the Process APIs to expose appropriate information to the loan processing application and the loan application web portal.

Automate document processing with AI

While APIs are used to accelerate data and process integration, AI is used to automate the manual and arduous document validation process. Here we use GLYNT, an AI-powered no-code solution to transform a stream of documents into a stream of data. This solution is exposed as a set of REST APIs which is turned into a consumable building block using the MuleSoft REST connector.

At a high-level GLYNT uses a supervised machine-learning model which is first trained using a set of sample documents. Once trained, the model can be called on the actual document to output data in a JSON format. The document-specific model is automatically overlaid with a classifier model to further abstract the complexity of understanding individual document models.

Making the digital transformation journey

Digitizing loan documents and composing the loan application process using APIs could be the first step in improving customer response time and experience. Now customers can snap and upload a photo of the document using their mobile phone and get to the decision point much faster.

With the API-led approach now it is easier to extend support for a new channel like mobile or chatbot by just creating a new Experience API that leverages the existing process layer. For example, imagine the benefit of swiftly adding a chatbot channel to offload the call center load, with both the chatbot and call center rep using the same document data.

As the banking industry focuses on helping customer service with urgent financial needs, an API-led approach not only helps in accelerating lending operations but also lays a future-proof foundation for successful digital transformation.

For more discussion on this topic, tune in to our on-demand webinar: COVID-19’s impact to API strategies in financial services.

Chatbots and Digital assistants have emerged as one of the important channels for companies to deliver personalized customer experiences. For many enterprises Chatbot falls under the digital transformation initiative as it offers the potential to interact with the customer wherever they are — mobile, web, or messaging apps — in a highly targeted fashion using data and machine learning. Here is an excellent overview of Chatbots and a list of examples in practice by Forbes.

While many companies are experimenting some are still grappling with the question of why my customers need a chatbot when they already have an app, a web site, and the call center. I think the answer is in the question itself — why create an app when there is a web site. Chatbots are not just a new way of communication; it provides a natural way to interact with humans in an intelligent way.

For example, it is much easier to ask the bot “when is my credit card late fee due and how much is it” while you are standing in a checkout queue to make that impulsive buy. Granted you can swipe and tap your mobile phone to get the same information but it is a lot easier to type/speak a simple question. Don’t believe me? Read this detailed article on Erica — Bank of America’s Chabot that is used by both millennials and baby boomers alike for simple tasks like locking the card which is literally a couple of taps away from the mobile app.

Convenience is a key attribute of customer experience and Chatbots are all about making the interaction frictionless and targeted.

So I believe enterprise market adoption of Chatbots (text and voice) is going to only accelerate.

In the rest of the post, I’ll share the key points I took away from Oracle Chatbot training class that I attended a few weeks ago. Thanks to Grant Ronald and the team from Oracle Chatbot group for an engaging class.

• Chatbot as an application delivers value by simply abstracting the power of Machine Learning (ML) and Natural Language Processing (NLP) in a way that is transparent to the business user and the developer. In many applications, machine learning could be just one piece of the puzzle or several steps removed from delivering the end user experience. In contrast, the ML component of Chatbot directly adds value to the customer experience.
• Chatbot uses classification algorithm, a supervised machine learning technique, to classify the input string based on the training data set. So it is important to train the Chatbot for unexpected or unsolved user input/utterances as well — i.e., training for the unhappy path is equally important as training for the happy path.
• Use case selection for Chatbot requires deliberate thinking. Not all Interactive Voice Response (IVR) use cases can be ported over to Chatbot. Note humans express problems/desires and not the solution. So it is ideal to think from scratch and start with simple use cases like FAQs and navigation mechanism as explained in the Bank of America article referred above.

Conversation design experience is paramount for the success of Chatbot. It is more of an art than science requiring business thinking, human psychology, and linguistics to support global deployment. Oh, don’t forget that Chatbot can also have a personality!

• Chatbot solution implementation entails a full software development lifecycle rather than plugging in a widget on the website. Specifically, conversation design, integration with channels and backend, and importantly continuous training and deployment are essential. In some sense, you will never be done as needs (human input) keep changing and expanding and hence the need for continuous training and deployment like any other data science/ML project.
• Finally, measuring success requires inspecting analytics to identify maturity level, discovering unmet needs (remember, consumers will always surprise you), and tracking metrics like customer engagement level, traffic offload from other channels like the call center, and customer satisfaction scores.

Digital Assistants and Chatbots are here to stay and are a powerful channel to enhance the customer experience. Leveraging the channel successfully requires a project lifecycle thinking starting from use case identification to on-going training based on new user data and other considerations that I’ve listed above.

Have a point or a comment? Feel free to comment below.

Today, Machine Learning (ML) technology is simplified and abstracted to an API call so you can solve a data-intensive pattern matching problem easily. Google’s Move Mirror is a great example.

While creating a standalone ML-based consumer app is reasonably straightforward, it can be quite challenging to infuse ML at scale into a mission-critical enterprise-class cloud platform. Enterprise apps have to consider various steps in the machine learning life cycle including data cleansing, integration, and production deployment. Operationalizing ML is a topic by itself and I’ll share more on that in a future post.

When I researched about operationalizing ML, I found an online course titled How Google Does Machine Learning. Intrigued by the title, I took the course to understand how leveraging ML in consumer web apps compares to enterprise apps. The course gave me fresh perspectives on ML and validated several of my views on bringing ML to life.

In this post, I’ll share four key learning from the course.

1. Machine Learning (ML) effort allocation — Expectation vs. Reality

From a business process automation project standpoint, Machine Learning component is just one small piece of the total effort. The diagram below compares the expected effort with reality across various steps in making the project successful and this fairly matches with my recent experience.

My takeaway is ML model generation and parameter tuning are important but it can’t be the only focus of an ML project. Data gathering and cleansing, integrating ML predictions and feedback loop, and the infrastructure for deploying ML models in production are some of the critical steps that consume more effort.

Check Google’s blog post on ML surprise for more on this point.

Product managers leading the ML project should consider above effort allocation in prioritization and planning in order to deliver the value of ML to end customer.

2. ML Strategy is first and foremost a data strategy

This seems obvious at first. But Google suggests big data and analytics as a pre-requisite for doing any machine learning. In other words, ML is used to automate the insight generation process (of analytics) at scale with a learning feedback loop. The bigger point is if you don’t have the data to run analytics then you can’t do ML.

Simple ML and more data are better than fancy ML and small data. Quality and quantity of data should take precedence over fancy models and algorithms.

Next is support for batch and streaming data. Unless the same ML system runs both the batch data and streaming data the training-serving skew will become an issue. This could be due to data scientists and production team using a different set of coding tools. Apache Beam or Google DataFlow solves this by processing batch and streaming data pipelines in the same way.

3. Multiple models for a business problem

For models to be effective in prediction, it is important to break the problem into smaller tasks and apply the specific model to each task as opposed to using a single monolithic model.

For example, forecasting stock-outs can be divided into predicting product demand, predicting inventory, and predicting restocking time and each one can use a different model. Also, the model could vary by product category as forecasting logic is different for an electronic and a kitchen item.

On a related note, Google has over 4,000 ML models in production that are transforming Google to become an AI-first company.

4. Equality of opportunity

This important ML concept gives individuals an equal chance of desired outcome i.e. when you move a sample from one sub-group to another the outcome remains the same. Depending on the situation the model can minimize or maximize false positive rate (or type I error) or false negative rate (or type II error). The trade-off between Precision and Recall will improve inclusiveness.

To ensure equality of opportunity data should be fair and representative as bias in the data leads to bias in the model.

Data problems like unbalanced distribution, unexpected feature values, missing values, and distribution skew between data sets (i.e., train and test set) can bias the model. Facets, an open-source visualization tool, helps to understand the data, discover anomalies, and help create inclusive ML models.

ML in action

Earlier, I wrote that ML technology is simplified for easier consumption and the course labs prove that statement. In the course lab exercise, I got my hands dirty with Python, DataLab and BigQuery columnar database running on Google Cloud Platform using VMs and server-less managed services.

Running an analysis on a large dataset with 70M rows using BigQuery in less than three seconds is impressive. Finally, the pre-trained models for vision, video, speech, and Natural Language Processing (NLP) are easily accessible via APIs so you don’t have write models for common use cases from scratch.

That wraps my key learning and takeaways from the Google Machine Learning introduction course.

After completing How Google Does Machine Learning course (summary in an earlier post), I began Launching into Machine Learning course by Google Cloud on Coursera. I was hoping to beat the course deadline, but I miscalculated the depth and complexity of the material. In addition to refreshing some calculus, I had to search a few blogs and refer to the book Hands-On Machine Learning with Scikit-Learn and TensorFlow by Aurélien Géronto gain a solid grounding on the concepts.

In this post, I’ll document seven key concepts covered by the course to launch into Machine Learning.

1. Machine Learning (ML) terminologies demystified

While it is exciting to see how mathematical concepts are applied to a data problem some terminologies are referred under new names influenced by the ML discipline. For example, the independent variable in an equation is referred to as a feature in ML. Once I got through the ML-speak it became easier to follow the course.

Below are some basic ML terminologies with description. ML purists out there are welcome to correct me :)

• Algorithm — a set of rules to solve a problem. The algorithm is independent of the dataset. For e.g. a simple regression y = a + x * b (understand this is an equation, but you get the idea)
• Model — the output of the machine learning process. It is specific to a dataset. E.g. Tip amount = 1 + 0.12 * Bill amount. Many use algorithm and model interchangeably

Feature — an input parameter or independent variable. In ML, this is information we already have access to e.g. Bill Amount in the above equation

• Feature weight — the coefficient of a variable. In ML feature weight is determined through the training process e.g. 0.12 in the above equation
• Bias term — a constant in the equation e.g. 1 in the above equation
• Hyperparameter — this requires some explanation so it is captured below separately

Labeled data — Label is essentially what the ML model predicts. Labeled data are dataset containing answers (i.e. values to be predicted) e.g. past one-year data on Bill amount with corresponding Tip amount

• Loss function — also known as a cost function, is the error metric used to measure the model performance. e.g. root mean squared error (RMSE) for linear regression
• Training — the process of applying an algorithm on an existing dataset to come up with a model. E.g. training process outputs the equation Tip amount = 1 + 0.12 * Bill amount by modeling the existing dataset using regression
• Generalization — the property of an ML model to fairly represent the current dataset so it can predict the labels on unseen data with minimal error. In other words, the model is a good proxy for real-world data which it hasn’t seen before

2. Machine Learning types

Supervised and Unsupervised are the two main Machine Learning types. There is a ton literature on the web about these two types, but I was looking for a side-by-side comparison that captures the key differences between them so I created one below.

There are two more types, Semi-supervised and Reinforcement. Semi-supervised Machine Learning is a hybrid of Supervised and Unsupervised, that mainly feeds off of few labeled dataset using supervised and transitions to unsupervised on a large unlabeled dataset. A great example is tagging of photos with names e.g. iOS Camera app and Google Photos.

The fourth is Reinforcement learning that learns by itself based on the reward or penalty from previous actions. Robots learn how to walk using this algorithm.

3. Optimizing the ML model

The goal of ML is to create a model for a given dataset to predict the label (dependent variable) accurately. The accuracy of prediction increases when the prediction error is minimized. If ML uses a linear regression with few variables there are analytical tools to determine the best feature weights that minimize the error, which is RMSE in this case.

What if you have with hundreds or thousands of features and a large dataset? Analytical computation becomes impractical. Gradient Descent comes to rescue!

Gradient Descent (GD) is an optimization algorithm that iteratively tweaks the weights to minimize the error. GD scales and runs faster and is widely used to optimize the ML model.

Gradient Descent iterates by first identifying the direction to change the weight (referred as slope/gradient or derivative in calculus), second changing the weight in steps (aka learning rate), and third checking for the error and looping through until a minimum is reached. This is the process of walking down the loss curve (for the single parameter) or loss surface (multiple parameters) on all the points in parameter space. Check this blog post at Machine Learning Mastery for further explanation.

There are mainly three flavors of Gradient Descent — Batch, Mini-batch, and Stochastic. Mini-batch is the popular one, which runs on a subset of the data by extracting samples that on average balance each other out. The size of this subset is referred to as a batch size.

4. Parameter vs. Hyperparameter

You will hear Data Scientists talk a lot about hyperparameter tuning. To understand what a hyperparameter is, it is first important to highlight a key point about the previous concept of optimization.

Most ML models require an optimization algorithm to perfect the model and Gradient Descent is a good example. But note this optimization algorithm itself is not part of the final ML model.

Let me try a simple analogy — assume you are a student, learning to drive with an instructor who is guiding so you get trained quickly and effectively. When you learn to drive well (with minimal error) and pass the driver’s test (model validation) you don’t need the instructor anymore.

Now the attribute of the student (i.e. model) learning to drive is the parameter or model parameter and the attribute of the instructor (i.e. optimization algorithm) is the hyperparameter. For Gradient Descent, learning rate (aka step size) and batch size are hyperparameters.

Below is a simple side-by-side comparison and explanation of parameter and hyperparameter.

5. Machine Learning workflow

ML workflow puts together all the above concepts to arrive at a generalized model for prediction. Model selection is the first step (after gathering and cleansing data) which is driven by the use case and data distribution.

Then train the model with a set of hyperparameters and validate the results. Based on the results tune the hyperparameters (i.e. adjust the batch size and learning rate or nodes and layers for neural nets) and repeat the process until model shows signs of overfitting.

Hyperparameters play a key role in regulating the ML workflow by generalizing the model for a given data set.

Finally, use the last non-overfit model (the model before when overfitting starts) for prediction.

6. Three buckets of data

The ML workflow requires three different data buckets.

• Training set or bucket for computing feature weights and going through the optimization process with Gradient Descent to minimize the error
• The Validation set is used to frequently evaluate the performance of the model on a data-set that the model hasn’t seen in order to tune the hyperparameters

• The Test set is used for the final evaluation of the model to make a go or no-go decision at the business level. This is usually done by evaluating the model against a business performance metric or by establishing a simple benchmark

While the Validation set is used multiple times to tune hyperparameter for better model performance the Test set is used only once.

This is to prevent the model from learning the Test set and subsequently provide an unbiased evaluation of a final model fit.

7. Sampling for repeatability

Machine Learning is all about experimenting with models and data to automate prediction at scale.

Successful experimentation requires repeatability. Data scientists experiment by keeping the dataset constant while tweaking and tuning the model and running it again, on the exact same experimentation data set.

Repeatability also enables collaboration by allowing team members to run the experiment and get the same results.

In order to repeat experiments and get the same results, you need a repeatable sample of datasets.

Systematic sampling technique is used to create repeatable datasets.

One such technique is to use a one-way hash function on a column that has a fair distribution. For e.g. apply hash on the date column and use modulo operator to select a certain percentile of data for a given bucket.

That completes the seven basic Machine Learning concepts. It is worth repeating that Machine Learning is an experimentation process with data and models. Understanding these basic concepts is not only essential to put that process into practice, but also helps the Business to better engage with the Data Scientists.