AI ARCHITECTURE AND IMPLEMENTATIONA detailed guide to choosing where AI should run, what each approach requires, and how to implement it without creating a costly or disconnected system.
Executive overviewThe right answer depends on the work being done, the information involved, the level of model capability required, how quickly the system must respond, how often it will be used, and who can realistically operate it.
Usually the strongest starting point when speed, access to advanced models, elastic capacity, and a lower infrastructure burden issue most.
Best fit:variable demand, complex reasoning, rapid experimentation, customer-facing experiences, and teams that do not want to operate model infrastructure.
Usually the strongest fit when information must remain inside a controlled environment, the work must continue offline, or stable high-volume demand can justify dedicated infrastructure.
Best fit:sensitive intellectual property, disconnected facilities, plant-floor use, predictable workloads, and applications that can succeed with appropriately sized local models.
Often the most practical company-wide answer because it lets each workload use the environment that fits it while company policy, identity, monitoring, and support remain consistent.
Best fit:mixed data sensitivity, mixed model needs, existing cloud and on-premises systems, resilience requirements, and companies adopting AI across multiple departments.
It is also where documents are stored, where retrieval occurs, where prompts and outputs are logged, which systems the application can reach, what happens when a service fails, who approves changes, and how a person takes over when judgment is required.
Test the work, information, users, integrations, and failure conditions.
Classify workloads. A marketing assistant and an engineering agent do not have the same requirements.
Buying hardware creates control, but it also transfers security, maintenance, capacity, and lifecycle responsibility to the company.
What the architecture changesAll three approaches need identity, data rules, application design, evaluation, monitoring, support, and incident response. The difference is how much is provided by a platform and how much the company must build and operate.
Which work may use AI, what outcome is expected, who owns it, what information is allowed, and where human review is required. This always remains the company's responsibility.
The interface, conversation, retrieval, tools, approvals, handoffs, system actions, exception handling, and recordkeeping that make the model useful.
The model, inference engine, context limits, rate limits, version behavior, safety controls, and performance characteristics.
Documents, records, embeddings, search indexes, permissions, retention, source citations, version control, and deletion.
Compute, networking, identity, secrets, logging, scaling, patching, backups, disaster recovery, capacity, and support.
Facilities, servers, accelerators, storage, power, cooling, hardware lifecycle, and spare capacity.
Keep the business decision, data classification, approval, and outcome tracking under company control regardless of where the model runs. Treat model hosting as an implementation choice, not the company's AI policy.
At-a-glance comparisonThese are starting assumptions, not promises. The final answer changes with the chosen model, provider, hardware, security design, workload volume, and operating team.
| Decision area | Cloud | Local | Hybrid |
|---|---|---|---|
| Time to first useful pilot | Usually fastest | Slower if infrastructure is not ready | Fast when the first pilot uses an existing cloud or local path |
| Access to frontier model capability | Usually strongest and newest | Depends on available open-weight models and hardware | Can use both |
| Control over weights and runtime | Limited to provider options | Highest | High where local control is required |
| Data containment | Strong controls are possible, but terms and configuration issue | Can remain inside company-controlled infrastructure | Sensitive portions can remain private while other work uses cloud models |
| Offline operation | No | Yes, if the full application stack is local | Possible for selected functions and fallback modes |
| Elastic capacity | High | Limited to purchased capacity | Local base capacity with cloud burst is possible |
| Infrastructure burden | Lowest | Highest | Higher architectural and integration burden |
| Cost at low or uncertain demand | Usually favorable | Hardware may sit underused | Can avoid premature hardware while preserving options |
| Cost at steady high utilization | Can become expensive without controls | Can be favorable if capacity is well utilized | Route stable volume locally and complex peaks to cloud |
| Model change control | Provider lifecycle and deprecations issue | Company chooses when to change | Local stability plus cloud innovation, with more testing |
| Operational simplicity | Highest at the model layer | Requires specialized operations | Requires unified routing, policy, and monitoring |
| Best overall use | Fast access to strong managed capability | Controlled, offline, stable, or highly sensitive workloads | Company-wide adoption across different workload types |
Do not score a deployment in the abstract.Score the specific workload, including the information it touches, expected demand, users, consequences of a wrong answer, systems it can change, and what must happen during an outage.
Cloud-based AIThe term "cloud" hides several very different arrangements. A consumer chat subscription, a company-managed API, and a private model endpoint inside a cloud network do not have the same controls or operating model.
An employee uses a hosted assistant through a website or desktop application. This can be useful, but company identity, information controls, logging, retention, and integration may be limited unless the organization buys and configures an enterprise plan.
The company builds its own application and sends selected prompts to a hosted model. This offers much more control over the user experience, retrieval, system actions, logging, and approval than sending employees to a general chat interface.
A cloud provider supplies model access plus identity, networking, content controls, evaluation, retrieval, agent tools, monitoring, and deployment services. The company still has to configure them correctly and decide which features may retain state.
The model remains provider-operated, but access occurs through private networking and company-controlled cloud resources. This can substantially reduce public network exposure without transferring model operations to the company.
Capacity is reserved or provisioned for more predictable throughput and isolation. It can improve reliability and performance planning, but it adds commitment and may not make sense for uncertain or low demand.
The company deploys an open-weight model on rented cloud compute. This gives more model and runtime control than a managed API while retaining cloud elasticity. The company now owns more of the serving, patching, scaling, and model lifecycle.
A cloud architecture can be tightly controlled. The mistake is assuming a provider's enterprise claims automatically apply to every account, feature, region, model, plug-in, stateful API, or third-party connection.
Cloud advantagesTeams can test advanced language, vision, audio, and reasoning models without acquiring accelerators or building a serving platform first.
Models, context strategies, workflows, and interfaces can be compared while the business is still learning what it needs.
Capacity can expand for seasonal work, campaigns, large document batches, or customer traffic without sizing permanent infrastructure for the peak.
Distributed employees, customers, representatives, and facilities can use a centrally managed service without routing every request through a single physical site.
The provider carries the base model serving, much of the scaling, hardware availability, and low-level optimization.
Enterprise platforms can connect identity, private networking, secrets, encryption, logging, policy, and monitoring already used by the company.
A company can route different jobs to different model families without buying hardware for every model size and modality.
Usage-based services let the company validate value, demand, and risk before committing to a local platform.
When the company does not yet know which workloads will survive testing, pay-for-use access avoids turning an early architecture guess into a hardware purchase and a permanent support obligation.
A sales team needs occasional deep analysis of complex documents and benefits from a frontier model.
A public website agent has irregular traffic and must support voice, language, and reasoning across many topics.
A marketing team drafts non-sensitive content and needs rapid access to new capabilities.
Cloud constraints and failure modesThe company still owns the decision to send information, the design of the application, the permissions it grants, the way outputs are used, and the consequences of a wrong or unavailable result.
The pilot uses personal accounts; employees paste unrestricted company information; nobody knows whether conversation history is retained; the application calls a model directly without identity or logging; costs are not allocated by workload; or a single provider-specific design controls the entire workflow.
Cloud implementationEmployees and customers should not need to understand provider accounts, model names, or prompt rules. The application should enforce the allowed path.
Use an internal model interface, store prompts and evaluations in company-controlled formats, separate retrieval from the model provider, and avoid embedding business rules inside a proprietary agent feature unless the benefit clearly outweighs the switching cost.
Local AI and local LLMsThe model may run on a workstation, an edge device, a plant server, a private data center, or company-managed infrastructure in a colocation facility. The important distinction is that the company controls the runtime and carries the operational responsibility.
A smaller model runs on a high-memory workstation for an engineer, technician, analyst, or creative specialist. This can be effective for private individual work, but it is difficult to govern and support if every user builds a different stack.
A dedicated device serves a plant, field location, mobile unit, or disconnected environment. It can provide low latency and offline availability, but remote support, patching, monitoring, and physical security must be designed from the beginning.
A central company service hosts approved models for multiple applications. This is generally more supportable than scattered desktop installations because identity, versions, logging, capacity, and updates can be managed centrally.
Multiple servers or accelerators support larger models, more users, redundancy, and separate environments. This begins to resemble a private cloud and requires platform engineering, scheduling, model serving, observability, security, and capacity management.
The model weights are downloaded under a specific license and served with an inference engine. "Open weight" does not automatically mean unrestricted use, open training data, simple security, or no ongoing updates.
This is hybrid, not fully local. Documents and indexes remain private, but selected excerpts are sent to a cloud model. It can be a strong compromise when the company needs frontier capability without moving entire repositories.
Local advantagesA technician agent must work inside a facility during an internet outage and uses approved manuals, service history, and machine-specific checks.
An engineering assistant works with sensitive drawings, formulas, customer specifications, and unpublished product information.
A high-volume classification or extraction task has stable demand and succeeds with a smaller validated model.
The local advantage is strongest when the use case is specific.A smaller local model connected to the right documents, rules, tools, and workflow can outperform a general chat experience for a narrow operating task even when it is not the strongest general-purpose model.
Local constraints and failure modesThe local model may be "free" to download while the production system around it is not. Hardware, serving, security, evaluation, support, upgrades, and capacity all have owners and costs.
Parameter count alone is not enough. Memory, precision, context length, concurrency, prompt size, output length, modality, latency target, and serving engine all affect the required accelerators and system memory.
Local systems can be underused or become saturated. Scaling may require procurement, facilities work, and lead time rather than a configuration change.
Smaller local models can be excellent for extraction, classification, retrieval, and narrow, defined tasks, but complex reasoning, multilingual voice, advanced vision, or broad customer conversation may require more capability than the local hardware can support.
The company must secure the model artifacts, containers, operating systems, drivers, APIs, secrets, administrator access, network exposure, logs, and update process.
A single workstation is not a production service. Redundancy, backups, monitoring, spare capacity, restart behavior, storage protection, and recovery procedures must match the business impact.
Review the model license, allowed uses, redistribution terms, source, integrity, dependencies, and security history. Open weights do not eliminate supply-chain review.
New model versions, serving engines, GPU drivers, container bases, security patches, and application libraries all require testing and controlled deployment.
If the system issues to production, someone must own incidents, capacity, access, logs, evaluation, updates, user support, and vendor escalation. "IT will handle it" is not an operating model.
The design begins with a GPU purchase instead of a workload; a desktop demo is presented as a production architecture; nobody has benchmarked the practical prompts; model downloads are uncontrolled; the system lacks centralized identity and logs; or the company expects a general local model to match every cloud capability.
Local implementationDefine who can use the service, expected hours, response-time target, supported model and context size, capacity limit, maintenance window, recovery target, and manual fallback. This turns "we have a local model" into something the business can rely on.
Hybrid AIHybrid should not mean a collection of unrelated pilots. It should mean consistent company policy with several approved execution paths.
Documents remain in company systems. The application retrieves only the relevant passages, applies permissions and redaction, and sends the minimum necessary context to an approved cloud model.
A local model handles routine questions. When confidence, complexity, or modality exceeds its approved range, the application requests permission or automatically routes an allowed version of the task to a stronger cloud model.
A cloud service provides the full experience during normal operation. A local model supports a limited set of critical functions during an outage or disconnected period.
Teams experiment and evaluate in cloud environments, then deploy a selected open-weight model locally for stable production use after performance, security, and licensing review.
The routing rule must be visible.The company should be able to explain why a workload uses a given model, what information crosses the boundary, what is logged, and what happens when the preferred route is unavailable.
Hybrid tradeoffsEach task can use the capability, privacy boundary, latency, and cost structure that makes sense.
Sensitive preparation can remain local while approved, minimized context uses a stronger managed model.
Critical local functions can continue during external outages, and cloud capacity can absorb peaks beyond local capacity.
The company can learn with cloud services, identify stable high-value demand, and move selected workloads locally when the case is proven.
Departments can use different approved patterns without creating unmanaged personal AI setups.
Identity, routing, policy, monitoring, evaluation, and support must work across both environments.
Different models may answer differently. The application needs clear capability boundaries and environment-specific evaluation.
Logs, versions, retrieval paths, and tool calls must be correlated across environments to explain what happened.
The company may pay for both cloud services and local capacity plus the routing layer that connects them.
A system is only as controlled as the least governed path, including local experiments, cloud consoles, connectors, and manual exports.
Use hybrid when the workload differences justify it. If all approved work can be handled safely and economically by a managed cloud service, adding a local stack creates unnecessary burden. If a single protected local environment meets the need, cloud routing may add an avoidable boundary.
Hybrid implementationDefine what each route is approved to do: supported tasks, information classes, maximum action authority, quality threshold, latency target, cost limit, and fallback. The application can then change models without silently changing the business promise.
Data, security, and privacyNIST's zero trust guidance specifically rejects implicit trust based only on physical or network location. Protect the resource, identity, and action in every architecture.
| Control question | Cloud | Local | Hybrid |
|---|---|---|---|
| Who can use the application? | Company SSO and conditional access | Company directory, device, and network identity | Same identity mapped across both routes |
| What information may be used? | Feature and provider terms plus company data policy | Local policy, file permissions, and index controls | Classification determines what remains local or may be minimized for cloud |
| Where is state stored? | Check prompts, files, threads, vector stores, logs, and abuse monitoring | Company storage, indexes, logs, backups, and model cache | Document every store and cross-boundary copy |
| Who may change the system? | Cloud administrator plus application release roles | Infrastructure, model, data, and application administrators | Coordinated release authority across environments |
| How is access reviewed? | Provider and cloud audit logs plus application record | Local platform, application, and system logs | Unified correlation and shared retention |
| What can the AI change? | Use the same rule everywhere: minimum tool authority, transaction limits, approval for consequential actions, and a complete record of what was proposed and executed. | ||
Classify data, minimize context, enforce source permissions, detect secrets and personal information, and prevent unauthorized connectors.
Separate instructions from retrieved content, constrain tools, validate outputs, require approval where needed, and resist prompt injection.
Log versions, sources, actions, approvals, and errors while avoiding unnecessary retention of sensitive prompt content.
Review data handling by feature.Managed platforms may treat stateless inference, stored conversations, uploaded files, fine-tuning data, abuse monitoring, and third-party models differently. The architecture record should name the exact feature and configuration, not just the provider.
Model quality and lifecycleCollect representative examples before choosing the architecture. Include ordinary cases, difficult cases, incomplete information, outdated documents, conflicting sources, edge cases, prohibited requests, deliberate misuse, and situations that require a person.
A local model with high-quality retrieval and narrow tools may beat a larger cloud model with poor sources. A strong cloud model may complete complex work that a local model cannot. Test the complete path.
Define what the model and application are proven to handle, what needs review, and what is outside scope. This is more useful than a broad claim that the system is "accurate."
Model version, quantization, prompt, retrieval index, document set, tool definition, safety layer, and runtime changes can alter behavior.
Model, version, provider or weights, runtime, endpoint, region, license.
Prompt, tools, retrieval, permissions, interface, approval, fallback.
Evaluation set, results, known limitations, risk review, owner approval.
Capacity, monitoring, cost, support, incident path, rollback, review date.
A provider benchmark or model leaderboard cannot answer whether the system will work inside the company's documents, language, rules, integrations, and approval process.
Applications, agents, and company systemsHow the person asks, reviews, corrects, approves, and reaches a human. The interface should make limits and sources clear without forcing the user to understand the architecture.
Permission-aware access to current documents, records, history, and definitions. Retrieval should preserve source, date, version, and ownership.
Search, calculate, create a draft, update an allowed field, schedule a task, prepare a quote, inspect a record, or request approval. Each tool needs inputs, validation, limits, and a record.
Instructions, allowed knowledge, available tools, spending or action limits, escalation, review, and the conditions that stop autonomous work.
Cloud, local, or hybrid selection based on data class, capability, latency, cost, capacity, and availability.
A customer, employee, operator, salesperson, or technician explains what they need in normal language. The agent finds approved information, asks useful follow-up questions, and hands the conversation to the right person or process.
An agent prepares or carries out clearly defined work: collect information, compare records, prepare a draft, monitor an exception, request approval, or update an allowed system after checks pass.
The user should see a dependable company tool. The application should decide which model route is allowed, preserve context, and provide a clear handoff if the preferred route cannot complete the work.
Total cost of ownershipUsage:input, output, cached context, embeddings, images, audio, batch, and provisioned capacity.
Platform:storage, retrieval, databases, networking, monitoring, security, support, and data egress.
People:application engineering, evaluation, policy, operations, and user support.
Infrastructure:servers, accelerators, storage, network, power, cooling, space, spares, and refresh.
Software:enterprise runtime, orchestration, security, monitoring, support, and model licensing where applicable.
People:platform, security, ML operations, application, support, and on-call coverage.
Both base paths:local capacity and approved cloud services.
Control plane:routing, policy, identity, evaluation, observability, and cross-environment support.
Benefit:stable work can use the economical route while peaks and difficult tasks use elastic capability.
Monthly architecture costdivided byaccepted completed outcomesis more useful than cost per token. Include human review, corrections, retries, failed jobs, support time, and integration work.
Example outcome:a service case prepared with correct customer, machine, symptom, relevant history, required checks, approved next step, and clean escalation - not merely an AI response.
Choosing by workloadScore each workload from 1 to 5. Add evidence and a short explanation. Weight the categories that issue most to the company rather than relying on a generic total.
| Category | Questions to answer | Cloud pull | Local pull |
|---|---|---|---|
| Information sensitivity | What data, documents, personal information, customer material, intellectual property, or regulated records are involved? | Low sensitivity | High sensitivity or strict containment |
| Capability requirement | Does the task need frontier reasoning, advanced vision, broad multilingual ability, high-quality voice, or very long context? | High capability | Defined task fits a validated model |
| Connectivity and continuity | Must it work offline? What happens during internet, provider, identity, or local infrastructure failure? | Reliable external path | Offline or local continuity required |
| Demand shape | Is demand small, uncertain, spiky, seasonal, steady, or continuously high? | Uncertain or bursty | Steady and highly utilized |
| Latency | What response time is required at practical prompt size and concurrency? | Network delay acceptable | Local response critical |
| Change control | Can provider model changes be absorbed? Must behavior remain pinned for long periods? | Frequent innovation useful | Tight release control required |
| Integration boundary | Which systems, devices, files, tools, and transactions must the application reach? | Cloud systems dominate | Local systems or equipment dominate |
| Operating capability | Can the company realistically run secure, resilient inference and support it over time? | Limited platform team | Strong platform and support team |
| Economics | What is the cost per accepted outcome under practical demand, review, redundancy, and support? | Usage economics win | Utilized capacity wins |
Capability, speed, elasticity, and lower infrastructure burden clearly outweigh the provider dependency.
Containment, offline operation, controlled behavior, or steady economics clearly outweigh the operating burden.
The workload genuinely contains two different classes of work or the company needs a managed migration and fallback path.
Scenario recommendations| Workload | Likely starting architecture | Why | What to validate |
|---|---|---|---|
| Public website conversational agent | Cloud or hybrid | Variable traffic and strong language, voice, and reasoning requirements | Data collection, retention, abuse, handoff, cost, and peak capacity |
| Internal company knowledge assistant | Hybrid or private cloud | Private retrieval with managed model capability is often practical | Permissions, source fidelity, stale content, logs, and information crossing the model boundary |
| Factory technician agent | Local or hybrid | Low latency, equipment proximity, sensitive records, and offline continuity | Model quality on practical faults, update process, local capacity, and escalation |
| Engineering and product IP assistant | Local, private cloud, or tightly controlled hybrid | High-value technical information and need for controlled integration | Model capability, data minimization, source access, export controls, and human review |
| Marketing drafting | Cloud | High capability and low infrastructure justification for approved non-sensitive work | Brand review, factual checking, source rights, and customer data exclusion |
| High-volume document classification | Local or cloud batch after benchmark | Stable repetitive work may fit a smaller model and predictable capacity | Throughput, confidence thresholds, exceptions, and total cost per accepted record |
| Sales opportunity and account preparation | Hybrid | CRM and company context may stay controlled while complex synthesis uses managed capability | Permissions, customer confidentiality, source dates, workflow action limits, and review |
| Autonomous system actions | Architecture depends on data and availability; controls are mandatory | Risk comes from authority, not just model location | Tool permissions, transaction limits, approval, idempotency, rollback, and complete audit record |
These are starting hypotheses. A short evaluation with practical company work can reverse the expected answer, especially when a smaller model performs better than expected or a cloud model's capability materially reduces human review.
Implementation roadmapChoose several meaningful workloads. Document users, information, current process, pain, systems, volume, risk, owner, and expected outcome.
Classify data, define approved uses, identify human approval, review vendors and licenses, and determine which architecture paths are permitted.
Build a workload evaluation set. Test cloud and local candidates where the decision is uncertain. Track quality, latency, cost, review, and failure behavior.
Connect the application, retrieval, tools, identity, logging, approval, and handoff. Run with a limited user group and a known support path.
Approve the architecture, service level, operating owner, budget, release process, monitoring, incident response, and next workload sequence.
The goal of the first 90 days is not to declare a permanent company standard. It is to establish a repeatable way to choose, test, approve, and operate each workload without starting from scratch.
Operating model| Responsibility | Primary owner | What the owner must be able to answer |
|---|---|---|
| Business outcome | Process or department owner | What problem is being solved, who uses it, what success means, and whether the system is improving the work. |
| Information use | Data owner with security and legal support | What information may be used, where it may go, how long it is retained, and who can approve an exception. |
| Application behavior | Product or application owner | What the experience does, what it may answer or change, how it hands off, and which releases are in production. |
| Model and evaluation | AI or technical owner | Which model and version is used, why it is fit, what tests it passed, known limits, and when it must be re-evaluated. |
| Cloud platform | Cloud platform and security team | Which tenant, region, endpoint, identity, network, retention, quota, logs, and provider terms apply. |
| Local platform | Infrastructure and AI operations team | Which hardware, runtime, capacity, patches, backups, monitoring, support, and recovery target apply. |
| Tools and actions | System owner and process owner | What the AI can read or change, validation, transaction limits, approval, rollback, and audit requirements. |
| Incident response | Operational owner with security and business | Who responds to harmful output, data exposure, model failure, outage, cost anomaly, unauthorized action, or quality regression. |
Review use, quality, exceptions, cost, access, incidents, unresolved user feedback, and capacity.
Re-test affected workloads, document changes, approve known limitations, confirm rollback, and communicate user impact.
Revisit vendor terms, architecture fit, model alternatives, data policy, business value, service level, and decommissioning plan.
Vendor and platform due diligenceCan it be tested with company examples before purchase, and can the company retain the results?
What may it read, recommend, approve, or change, and how are those permissions enforced?
Who supports it, what is monitored, what is the recovery path, and what does the service level cover?
How are data, indexes, logs, evaluations, prompts, tools, and workflows moved or retired?
A strong vendor answer names the exact product, feature, region, contract, control, and responsibility. A vague statement that the platform is "enterprise secure" is not an architecture decision.
Decision worksheet| Workload and owner | What work is being improved, who owns the outcome, and who uses the system? |
| Current process and cost | How is the work done now? Where do time, waiting, errors, rework, risk, or customer delay occur? |
| Expected outcome | What measurable improvement should occur, and what result would justify continued investment? |
| Information | Which documents, records, personal information, customer data, intellectual property, and system context are needed? |
| Actions and authority | What may the system read, draft, recommend, request, approve, or change? Where is human approval required? |
| Demand and service level | Users, requests, concurrency, hours, seasonality, response time, availability, recovery, and offline requirements. |
| Capability | Language, reasoning, vision, voice, context, tool use, accuracy, consistency, and citation requirements. |
| Evaluation evidence | Representative cases, difficult cases, prohibited cases, quality threshold, human review, latency, and cost. |
| Cloud option | Provider, model, feature, region, network, retention, training restriction, quota, cost, fallback, and operating owner. |
| Local option | Model, license, runtime, hardware, capacity, security, availability, support, cost, fallback, and operating owner. |
| Hybrid option | Routing rule, local boundary, cloud boundary, shared control plane, logs, fallback, and cross-environment support. |
| Decision | Selected approach, reasons, rejected alternatives, assumptions, conditions, approval, review date, and exit path. |
Keep this record short enough to update. Its purpose is to make the decision reviewable and prevent architecture from becoming an undocumented assumption inside a pilot.
Research and source notesImportant:Provider features, model availability, licensing, retention options, regions, and service terms change. Re-check the exact current documentation and contract before approving a production architecture. This guide is technical and operational guidance, not legal advice.
CLOUD, LOCAL, OR HYBRID AIA company does not need to predict the future of AI or commit every department to the same model. It needs a clear way to decide what may be used, where it may run, how it will be tested, who owns it, and how it becomes part of normal work.
Workload inventory, data and action classification, cloud and local evaluation, architecture selection, security and integration design, cost analysis, pilot implementation, production readiness, and the operating roadmap.
A documented decision for each priority workload, a practical company architecture, clear policies and ownership, working applications or agents, measured results, and a sequence the company can continue to follow.
Choose work that people already recognize: questions that repeat, information that is hard to find, follow-up that consumes time, a process that stalls, or a decision that requires too much manual preparation. That is enough to begin.