Make’s AI adoption survey points to a useful operational tension: businesses are enthusiastic about AI, but many also question their readiness and the role of human judgment. That contrast is not evidence that companies are ready to hand critical work to autonomous agents. It is a reason to select one bounded process, test it against a baseline, and keep accountable people and deterministic controls in charge of what the system may change.
This article translates the survey’s reported findings into a practical workflow design method. The goal is not to choose an agent first. It is to decide where interpretation helps, where exact rules are safer, how a proposed result should be validated, and what happens when the system is uncertain or fails.
A suitable pilot might let an agent suggest a route for an inbound customer message. A case match, permitted-value check, permission check, freshness check, and review policy should decide whether a CRM record can actually be updated.
What the AI adoption survey says, and what it cannot tell you
Make says it commissioned a study of more than 1,200 business decision-makers. Its article reports that 84% of respondents were excited about AI creating smarter, adaptive processes, 80% expected AI to simplify complex workflows, and 82% believed AI-driven automation would free time for strategic and creative work. On agent autonomy, 64% believed AI agents could handle tasks without constant oversight.
The same article reports several concerns: 39% felt unprepared for AI-enabled workflows, 50% perceived uncertainty or disruption from the pace of AI integration, and 55% worried that limited human judgment in critical workflows could cause problems. These figures are reported by Make. They are not independently recalculated results or observed measures of productivity, agent accuracy, or adoption.
Make’s article does not publish the questionnaire, sampling method, respondent geography or demographics, fieldwork dates, denominator details, weighting, or margin of error. It therefore cannot establish that the findings represent businesses generally, or show how respondents interpreted terms such as AI agent and constant oversight. See Make’s survey summary for the vendor’s account of the findings.
Use the survey to identify a question worth testing, not to certify a workflow as ready. Before increasing autonomy, compare your own pilot with a reviewed baseline and document who owns exceptions.
The practical decision is local: identify one recurring process, record its current failure points, name its business owner, and choose a measurable outcome. Make argues that confidence may increase as agent capabilities and user familiarity develop. That is a prediction, not a measured longitudinal finding, so your rollout should generate the evidence for your own process.
Choose the right job for AI before choosing an agent
Define the job narrowly. Examples include classifying an incoming request, extracting candidate fields from an unstructured message, summarizing a case, or proposing a route from an approved list. A goal such as automate customer support is too broad to test, govern, or assign to an owner.
For exact conditions
Check required fields, match event IDs, confirm permissions, enforce monetary thresholds, validate dates, and allow only known status values with deterministic logic.
For interpretation
Use AI to interpret free text, summarize a case, or extract possible fields. Let rules, permissions, and where necessary a person decide what action is permitted.
The decision rule is straightforward: if a condition is stable and machine-readable, a deterministic rule is usually easier to test and explain than a model. If the input needs contextual interpretation, AI can propose a bounded result. If the result could materially affect a customer, payment, legal matter, safety issue, or account access, add a human decision gate or an explicit policy gate before the action.
When another module consumes the result, define allowed fields and values. A syntactically valid JSON response does not prove that the identity, meaning, authorization, or destination is correct. Make’s AI Agent configuration guide documents inputs, response formats, tools, and provider options. Provider availability depends on plan and connection configuration. The relevant implementation question is how those capabilities connect to your controls and system of record.
Set the baseline before the pilot. Useful measures include processing time, agreement with reviewed examples, invalid-output rate, exception rate, human correction rate, duplicate side effects, and unresolved exception age. Decide in advance which cases are acceptable for automatic handling and which must go to review.
Design the workflow as a controlled chain
Make documents a basic request-and-response pattern using Webhooks, a Custom webhook, the Run an agent module, and a Webhook response. The example receives a request, maps selected data and optional conversation context into the agent, and returns a response. It does not by itself establish authentication, business validation, an approval queue, CRM write-back, or duplicate protection. Those are production design requirements added around the documented demonstration. See Make’s webhook-triggered agent example.
For a hypothetical case-triage workflow, a support inbox event could reach a Custom webhook. The agent would propose a classification, sentiment, summary, and route. Deterministic checks would confirm that the customer and case match, the route belongs to an allowed set, the connected account has permission, and the event has not already been applied. Only then would a proposed CRM write-back occur.
Do not let the AI silently overwrite a newer human edit. Define the system of record for each field and use a version, timestamp, or freshness check before updating it. The following is an illustrative output contract, not a Make-published schema:
{
"source_system": "support_inbox",
"source_event_id": "msg_8f27",
"classification": "human_review",
"intent": "appointment_change",
"sentiment": "uncertain",
"confidence": 0.72,
"destination_record_id": "case_774",
"proposed_action": "notify_support_staff",
"prompt_version": "triage-v1",
"workflow_version": "case-flow-v1",
"agent_run_id": "run_20261016_001",
"review_status": "pending"
}The event-level record should be keyed by a stable combination such as source_system + source_event_id. Each execution attempt needs its own run-level record, such as source_event_id + agent_run_id. Do not collapse retries or operator corrections into the original event row. If the workflow also stores citations or extracted items, give those records their own grain, such as agent_run_id + citation_index or agent_run_id + item_index.
Validate that the event ID is present and has the expected format, the case belongs to the intended customer, classification and action values are enumerated, the destination is writable, and the proposed update is still fresh. Save the original input reference and failed validation reason when a case is routed to review. Teams defining CRM ownership and field rules can consult CRM systems and workflow design.
Two practical patterns: message triage and invoice extraction
The patterns below are hypothetical adaptations of documented capabilities and vendor-published case-study narratives. They show how to separate language interpretation from business validation. The named case studies illustrate problem types, not turnkey implementations or independent performance benchmarks.
| Trigger and data | AI responsibility | Validation and destination | Human fallback |
|---|---|---|---|
| Inbound customer message with source event ID, customer or case ID, message text, and received time. Illustrative chain: inbox event to Custom webhook to Run an agent. | Propose intent, sentiment, summary, and one route from an allowed list. | Match customer to case, check route values and permissions, then update a case or notify staff. CRM write-back is a proposed extension of the webhook tutorial. | Support operations reviews complaints, conflicting identities, low-confidence routes, legal or safety concerns, and sensitive matters. |
| Voice or text invoice request with source event ID, customer reference, requested items, quantities, and date. Illustrative chain: messaging input to transcription if needed to agent extraction. | Extract candidate customer, items, quantities, date, and missing information. Flag gaps rather than inventing values. | Match customer and item to authoritative records; validate quantity, price, tax, required fields, and duplicate status before document creation or accounting entry. | Finance or invoicing owner resolves ambiguous items, missing prices, tax questions, and customer mismatches before issuance. |
Make’s Stellantis &You case study describes a particular customer-message analysis and governance process, including the customer’s own privacy and provider-review work. It does not establish that Make automatically supplies that assessment for every customer. For invoice extraction, a Make-published farmer invoicing case study describes a specific voice-driven implementation using messaging, AI, document generation, storage, and spreadsheet elements. Its reported results belong to that case study and should not be treated as a general benchmark.
For message triage, the key implementation question is whether the source event identifies the intended customer and case before any notification or update. For invoice extraction, the key question is whether each product, price, tax field, and quantity can be confirmed against an authoritative record. These controls are different because the failure modes are different.
Prevent bad write-backs, duplicates, and unsafe retries
Use a stable event key such as source_system + source_event_id for event-level identity. Keep execution attempts separate because one source event may generate several agent runs after a retry or an operator correction. A clear model has one event record per source event and one run record per execution, linked by the event key.
Where the destination supports it, prefer an atomic upsert or a database-enforced unique constraint. A check-then-create sequence can race: two concurrent executions may both find no record and then both create one. Make Data Stores support explicit record keys, but their documentation does not establish that a separate existence check followed by creation is transactionally safe under concurrent execution. A stable key is useful, but uniqueness must be enforced by the write mechanism or destination when concurrency matters.
Make documents error handlers including Retry, and automatic retries for incomplete executions. A retry addresses an execution failure; it does not make a non-idempotent side effect safe. Before retrying an operation that sends a message, creates an invoice, or creates a record, ensure the destination recognizes the event key or route the operation through a system that enforces uniqueness. If that is not possible, require manual reconciliation instead of blindly repeating the action.
Store invalid and ambiguous results with the original input reference, proposed output, failed validation reason, and review status. A useful review queue gives the owner enough context to approve, reject, edit, or retry the item without reconstructing the original run.
Pilot, measure, and expand only when the process is ready
Start with a bounded and reversible task. Build a representative test set containing ordinary, ambiguous, incomplete, and adversarial inputs. Domain experts should define expected results and exception categories, then compare the AI output with those reviewed examples before downstream actions are enabled.
Make’s agent guidance recommends limiting the data exposed to agents and using human validation where appropriate. It also warns that agents may misinterpret or ignore guardrails. Review personal and sensitive data, provider settings, retention expectations, access permissions, and prompt-injection exposure before production. The required controls should be specific to the process rather than repeated as a general slogan.
- A reviewed baseline and acceptance thresholds exist for the specific task.
- Normal, ambiguous, incomplete, and adversarial cases have been tested.
- Invalid, sensitive, and consequential cases reach a named exception owner.
- Identity, allowed values, permissions, freshness, and required fields are checked before write-back.
- Concurrent and retried runs cannot create duplicate external side effects.
- Reviewers can see the source, proposed result, failed checks, and final outcome.
Track processing time alongside agreement with reviewed examples, invalid-output rate, human override rate, duplicate side effects, and unresolved exception age. Expand from review-only to limited automatic action only when the process meets pre-agreed criteria and can recover from exceptions.
Readiness is demonstrated by a tested process, a clear owner, and a recoverable failure path. It is not demonstrated by survey enthusiasm or fluent model output. Teams assessing a bounded agent use case can review AI agent design and implementation as a relevant next step.