# Viktor: AI Coworker That Lives in Slack Fryderyk Wiatrowski, Viktor | AI Engineer Europe 2026 | 19:30 Source: https://www.youtube.com/watch?v=ohKt066uFhg Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/viktor-ai-coworker-that-lives-in-slack Published: 2026-05-11 Tags: agents, chatbots, memory, team-adoption ## TL;DR - Viktor is built as a company-wide AI employee in Slack, with shared access to tools and context across the organization. - Scaling from one user's agent to many users requires memory isolation and rules that prevent context from one channel, team, or DM from leaking into another. - An agent's tone and personality can affect adoption even when another model performs well on tool calling, code generation, and cost. ## Summary Fryderyk Wiatrowski explains how Viktor evolved from browser and email agents into an AI employee that lives in Slack. The product has no separate web app. It joins channels and threads, uses company integrations, and can work on tasks while people change context. Wiatrowski focuses on what becomes difficult at company scale. Slack produces many kinds of input, including DMs, threads, edits, deletions, and emoji reactions, and the agent has to turn them into coherent conversations. Memory must be isolated across users, teams, and channels. Integrations also need careful scoping, especially after a customer accidentally shared a personal Gmail account with the whole team. Wiatrowski says personality affects whether people accept an agent, citing users' reaction when Viktor was tested with GPT 5.4 instead of Opus 4.6. He closes with three requirements for a coworker: it must complete work, know the company, and be friendly. ## Key ideas ### Viktor puts the agent inside the place where teammates already work [00:34](https://www.youtube.com/watch?v=ohKt066uFhg&t=34s) Viktor has no web app. It lives in Slack, participates in discussions, channels, and threads, and uses the tools available to the company. Wiatrowski says it has access to 3,000 integrations and can build connections when a needed integration is missing. This gives it broad context across the company rather than the narrower context usually held by one employee. He uses a CMO as an example: the person could be more effective with access to the codebase, and Viktor can contribute there as well as work in marketing systems. ### The product moved from browser actions to proactive tool use [02:10](https://www.youtube.com/watch?v=ohKt066uFhg&t=130s) The company first tried to build AI employees through browsers in 2023, when tool calling and code-generation models were less capable. Its JCAI system took a losslessly minified DOM snapshot and selected the next browser action, such as typing in a search field or clicking a login button. It worked for roughly three to five steps with 60% reliability, but errors compounded and each run was slow. The team later built an email agent after Sonnet 3.5 arrived. That agent could react to incoming mail, draft replies, call tools, and process a refund when approved. ### A company agent shares integrations instead of making every user connect them [05:37](https://www.youtube.com/watch?v=ohKt066uFhg&t=337s) Wiatrowski distinguishes a personal agent from a company agent. With a personal agent, each employee connects their own integrations. With Viktor, one person can connect an integration and the team can inherit its permissions, with the scope adjustable. This avoids asking every member of a 100-person company to connect the same service. Shared integrations also give Viktor a consistent source to use when it acts proactively. Without that setup, different users could connect different or incorrect accounts, leaving the agent unsure which integration to use. ### Company-wide memory needs boundaries between teams and people [06:42](https://www.youtube.com/watch?v=ohKt066uFhg&t=402s) An agent that works for 100 users cannot use memory like a personal agent. Wiatrowski says the same architecture would run out of memory 100 times faster, so memory management becomes a major problem. Slack adds access-control complications because the agent may appear in a growth channel, an engineering channel, an executive channel, and individual DMs. Context from the growth channel must not leak into engineering or support. A user's private DM should not pull in growth context unless that person belongs to the growth team. Conflicting instructions across channels make the problem harder. ### Slack makes long-running work feel more natural [08:39](https://www.youtube.com/watch?v=ohKt066uFhg&t=519s) Wiatrowski gives two reasons for choosing Slack. It makes Viktor feel like a human employee, since people interact with coworkers in Slack rather than in a separate web app. It also changes how users perceive latency. Difficult tasks can take ten minutes, which feels frustrating in a web app where someone is waiting for an answer. In Slack, a teammate who builds an app in ten minutes feels unusually fast. The same wait becomes more acceptable because the user can move on to other work. ### Slack interactions must be converted into one coherent agent context [10:13](https://www.youtube.com/watch?v=ohKt066uFhg&t=613s) Slack has more input modes than a conventional agent interface. Users can send DMs, write in public channels, reply in threads, react with emojis, edit messages, and delete messages. Viktor has to fit all of these events into a usable linear context. A deleted message may mean the task should stop. An edit should prompt a new response. Another problem occurs when someone starts a DM thread, forgets it, and later opens a new DM with the same person. Humans carry over the earlier context, but the agent may treat the new exchange as a separate task. Viktor therefore needs to find and roll earlier messages into the existing conversation. ### Users can reject a model because of its personality [12:05](https://www.youtube.com/watch?v=ohKt066uFhg&t=725s) The team tested GPT 5.4 against Opus 4.6, which they were using for Viktor. Wiatrowski says GPT 5.4 was cheaper and performed well at tool calling and code generation, but users reacted badly when the team ran the A/B test. They liked Opus and started complaining when it was replaced. He attributes this partly to personality and says Opus gives Viktor a somewhat sassy tone. The example shows why task performance and price do not determine whether people accept an AI coworker. ### Proactivity should be introduced after the agent has earned trust [13:06](https://www.youtube.com/watch?v=ohKt066uFhg&t=786s) Viktor can inspect a conversation and suggest a workflow. In a growth discussion about an A/B test, it could check PostHog and point out that the result was not statistically significant, then calculate why. That kind of intervention can make the agent useful across the workspace. It can also alarm a security team if the agent starts DMing people and joining threads immediately after being added. Wiatrowski recommends starting with a few users and rolling the agent out slowly. Proactive behavior should come after people understand how it acts. ### A coworker needs capability, company knowledge, and an approachable tone [16:24](https://www.youtube.com/watch?v=ohKt066uFhg&t=984s) Wiatrowski closes with three requirements for building an AI coworker. It must get work done, which he considers relatively easy with current models and integrations such as Pipedream. It must know the company by using Slack context well. The product also needs to feel friendly, because the team has to like interacting with it. He mentions the Slack approval process as a difficult practical step. His broader view is that companies will have AI employees, with cognitive work increasingly handled by machines. He ends by inviting the audience to add Viktor to Slack and test it with free credits. ## Notable quotes - "Viktor is an AI employee. And when you think of an AI employee, you should think of it as just like a human employee." (00:34) - "When someone deletes a message, a human assumes that the task should not be continued or it's not interesting anymore." (10:59) - "For some reason, our users loved Opus, and they all started raging when we did the A/B test." (12:25) - "Viktor is not a tool. It's a hire." (15:33) - "Make sure you're able to utilize this context well. You will probably need to go through the Slack approval process, which is very difficult and can be boring. And then make it friendly." (17:21) ## Tools & references mentioned - Viktor - JCAI - WebArena - ChatGPT - Sonnet 3.5 - Opus 4.6 - GPT 5.4 - Claude Code - Claude Co-work - PostHog - Pipedream - Gottfried Leibniz ## Who should watch - You are building an agent for a whole company and need to understand why personal-agent memory and permissions do not scale directly. - Your agent runs in Slack and must handle threads, DMs, edits, deletions, reactions, and conversations that restart outside the original thread. - You are considering a cheaper model and need to account for user reactions to tone and personality, not only benchmark or task performance. ## Related talks - [Agentic Workflows on Vertex AI](https://aietalks.com/talks/agentic-workflows-on-vertex-ai) (Rukma Sen, Google Cloud, 18:06) - [Form factors for your new AI coworkers](https://aietalks.com/talks/form-factors-for-your-new-ai-coworkers) (Craig Wattrus, Flatfile, 15:35) - [Multiplayer agentic engineering](https://aietalks.com/talks/multiplayer-agentic-engineering) (Arjun Singh, Superconductor, 18:44) - [Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment](https://aietalks.com/talks/collaborative-ai-engineering-one-dev-two-dozen-agents-zero-alignment) (Maggie Appleton, GitHub, 17:43) - [Creating Agents that Co-Create](https://aietalks.com/talks/creating-agents-that-co-create) (Karina Nguyen, OpenAI, 24:22)