Choose an AI agent platform by the controls your workflow needs and the systems your team already operates, not by the size of its feature list. Use a visual automation platform when operators need to see cross-application flows, an ecosystem-native builder when identity and business data are centered on one suite, or a developer framework when engineers need code-level control of state and execution.
This is a decision guide, not an independently tested ranking. Vendor documentation supports descriptions of vendor-stated capabilities and billing models, not comparative claims about reliability, accuracy, or value. The Make publisher’s comparison ranks Make first according to its own criteria. That is editorial opinion, not independent evidence. The live canonical article is dated June 17, 2026, although extracted metadata shows different dates.
An AI agent platform is software for building and operating systems that use context and tools to complete tasks. A conventional workflow can include a model call without being meaningfully agentic. The practical selection question is whether AI must interpret ambiguous information or choose among permitted next steps, rather than merely apply explicit rules.
How to choose an AI agent platform for production work
Start with the source event and system of record. Then decide whether the task needs semantic interpretation, stateful orchestration, or only deterministic automation. A rule such as routing Enterprise customers to a designated queue does not need an agent. Interpreting a varied customer message to identify its issue may benefit from AI, followed by fixed routing and authorization rules.
Write the job in one sentence, list the allowed tools, define the output fields, and specify what happens when information is missing or confidence is inadequate. The platform is a consequence of that design, not the starting point.
Make documents agent construction, app modules, scenarios, tools, custom response structures, testing, and run inspection in its official setup guide. Its product page also describes a Reasoning panel and manual approvals or stop points. These are documented mechanisms, not proof that a particular workflow is validated, idempotent, or safe to deploy. Verify the edition, provider connection, connector, and deployment requirements. Make automation services may be relevant when the workflow needs implementation support.
Start with the workflow, not the platform shortlist
Use deterministic rules when conditions and outcomes are explicit, finite, and consequential: reject an event already processed, route by account tier, or create a task when an invoice becomes overdue. Use AI for variable or unstructured inputs such as classifying an email, extracting fields from a document, or summarizing a request. Pass the result through fixed validation before any business action.
Do not let an agent authorize a payment, decide access rights, delete records, or make irreversible status changes. It may propose an action, but a policy check or authorized person should determine whether that action is permitted. Low-confidence, malformed, stale, or policy-flagged results should become explicit exception states rather than silent guesses.
Use AI to interpret variable meaning; use deterministic rules to authorize and execute consequential changes.
Compare platform models by operational fit
Product names, packaging, connectors, and entitlements change. Compare the operating model first, then verify the exact product edition against the workflow.
Visual automation
Make and n8n
Consider these when a workflow crosses business applications and operators need a visible flow. Make documents agent tools, scenarios, structured responses, knowledge, and run inspection. n8n offers hosted and self-hosted options, but its free self-hosted Community Edition uses the Sustainable Use License and some commercial use cases require a commercial license. Verify connections, permissions, and operational controls.
Ecosystem-native builders
Microsoft, Salesforce, and Google Cloud
Microsoft Copilot Studio is a candidate for Microsoft-centered environments, Salesforce Agentforce for Salesforce-centered CRM work, and Vertex AI and related Gemini capabilities for teams already operating in Google Cloud. OpenAI tools may suit teams designing around OpenAI models and APIs. These are stack-fit observations, not claims that the products only work within those ecosystems.
Developer frameworks
LangGraph and CrewAI
LangGraph documents stateful orchestration, persistence, durable execution, streaming, and human-in-the-loop capabilities. CrewAI distinguishes autonomous Crews from structured, event-driven Flows. These approaches offer code-level control, with more responsibility for hosting, integrations, permissions, testing, and operations.
These categories are not interchangeable. A framework can provide orchestration primitives without supplying a managed business-app workflow. A workflow platform can expose useful agent features without proving that its default configuration meets transaction, audit, or data-residency requirements.
OpenAI announced AgentKit, but Agent Builder is scheduled to shut down on November 30, 2026. New architecture should assess the Agents SDK, Workspace Agents, and ChatKit against the use case instead of making a long-term design depend on Agent Builder. Google Cloud product names and entitlements are also changing, so verify the exact Vertex AI or Gemini product at selection time.
For any shortlisted product, confirm the connector, identity model, permissions, deployment arrangement, output contract, approval path, logs, export options, and edition-specific limits. Do not describe n8n simply as open source, and do not describe Make categorically as having no on-premise option: its current offering includes an on-prem agent capability for accessing local networks, which is distinct from self-hosting the full Make platform.
Evaluate the controls that make an agent usable
A successful demonstration is not a production test. Require a typed output contract when downstream steps depend on stable fields. Make documents custom data-structure responses; otherwise, add an explicit parsing and validation step before any business action. Check required fields, allowed values, source identity, evidence references, and policy flags.
Test the complete execution path: input, model and tool calls, output, errors, retries, and final write-back. Confirm which run evidence the selected edition retains and who can inspect it. An approval should show the target record, proposed before-and-after values, evidence, reason, approver, and expiry. Assign an owner for rejected, stale, or timed-out work.
Idempotency must be tied to the source event, not a date or prompt. A proposed event key is source_system + source_event_id. Protect it with a database uniqueness constraint or transactional upsert where concurrent runs are possible. A read-then-create check alone can race: two executions may both find no record and then both create one. Recheck the target record version before applying a proposed update.
01Identify the eventRecord the source system and stable source event ID. The integration owner confirms that retries can be recognized.
02Bound the AI taskSpecify what the model may classify, extract, or recommend, and which tools it may call. The workflow owner defines the boundary.
03Validate the resultCheck the schema, allowed values, evidence, and policy conditions. Malformed or ambiguous results go to a named exception owner.
04Protect the writeEnforce idempotency, apply deterministic authorization, and require approval for high-risk changes. The system-of-record owner defines the allowed transition.
05Inspect outcomesReview evidence, completed writes, failures, retries, review rate, and cost per completed event. The operations owner decides whether the pilot passes.
Compare costs at the business-event level
Normalize cost to a successfully completed source event, not a headline plan price. Estimate event volume, agent runs per event, model and tool calls, retries, retrieval or grounding, human review, failed writes, and duplicate attempts. Test the same representative workload and a high-usage scenario across finalists.
The meters differ. Make uses credits, with AI usage affected by provider and configuration. Microsoft Copilot Studio uses Copilot Credits across usage categories. Google Cloud bills model tokens and applicable grounding. OpenAI pricing is model and tool specific. Salesforce describes Flex Credits, conversations, and user-license options. LangSmith uses seats and trace-related usage. n8n uses executions, while self-hosting adds infrastructure and operations costs. Consult the live vendor pages immediately before purchase.
Five questions for every finalist
- What exact unit is metered, and what did the pilot cost per successfully completed source event?
- Can operators inspect inputs, tool calls, errors, retries, outputs, and write-back in the required edition?
- Can concurrent delivery be handled with an idempotency key, uniqueness constraint, or transactional upsert?
- Who owns malformed output, approval timeouts, stale records, and unavailable destinations?
- Does the estimate include model use, platform charges, review time, infrastructure, and likely retries?
Three implementation patterns to test against your shortlist
These are hypothetical designs, not vendor templates or reported customer implementations. Confirm that the chosen product and edition can access the required source and destination. Keep event records, execution attempts, and model observations at separate grains: one source event has a source_event_id, each attempt has a run_id, and each model call has run_id + step_id + attempt_number.
1. AI-assisted intake with deterministic routing
Sequence: new support email, web form, or ticket event → normalize fields and preserve the event ID → AI classifies the request and extracts relevant details → validate the structured result → deterministic rule routes or creates the ticket. The support system remains the system of record.
A proposed output contract might contain:
{
"source_system": "support_inbox",
"source_event_id": "evt_8f21",
"classification": "account_access",
"confidence": 0.93,
"recommended_action": "route_to_account_support",
"requires_human_review": false,
"policy_flags": [],
"schema_version": "1",
"run_id": "run_20261016_103002"
}
The values are illustrative. Validate that the event ID matches the input, required fields exist, and classification and action belong to allowed lists. Enforce uniqueness on source_system + source_event_id before creating a ticket. If the output is malformed, ambiguous, low-confidence, or policy-flagged, retain the original message and send the case to the support operations owner.
2. Knowledge-grounded document handling
Sequence: an approved document is added or revised → record its source URI, version, checksum, and access classification → update the approved knowledge source → answer an authorized request using accessible material → validate citations and access → return the answer or route it to the document owner.
Make’s official guide documents knowledge uploads, supported file examples, and a separate knowledge-management scenario so unchanged material is not uploaded during every main workflow run. That guide is implementation documentation, not an importable finished workflow. Store the request ID, document ID and version, evidence references, unresolved status, and run ID separately. If a document is missing, stale, or inaccessible, return an unresolved result rather than allowing the model to infer permission to disclose restricted content.
3. Human-reviewed CRM update
Sequence: an inbound customer message suggests a change → retrieve the target CRM record and version → AI extracts a proposed field change with evidence → validate the field and permitted transition → show before-and-after values to an authorized approver → recheck the record version → apply an idempotent update after approval.
The CRM remains the system of record. Save the source event ID, target record ID, retrieved record version, proposed changes, evidence, approval decision, approver, write result, and destination record ID. If the record changes before approval, reject the stale approval and return it to the CRM data steward. If a write is retried, use an idempotency key protected by a uniqueness constraint or transactional upsert. CRM systems consulting may help when system-of-record ownership and field governance need clarification.
Separate evidence by row grain
Many agent projects become difficult to audit because one record mixes events, runs, model calls, citations, and period-level metrics. Keep these grains separate:
- Source event: one message, webhook, ticket, or CRM change, keyed by
source_system + source_event_id.
- Execution attempt: one workflow run, keyed by a workflow version, source event ID, and
run_id.
- Model observation: one model request, keyed by
run_id + step_id + attempt_number, with provider, model, prompt version, tokens, latency, and outcome.
- Citation: one document or source reference attached to a response, keyed by run and citation sequence or canonical source hash.
- Aggregate: one entity, model variant, query set, and reporting period. Do not store period-level usage or quality totals in an individual event row.
Multiple citations in one answer, multiple runs on one day, or changed model variants can collide when an identifier uses only a URL, date, or prompt. Use database-enforced unique indexes or transactional upserts where concurrent writers are possible. A lookup-then-create sequence is not sufficient.
A practical shortlist and next step
Choose two or three candidates by existing stack and operating model. Run the same representative workflow in each, including duplicate delivery, malformed output, an unavailable destination, a changed source record, and an approval timeout. Treat mandatory controls as pass or fail first; compare usability and measured cost only among candidates that pass.
Ask each vendor to demonstrate permissions, logs, retry behavior, approval mechanics, data handling, and export or migration options in the exact edition you would buy. Keep prompts, schemas, evaluation cases, and tool contracts versioned outside a single visual builder where practical. Product names, prices, limits, licensing, and features can change, so verify them immediately before purchase.
Choose the platform that can perform the bounded task, preserve event identity, validate its output, prevent repeated writes, and give a named person ownership of exceptions. If you need help defining those boundaries or planning implementation, see AI agent implementation services.
