Surveying the AI Landscape

Making AI Work: From Technology to Business Capability

A technical taxonomy for faster business decisions

Lee Farretta and Matthew Farretta · LMM Labs
Prepared in collaboration with ChatGPT · Article 1 of 3
Research cutoff October 1, 2026 · Published October 17, 2026

Download the article as a PDF

Abstract

An AI application may combine a model, company information, business software, and controls over how work proceeds. This article organizes those capabilities into five working areas and connects them to product choices. It develops the functional model introduced in Making Sense of AI and the Acceleration Opportunity into a practical taxonomy. Figure 1 maps capabilities to product examples; Table 1 supplies ten implementation categories, fifty candidates, and selection criteria. Figure 2 explains how to use both to define requirements, shortlist components, and test their fit. Table 2 applies that process to ten business functions, followed by a worked customer-service example that recommends an architecture and compares two implementation options. These are design analyses, not measured deployment results. A glossary clarifies the classification and technical terms. As the first article in the Making AI Work trilogy, the article establishes a foundation for a system blueprint and a subsequent decision about buying, combining, or building. The purpose is to shorten investigation without bypassing technical and business judgment.

Introduction

An AI application often combines a model with company information and business software. The design challenge is deciding which parts are needed, how they connect, and who controls the result. A useful taxonomy classifies components by function so a team can compare products that perform the same job.

Making Sense of AI and the Acceleration Opportunity introduced five working areas for understanding those functions (Farretta & Farretta, 2026). This article connects them to named products and a method for choosing among them. It begins the Making AI Work: From Technology to Business Capability trilogy. Article 2 develops a system blueprint; Article 3 examines buying, combining, and building. The aim is to reduce repeated investigation and move sooner into useful development. After the selection flowchart, ten business applications and a worked customer-service example demonstrate how to use the taxonomy. A glossary follows the references.

Reading the taxonomy

Figure 1 answers “What does this component do?” Its branches run from the five working areas to capabilities and product examples. A product can serve several functions, so its position identifies a useful role rather than an exclusive category. Managed platforms appear in a shared band because they span several areas.

Table 1 answers “Which products should we consider for that role?” It groups the options into ten implementation categories, each with five candidates and selection criteria. Read across the row that matches a required capability. Figure 2 then shows how to turn that classification into a shortlist and a set of selection checks. There is no need to choose a product from every branch.

Learning and generating

Predictive models classify items, estimate quantities, or forecast future values. Libraries such as scikit-learn provide methods for developing and comparing these models (scikit-learn developers, n.d.). Generative models produce language, code, images, or other content. Model services expose these capabilities through application programming interfaces (APIs), allowing a team to use a model without training its own.

Training and fine-tuning change a model’s learned parameters. Instructions and retrieved documents influence a response without, by themselves, changing those parameters. This matters when company information changes: updating access to documents is different from adapting the model itself. Table 1 separates predictive development from generative APIs so the shortlist begins with the kind of task the application must perform.

Retrieving knowledge

Retrieval finds information outside the model. Keyword search is useful for exact terms and identifiers. Vector search compares numerical representations, called embeddings, to find related meaning. Hybrid search combines the two (Microsoft, 2026). The application must also check permissions and document revisions; similarity alone does not establish that information is authorized or applicable.

Retrieval-augmented generation (RAG) gives retrieved material to a model as evidence for its response (Lewis et al., 2020). Table 1 separates search and storage products from tools for building RAG applications. The latter help connect document processing, retrieval, and generation, but the design still needs source attribution and answer checks. GraphRAG adds relationships and summaries for questions spanning a collection (Edge et al., 2025). Consider that extra work when the questions require it.

Figure 1
Functional taxonomy from working areas to product examples

Taking action

Tools connect AI to software operations, such as reading a database or submitting a business record. The model can propose an operation and its arguments; application code validates and executes the request. The system must enforce permissions and any required human approval.

A workflow follows predefined steps and branches. An agent selects its next actions from intermediate results, a pattern explored in ReAct (Yao et al., 2023). A workflow can contain a bounded agent stage where adaptation is useful. Compare that flexibility with its added cost and delay (Anthropic, 2024). Table 1 distinguishes agent construction from business integration. Model Context Protocol (MCP) standardizes connections to tools and context; it does not set the application’s authority or approval policy (Model Context Protocol, n.d.).

Coordinating work

Coordination manages steps, waits, and recovery. Context is the information supplied to a model call. Task state records progress and pending decisions. Retained memory makes selected information available to later work. Saving any of these does not, by itself, change the model’s learned parameters.

LangGraph supports flows combining models and code; Temporal supports durable workflows across failures and long waits (LangChain, n.d.-a; Temporal Technologies, n.d.). Recovery must also account for external actions. Repeating a request can duplicate a completed write if the receiving system lacks suitable protection. Agent2Agent (A2A) supports exchanges of tasks and results between agent services (A2A Project, n.d.). Use these components where the process needs them, rather than adding coordination layers by default.

Evaluating results

Evaluation checks whether the system meets its requirements. Observability records what happened so a result can be investigated. A trace links the sources, model calls, tool results, and outcome of an execution (LangChain, n.d.-b). Table 1 separates platforms for these records and feedback from tools that run checks, while recognizing that their features overlap.

The checks must match the failure. A formatted answer can still use the wrong evidence. RAGAs examines retrieval and answer quality; τ-bench examines tool use, final state, and consistency across repeated trials (Es et al., 2024; Yao et al., 2024). These methods inform testing, but an application needs evidence from its own data and integrations. Include correction, human review, elapsed time, and total cost when judging whether it accelerates accepted work.

Using the product map

Use the categories to compare products that address the same requirement. Table 1 identifies differences worth testing, including exact-identifier search, permission filters, approval waits, recovery, and records that explain a failed case. A managed platform may cover several roles, but its services must still fit the application’s data, deployment, and integration needs.

Check product lifecycle as well as features. Pipedream Connect, for example, is distinct from the Workflows product scheduled to close in March 2027 (Pipedream, n.d.). Keep the shortlist tied to the required capability and the work that remains. Figure 2 turns these comparisons into a selection process.

Applying the taxonomy

Figure 2 shows how to use the taxonomy and product table together. Begin with a specific business outcome and decide what would count as success. Use Figure 1 to identify the capabilities needed, then Table 1 to shortlist products for those roles.

Check whether the candidates can work together within the data, permission, deployment, and cost limits. Test them with the same representative inputs and acceptance criteria. If a candidate fails, return to the shortlist. If none fits, make any scope change an explicit business decision. Record the selected components and remaining integration work for the system blueprint and make-or-buy analysis.

Table 1
Five working areas and ten implementation categories

Original classification and conditional shortlists from the companion product source register, retaining the October 1, 2026 research cutoff. All 50 entries are preserved. Managed platforms span areas. Selection criteria are tests, not rankings. Connect is distinct from the retiring Pipedream Workflows product.

Figure 2
Using Figure 1 and Table 1 to select components

Applying the taxonomy across business functions

Table 2 records the preliminary design choices reached by applying the six steps in Figure 2 to ten representative business functions. Each row maps an application to the relevant taxonomy categories, an architecture, candidate products, and the checks that would decide the choice. These are worked design mappings; product performance has not been measured.

Table 2
Business applications mapped to architecture and candidate components

Note. Category IDs refer to Table 1. The mappings apply the flowchart to defined business tasks; they are not a ranking. Listed components are not complete stacks. Amazon Bedrock Knowledge Bases supports retrieval and cited generation (Amazon Web Services, n.d.). Verify product editions and interfaces, and specify hosting, storage, permissions, and integration work before implementation.

Worked example in customer service

Consider a mid-market equipment distributor whose representatives search product manuals and warranty policies before replying to customers. The following fictional case works through Figure 2; it is not a customer deployment or a product benchmark.

1 Define the outcome. Produce a draft reply with the applicable policy passage and a source link. Assume an Azure-hosted application, authenticated staff, and a maintained document collection. The first release cannot send replies, authorize refunds, or promise replacements. Success means less total handling time, including review and corrections, without weakening evidence or access controls.

2 Map the capabilities. Figure 1 points to generation, retrieval, and evaluation. Table 1 narrows the shortlist to 1B and 2A, with 5A and 5B for testing and trace review. A fixed retrieval-and-drafting workflow is sufficient; a free-form agent would add planning work without a demonstrated need (Anthropic, 2024). Ticketing remains the system of record.

3 Shortlist the products. Start with Azure AI Search for hybrid retrieval (Microsoft, 2026) and the OpenAI API for drafting. Application code passes retrieved passages to the model. An AWS alternative is Amazon Bedrock Knowledge Bases, with its model and vector-store configuration, including an Amazon OpenSearch option (Amazon Web Services, n.d.). The stated Azure environment favors the first pair; it does not establish superior answer quality.

4 Check the fit. The application authenticates the representative, filters documents by authorization, product, and effective date, retrieves evidence, drafts a response, and displays it for review. It stores the question, source revisions, draft, and disposition. Validate structured output and citations in code: schema compliance does not establish factual correctness (OpenAI, n.d.). Confirm retention terms, region, indexing updates, and total operating cost before committing.

5 Test a concrete case. Use a synthetic request: “A ZX-40 failed after 18 months. Can I promise a replacement?” Supply a current test policy stating 24 months of coverage subject to inspection, plus an obsolete 12-month policy. The expected draft cites the current policy and explains that inspection is required; it must not promise replacement. Repeat with the current policy missing and with access denied: escalate in the first case and exclude unauthorized evidence in the second. These are specified tests and expected outcomes, not observed product results.

6 Record the recommendation. Recommend the Azure AI Search and OpenAI API pair for an initial read-only pilot under the stated assumptions. Retain Bedrock Knowledge Bases as the AWS alternative. Compare both on the same reviewed cases, including conflicting documents and instructions embedded in retrieved text. Reject unsafe behavior; require an agreed improvement in total handling time and acceptable cost. Record model versions, configuration, integration work, and test results for Article 2. Add an agent only if measured retrieval failures justify adaptive searches.

Conclusion

The taxonomy is useful when it narrows a real decision. It should leave a team with a component shortlist, reasons for each choice, and specific questions to resolve in design. Figure 2 provides that path without requiring every technology in the map. Human goals, architecture, and review remain central to LMM Labs’ development methodology (LMM Labs, n.d.). Carry the selection record into the next article’s system blueprint, then compare implementation paths in Article 3.

Research and preparation note

Technical explanatory synthesis with an original editorial taxonomy and selection flowchart. Research cutoff and product information: October 1, 2026. Editorial revision: October 17, 2026. Sources and product roles remain documented in the companion register. The flowchart is an editorial guide, not a validated selection model. No comparative experiment, new performance measurement, or market-share ranking is reported. Prepared in collaboration with ChatGPT; Lee Farretta is executive editor. © 2026 LMM Labs. Third-party rights are retained.

Product-source links and implementation roles verified October 19, 2026. The public product source register provides official sources for all 50 candidates, retrieval dates, and selection qualifications. This is a documentation check, not new benchmarking or a change to the article’s research cutoff.

References

Appendix

Glossary

Terms describe their use in this article. Business functions identify where work occurs; working areas and implementation categories organize the technology used to support it.

Acceptance criteria. Agreed conditions used to accept an application or compare candidates, including quality, safety, cost, and response time.

Agent. A model-driven execution pattern that selects actions or tools using intermediate results, within application-defined limits.

API and SDK. An application programming interface defines how software requests a service. A software development kit supplies code and tools for using interfaces or building applications.

Architecture. The arrangement of application components, their interfaces, data flows, execution control, and deployment boundaries.

Business function. An organizational responsibility, such as finance or customer service. It describes where work occurs, not a technical layer.

Capability. A function a component can perform, such as forecasting, finding evidence, or executing an approved action.

Chatbot. A conversational interface. Its underlying execution can use a simple model call, a workflow, an agent, or a combination.

Context and task state. Context is information supplied to a model call. Task state records execution progress and pending decisions between steps.

Embedding and vector search. An embedding represents content numerically. Vector search compares these representations to retrieve related content.

Evaluation and observability. Evaluation tests whether requirements are met. Observability records execution so behavior and failures can be investigated.

Fine-tuning. Additional training that changes model parameters. Supplying instructions or retrieved documents does not itself fine-tune a model.

Hybrid search. Retrieval combining keyword and vector methods so exact terms and semantic similarity can both contribute.

Idempotency. The property that repeating an operation has the same intended effect as performing it once, important when retrying writes.

Implementation category. One of Table 1’s ten groupings of products by an implementation role. Categories are not mutually exclusive vendor memberships.

LLM. A large language model trained to model language patterns and generate responses. Its output still requires task-specific validation.

MCP and A2A. Model Context Protocol connects applications to tools and context. Agent2Agent supports task exchanges between agent services. Neither replaces authorization policy.

Orchestration and workflow. Orchestration controls execution, state, and recovery. A workflow specifies steps and branches in advance; it can contain bounded agent stages.

Provenance and trace. Provenance identifies a result’s sources and revisions. A trace records the linked steps, calls, tool results, and outcome of one execution.

RAG and GraphRAG. Retrieval-augmented generation supplies retrieved evidence to a generative model. GraphRAG uses extracted relationships and summaries for graph-based retrieval and synthesis.

Working area. One of this article’s five broad functional groupings: learning and generating, retrieving knowledge, taking action, coordinating work, and evaluating results.

Download the article as a PDF

More LMM Labs articles