Viktor vs Make: Canvas or Conversation?
Key Takeaways
- Make is a visual scenario builder. Viktor is a Slack-native AI coworker. They solve related problems in different shapes. Make is a canvas you draw on. Viktor is a teammate you @mention.
- Make excels at repeatable, structured pipelines. Trigger, scrape, enrich, write to a spreadsheet, send to HubSpot. If the steps are known and stable, the canvas is the right tool.
- Viktor excels at context-heavy, conversational work. Draft this email from the last 20 Slack messages, pull the churn signal from Stripe, open a Linear ticket with the exact repro steps. If the steps change every time, the canvas gets in the way.
- Review-first is the safer default for either tool. Both can take actions in your real systems. Viktor ships review-first out of the box. Make requires you to wire approvals in.
- Most teams end up running both. Make for the scheduled enrichment scenario, Viktor for the day-to-day operator work inside Slack.
The short version
Make is a no-code visual workflow builder (formerly Integromat, rebranded in 2022). You draw a scenario of modules (trigger, transform, write, send), wire them together, and schedule or trigger the result. It is a strong fit for teams that have already identified a repeatable process and want a visual canvas to run it.
Viktor is an AI coworker that lives inside Slack and Microsoft Teams. You @mention it the way you would a human teammate, it connects to 3,000+ integrations through real OAuth, and it drafts actions for a human to approve before acting.
The core question is not which product is better. The core question is what shape your work takes. If the work is a pipeline, use a canvas. If the work is a conversation, use a coworker.
A comparison across five real workflows
The easiest way to think about the difference is to walk through specific workflows a 20-person team actually runs.
| Workflow | Make | Viktor |
|---|---|---|
| Nightly enrichment of 2,000 leads from Apollo, write to HubSpot | Native fit, scheduled scenario on the canvas | Works but is overkill; Viktor is not built as a nightly job runner |
| Draft a follow-up to a customer from the last 20 Slack messages | Not a fit, no Slack thread-context layer | Native fit, reads the thread and drafts in the same channel |
| Post a weekly Stripe revenue report to the growth channel every Monday | Workable with a scheduled scenario and a Slack module | Native fit, Viktor drops the report in the channel and answers follow-up questions inline |
| Open a Linear ticket from a customer bug report in Pylon | Possible with a scenario wired to Pylon and Linear | Native fit, Viktor reads the Pylon thread and drafts the ticket with repro steps |
| Scrape 500 competitor landing pages and summarize their product pages | Native fit, iterator + HTTP module + AI text module | Workable but slower, Viktor handles it one at a time |
Neither tool wins the whole table. That is the point. Make wins the rows where the work is a batch pipeline. Viktor wins the rows where the work is a conversation inside a team's actual tools.
The builder model: canvas vs conversation
The biggest feature-level difference is how you describe a task.
Make asks you to draw it. You open the canvas, drag a module for "watch Apollo list," a module for "enrich via OpenAI," a module for "upsert to HubSpot," and wire them together. The scenario is explicit, visible, and editable by a teammate who opens the same canvas.
Viktor asks you to describe it. You @mention Viktor in a Slack channel, tell it what you want in plain English, and it proposes an execution plan in the thread.
@Viktor pull the 12 deals in HubSpot that entered the "decision-maker
meeting" stage this month, cross-reference with the Gmail thread
history for each deal, and draft a one-paragraph recap per deal for
our Monday sales sync. Format as a Slack message, not a PDF.
Viktor reads the request, pulls the HubSpot data, cross-references the Gmail threads, and drafts the recap in the same Slack thread. A sales lead reads it inline, edits two words, and ships it to the growth channel.
That is a workflow you would not build on a canvas. It is specific to this week, shaped by context only a human can name ("the decision-maker meeting stage," "our Monday sales sync"), and you do not expect to run it again next week the same way. Canvas-first tools ask you to invest before you know if the workflow is repeatable. Conversation-first tools let you try it once and find out.
The trust model
Both products take real actions in your production tools. How each one handles approvals is the most important question for any team running more than a pilot.
Viktor ships review-first by default. For any write action (sending an email, posting to Slack in another channel, creating a Linear ticket, pushing to HubSpot), Viktor drafts the action and waits for a human in the thread to approve. The action is logged with the approver's name. You see the exact payload before it lands.
Make gives you write modules inside your scenario. Approvals are something you wire in, usually as a human-in-the-loop step that posts to Slack and waits for a reaction before the scenario continues. That works once you set it up. It is not the default.
If your team is early in AI coworker adoption, default-on approvals matter. The Stanford 2024 AI Index reported a 32% year-over-year jump in publicly reported AI incidents, and the ones that cost the most money were agents running write actions without a human in the loop. We wrote about this pattern in our piece on why an AI agent that acts without asking is a liability.
Where each tool lives in your stack
A rough model for how teams end up using both products:
| Layer | Tool | Example |
|---|---|---|
| Scheduled batch pipelines | Make | Nightly Apollo enrichment, weekly competitor scrape, monthly churn-risk scoring |
| Conversational operator work | Viktor | Draft this email, pull this report, open this ticket, triage this alert |
| Shared dashboards | Notion, a BI tool, or a Viktor Space | The thing both tools write to |
The teams that get the most value run a Make scenario for the 5 batch jobs they rely on, and Viktor inside Slack for everything else. The canvas stays stable. The Slack conversations change every week. Each tool is in the shape that matches the work.
How Viktor handles the context problem
One practical gap: a Make scenario does not know that "our Monday sync" means the growth channel at 9 AM, or that "Lena" is our controller. Context lives outside the scenario, in the heads of the people who built it.
Viktor lives inside Slack, which means the context is native. Viktor reads the channel description, the pinned messages, the last 30 messages in the thread. When Lena drops a request, Viktor knows the last three asks she made, which integrations are wired up for her team, and which channel the report is supposed to land in.
This is not a trick. It is the feature of living where the work already is. Viktor does not try to replace a scheduled job runner. It does the work that used to belong to a junior operations hire: read the thread, pull the data, draft the action, wait for the sign-off.
Where this still breaks
Neither tool is a fit for every shape of work, and we flag the edges on purpose.
Make is the wrong tool for conversational work. If the request changes every time and the context lives in a Slack thread, a canvas is the wrong surface.
Viktor is the wrong tool for heavy batch pipelines. If you need to process 20,000 leads every night on a schedule, a canvas-based scenario runner is a better fit than a conversational agent. Viktor can run scheduled jobs, but large batch throughput is not its strongest shape.
Both tools are the wrong fit for workflows where an auto-executing agent is acceptable risk. If you want a fully autonomous agent that takes actions without a human in the loop, you should pick that tool deliberately and accept the incident risk. We do not recommend it for any team below 500 employees.
Gartner's 2024 generative AI forecast estimated that 30%+ of generative AI projects would be abandoned after proof-of-concept by the end of 2025. The common failure mode is a team picking a tool that does not match the shape of their work, then blaming the tool.
Which one to pick
A short decision guide:
- Your work is a repeatable pipeline with stable steps. Make is the right shape. The canvas pays for itself after the third run.
- Your work is conversational, context-heavy, and different every time. Viktor is the right shape. The Slack-native surface pays for itself inside the first week.
- Your work is a mix. Run both. Make for the 5 scenarios you rely on. Viktor inside Slack for the operator work.
- You have not identified which workflows are repeatable yet. Start with Viktor. Let the team @mention it for two weeks. The patterns that repeat will become obvious, and those are the ones worth moving to a canvas.
For teams still narrowing the shortlist, our 8-question checklist before you buy an AI agent covers the approval, audit, and integration questions that matter most before rollout.
Frequently Asked Questions
Is Viktor a Make alternative? Partially. For workflows that live inside Slack, yes. For nightly batch scenarios, Make is the better shape. Many teams run both.
Can Viktor run on a schedule? Yes. Viktor can run scheduled jobs, post recurring reports, and drive recurring workflows. The strongest fit is still conversational work, not heavy-volume batch processing.
Does Make work inside Slack? Make can send messages to Slack via the Slack module and trigger scenarios from Slack events. It does not run as a Slack-native agent that reads channel context the way Viktor does.
Which integrations does Viktor support? Viktor connects to 3,000+ integrations including Slack, Microsoft Teams, HubSpot, Linear, Stripe, Notion, Google Ads, Meta Ads, GitHub, Ashby, Pylon, SignWell, DocuSign, and the rest of the stack a 20-to-200 person team usually runs.
Does Viktor write to production systems without approval? No. Viktor is review-first by default. Every write action (email send, Slack post outside the current channel, ticket creation, CRM push) is drafted and held until a human in the thread approves.
How does the audit trail work for Viktor actions? Every action is logged with a timestamp, the input that triggered it, the proposed action, and the human approver. The trail reads the same as one produced by a human teammate.
Where should we start if we are new to both tools? Start with Viktor for two weeks inside one Slack channel where the team already does messy operator work. Watch the patterns. The ones that repeat cleanly are the ones worth moving to a Make scenario.
Viktor is an AI coworker that lives in Slack, connects to 3,000+ integrations, and does real work for your team. Add Viktor to your workspace.