Make’s Waves ’25 sessions point to a practical discipline for AI automation: start with a defined process problem, test within clear limits, and add shared controls before a workflow scales. For example, a support team might use fixed rules to check a case ID, ask AI to suggest a category for ambiguous text, validate that suggestion, route uncertain cases to a person, and only then update the CRM.
Waves ’25 took place on October 15 and 16, 2025. Make published its recap on October 24, 2025. The official session recap is Make’s account of selected sessions, not an independent evaluation or a technical build guide. The event replay page provides related event material, but neither page supplies complete blueprints for the examples described.
This article turns those themes into an operator’s guide. The governance rules, field contracts, and workflow sequences are editorial recommendations unless explicitly identified as Make-documented capabilities.
What is the practical takeaway from Waves ’25?
Use a simple decision sequence: define the business problem, choose rules, AI, or a combination, test with bounded access, validate outcomes, and assign an owner before production. Use AI where interpretation is useful, such as classifying ambiguous text. Use deterministic rules for exact matches, required fields, approved values, thresholds, permissions, and known status codes.
That approach reflects the recap’s themes of learning from failed attempts, balancing experimentation with governance, iterating, building reusable components, educating employees, and keeping people involved where judgment matters.
A workflow is ready to scale only when its business owner, validation rules, failure path, and destination are as clear as its happy path.
Start with the process problem, not the AI tool
Before building, write down what starts the process, who handles it, which systems are involved, what information is used, where exceptions occur, and what outcome should improve. Then frame one measurable question, such as whether a limited test reduces time spent routing support messages without increasing misrouted cases.
In Make’s recap, Sara Maldon said she was comfortable describing 90% of her early projects as failures. Treat that as her statement as reported by Make, not a general failure rate or a benchmark for other teams. The operational lesson is to make early experiments small and reversible: set a baseline, choose a limited test population, name a stop condition, and keep the existing process available if the test fails.
Make also reports a FranklinCovey customer-story result in which one HR process fell from about 30 days to 2 hours. Those are Make and FranklinCovey reported figures, not independently audited results. The FranklinCovey customer story provides additional context, but not a reusable, module-by-module workflow.
Choose the right kind of automation
- Exact matching: use rules to route by a known case ID, email address, or status.
- Required-field checks: use rules to reject a request missing its record ID or other mandatory value.
- Ambiguous text: use AI to suggest a category or extract a field for review.
- High-impact changes: combine deterministic checks with approval before changing a sensitive record.
The experiment owner should record one baseline measure, the test group, a stop condition, and the route back to the current process. A failed test is useful only if the team can see what was tested and decide what to change next.
Use hybrid governance: experiment locally, standardize what scales
In the governance panel summarized by Make, speakers contrasted centralized controls with broader employee experimentation. They described trade-offs rather than quantified performance comparisons. Central review can support consistent access and data controls but create bottlenecks. Local experimentation can address specific needs quickly but produce variation and more maintenance work.
A practical rule is to match review effort to risk. A read-only test using low-sensitivity data may start with lighter review. A workflow that handles personal or financial data, publishes externally, deletes records, or makes irreversible changes should receive centralized review before activation. When a prototype works, record its owner, source and destination systems, permissions, data handling, failure route, volume limits, monitoring, and rollback approach.
Make documents subscenarios that a parent scenario can call with defined inputs and structured outputs. That capability can separate repeated business logic from a larger workflow. It does not replace documentation, testing, ownership, permissions, or change control. For help moving a Make prototype toward a governed workflow, see Make automation consulting.
Build an AI-assisted workflow with controlled writeback
Consider this a hypothetical pattern, not a workflow demonstrated at Waves ’25. A new support message arrives through a configured source-app trigger in Make. The scenario passes the message and source record ID to an AI step for a proposed classification. Subsequent steps check the output against a defined schema, permitted categories, and business rules. A reviewer handles uncertain or high-impact cases. Only an approved and validated proposal is written to the CRM. The exact trigger and app connections depend on the systems selected.
- Capture the source: retain the source system, record ID, timestamp, and original message or a suitable reference to it.
- Ask for a bounded proposal: request a category from a fixed list, not an unrestricted decision about what action to take.
- Validate with rules: check required fields, allowed categories, confidence threshold, current record state, and applicable business policy.
- Route the decision: send uncertain or consequential cases to a human review queue. Write back only when required checks and approvals pass.
- Keep traceability: store the source ID, proposed value, validation result, reviewer decision when applicable, and final outcome.
An illustrative contract for one classification observation could look like this:
{
"source_record_id": "case-illustrative-1042",
"source_system": "support-platform",
"source_timestamp": "2026-10-17T09:30:00Z",
"classification": "billing",
"confidence": 0.87,
"proposed_action": "set_case_category",
"validation_status": "needs_review",
"review_status": "pending"
}The sample represents one raw classification observation, not a daily aggregate, CRM contact, deal event, or audit summary. If several model runs process the same source record, add a run identifier, model identifier, and prompt version so each observation has a distinct grain.
Make documents structured scenario inputs and outputs, but a data contract does not verify business meaning or grant permission to update a record. Make’s documentation on scenario inputs and outputs describes the contract capability. Confirm ownership, field permissions, current-record checks, and the appropriate update method with the system owner. CRM systems consulting is relevant when that design spans teams or platforms.
Valid JSON proves only that a response fits a format. Before a CRM update, verify the source record still exists, reject unknown categories, compare the proposed value with the current destination state, and require approval when the change is uncertain or consequential.
Make distinguishes standard scenarios, which follow fixed rules, from AI and AI-agent scenarios, where AI has a role in the workflow or determines a path. That distinction helps teams choose a bounded AI task rather than defaulting to an agent. Make’s scenario-type documentation describes the product distinction. It does not show that an agent is more accurate or suitable. For teams assessing a broader agent design, see AI agent consulting.
Iterate without creating fragile workflows
Rapid prototypes can make a process easier to test, but a successful test is not automatically maintainable. Make’s recap describes a Vercel demonstration pairing an AI-assisted front-end development approach with Make automations. It does not identify a complete integration recipe, exact product configuration, or enough detail to reproduce that build. The useful operational point is to test small changes and make the workflow understandable to the people who will operate it.
Make documents subscenarios that a parent scenario can call, with defined inputs and structured outputs. Synchronous and asynchronous execution are documented options. A reusable component might accept a customer ID and return found, not_found, rejected, or error. Those distinct results let the parent route a missing customer differently from a failed connection.
For event-driven writes, use a stable source event identifier and make repeated processing harmless or detectable. For an event-grain record, a proposed key is source_system + source_event_id + operation_type. If one event contains multiple citations or child records, add the citation or child identifier rather than reusing the event key for every row. A daily aggregate needs a different grain and should include dimensions such as entity, date, engine, model, prompt set, geography, and aggregation version.
Retries and incomplete-execution handling can help recover from certain failures, but they do not guarantee exactly-once processing. A lookup followed by a create can race if two executions arrive together. Where concurrent writes matter, prefer a destination-side unique constraint and transactional upsert when available. Make documents keyed Data Store records and an Add/Replace a Record operation, but that documentation does not establish race-safe lookup-then-create behavior under concurrent writers.
Make learning and human judgment part of the operating model
Access to an automation tool does not establish process knowledge, permission to use sensitive information, or production readiness. Make Academy is a free, self-paced learning platform with material on automation and AI agents. Course availability and access terms can change.
Make’s recap also reports a speaker’s onboarding anecdote about a new hire automating what the speaker characterized as thousands of hours of work per month. The recap does not provide a measurement method, so treat this as an attributed anecdote, not a forecast of training results.
A sensible learning path pairs a relevant course with supervised practice: build a low-risk workflow, test its failure route, document its owner and data access, and obtain process-owner approval before activation. Keep human review for uncertain classifications, exceptions outside defined rules, and decisions with material impact. Make Academy’s learning platform and its AI agents foundation course are optional learning resources, not production-readiness certifications.
Measure reliability and keep the human purpose in view
Set a baseline and review period before launch. Choose measures that match the workflow: time to first useful result, manual exception rate, duplicate-write incidents, unresolved failures, queue delay, human-review rate, and maintenance effort. Track ownership and provenance alongside throughput, so a fast process is not mistaken for a dependable one.
For high-volume or instant-trigger scenarios, also monitor queue delay, rejected payloads, rate-limit responses, and unresolved incomplete executions. Make documents rate limits and incomplete-execution handling, but actual behavior depends on the trigger type, scenario settings, capacity, and destination application.
Speakers from Meta and Webflow offered perspectives on AI’s relationship to people, creativity, and changing patterns of discovery. Make’s recap presents these as session viewpoints, not proven performance advantages or a product forecast. For operations teams, the practical principle is narrower: automate repeatable work, preserve human judgment where uncertainty or impact warrants it, and revisit the process when conditions change.
- A baseline and review period are recorded.
- A process owner and an automation failure owner are named.
- The record grain and duplicate-handling strategy are explicit.
- Exceptions have a defined route and responsible person.
- Human-review thresholds are explicit for uncertain or consequential changes.
- A pause or rollback condition is documented and tested.
Waves ’25 points toward a practical discipline: experiment within limits, learn from evidence, and promote only workflows whose ownership and operating controls can keep pace with their benefits.