Viktor — AI Coworker That Lives in Slack

What would an AI employee need to participate in the same workplace as everyone else? Fryderyk Wiatrowski, co-founder of Viktor, describes a February launch that began as an experiment and attracted unexpectedly strong adoption. His starting point is the interface: Viktor lives in Slack, without a separate web app to visit before asking it to work. It participates in channels and threads and uses company tools. Wiatrowski reports access to 3,000 integrations, with the ability to build connections when an integration is missing.

Those connections are meant to give the agent context across departments. Consider a CMO who could also understand and contribute to the codebase: marketing decisions could draw on implementation knowledge rather than stop at the boundary of the marketing team. That is the cross-functional ambition behind Viktor. Wiatrowski characterizes it as bringing PhD-level understanding across the company; the practical requirement is access to the information and tools needed to act across roles.

The team began pursuing AI employees in 2023, after ChatGPT appeared. In Wiatrowski’s account, their early implementation did not have the tool calling or strong code generation they would later rely on. Browsers offered a universal action interface: most business applications already had one. The original browser agent, called JAI in the talk, took a DOM snapshot, minified it without losing information, and combined that representation with the user’s goal to select the next action. It might type into Google’s search field or click a login button, then repeat the process against the next page state.

The loop worked, but useful tasks demanded more consecutive correct actions than it could reliably sustain. Wiatrowski recalls three to five browser steps with roughly 60% reliability in 2023. He does not define whether that percentage applies to individual steps or complete sequences, so it cannot support a compounded success calculation. He separately describes the agent as state of the art on WebArena. Even with benchmark progress, reliability and speed made a useful product difficult: a function call could return directly, while a browser agent might spend a minute navigating before failing. He also acknowledges that browser agents have improved since then.

With Sonnet 3.5, the team built its first agent loop and moved into email with Jace. The goal was to stop requiring a user to open another application and formulate every task. Incoming email already supplied both a trigger and relevant context. Wiatrowski reports that this product also found product-market fit and remained available at the time of the talk.

The email workflow is straightforward:

1. An email arrives and triggers the agent loop.
2. The agent connects to the relevant tools and interprets the request.
3. It responds with an email draft, a tool action, or both.
4. Where required, an approval gate precedes the action.

A refund request illustrates the difference between drafting assistance and operational work: the agent can actually issue the refund, with approval gating available. This progression—from navigating interfaces, to reacting to incoming work, to participating as a company employee—sets up Viktor’s move into Slack.

Viktor’s February launch extended that ambition from an individual assistant to a company agent. Wiatrowski uses OpenClaw as the personal-agent comparison. In the personal setup he describes, employees each connect their own integrations and run their own agents. With a company agent, one person connects an integration for the team, and the agent inherits its permissions, with adjustments available.

The convenience of connecting once introduces a harder state-management problem. Memory that becomes cluttered for one user faces much more activity when the same agent serves a team. Wiatrowski illustrates this with 100 users potentially exhausting the same memory 100 times faster—a scaling thought experiment, not a measured rate. He says the team solved its memory problem but does not describe the implementation.

Company hierarchy adds another dimension: users can issue conflicting instructions, and not everyone may access the same information. Growth-channel or executive-channel context must not leak into engineering or support conversations. In a DM, access to growth-team context should depend on whether the person belongs to that team. Shared context therefore needs boundaries at retrieval and use, not merely a larger memory. The talk establishes these requirements without supplying a channel-level authorization design.

Slack serves two purposes in this design. First, it makes the agent available through the same interface as a teammate. Second, it changes the expectations surrounding long-running work. A difficult task may naturally take ten minutes. After switching into a dedicated web app, waiting that long can feel frustrating, especially against the roughly thirty-second ChatGPT interaction Wiatrowski uses as his comparison.

Ask a coworker in Slack to build an app, however, and receiving it ten minutes later feels remarkably fast. The computation has not become faster; the interaction has become asynchronous in a familiar way. The interface changes the reference point for latency. A user can delegate work and continue elsewhere instead of treating the agent’s response as the next thing they must wait for on the current screen.

The familiar interface also creates implementation work. A typical agent web app presents one conversation at a time. Slack supplies DMs, public channels, threads, emoji reactions, and edited messages. All of those interactions can be inputs to the agent, but they must ultimately become a linear context the model can consume.

Message changes carry intent. Wiatrowski treats deletion as a signal that work should stop or is no longer relevant, and an edit as something the agent must respond to. That cancellation interpretation is an application policy: Slack’s message deletion event reports the deletion; it does not cancel an agent task automatically.

Continuity is subtler. Someone starts a thread in a DM, then forgets the thread and sends a new top-level message to the same coworker. A human usually understands that the conversation continues. An agent that opens a fresh task or sandbox for every new top-level message can lose that connection. Wiatrowski’s requirement is to inspect previous messages when a DM arrives and carry relevant context into the continuing conversation.

For a concrete implementation sketch, suppose the earlier thread says, “Prepare a report on the growth experiment,” and the new DM says, “Include the control group too.” Once the application has identified the relevant prior messages and checked access, a TypeScript context builder can preserve their order and origin:

type Message = {
  id: string;
  threadId: string | null;
  text: string;
};

function buildContinuationContext(
  prior: readonly Message[],
  incoming: Message,
): string {
  const messages = new Map<string, Message>();
  for (const message of [...prior, incoming]) {
    messages.set(message.id, message);
  }
  return [...messages.values()]
    .map(({ id, threadId, text }) =>
      JSON.stringify({ id, threadId, text })
    )
    .join("\n");
}

const prior: Message[] = [{
  id: "m1",
  threadId: "t1",
  text: "Prepare a report on the growth experiment.",
}];

const incoming: Message = {
  id: "m2",
  threadId: null,
  text: "Include the control group too.",
};

const context = buildContinuationContext(prior, incoming);

The new message retains its identity as a top-level DM, while the model receives the earlier request alongside it. Selecting the right prior conversation remains a separate responsibility; concatenating every DM would merely replace missing context with clutter.

Tone turned out to matter more than Wiatrowski expected. At the time of the talk, Viktor used Claude Opus 4.6 as its main model. The team tried GPT-5.4, which he praises for tool calling and code generation and describes as cheaper. That assessment made it an attractive replacement candidate.

Users reacted angrily during the A/B test and preferred Opus. Personality was one of several reasons the team did not switch. Wiatrowski allows that the preference could depend on Viktor’s architecture, and describes its Opus-based personality as somewhat sassy. The product consequence is concrete: a model can look promising on action-taking ability and cost yet make the coworker less welcome in the conversations where it must operate.

Viktor can proactively suggest workflows to automate. It can also intervene when a discussion appears to outrun its evidence. Imagine a growth team reviewing an A/B test and deciding that one option is performing well enough to adopt. With access to PostHog, Viktor can check the underlying analytics instead of accepting the conversational conclusion.

Wiatrowski reports occasions when Viktor checked PostHog, challenged the team’s conclusion because the result was not statistically significant, and supplied a calculation. The talk does not give the experiment data or statistical method. The distinctive behavior is the sequence: observe a discussion, consult the connected source, and contribute an evidence-based objection without waiting for an explicit analysis request. Helpful participation of this kind can lead users to enable the agent more broadly.

The same initiative can make an installation alarming. Wiatrowski describes security teams reacting badly when Viktor began DMing people and joining threads immediately after someone added it to a workspace. His rollout advice is to earn trust with a few users first, then expand. Permission to install an agent and acceptance of its proactive behavior are separate product problems.

Turning to comparisons with Claude Code and Claude Cowork, Wiatrowski emphasizes that Viktor runs in the cloud. In his comparison, Cowork operates on the desktop; Viktor does not require the user’s computer to remain open. That fits the expectation of an employee who can continue working after a request has been delegated.

Shared connections remove another source of friction. To ask Viktor to change a Meta ads budget or read analytics, one person can connect the company integration. In Wiatrowski’s hypothetical hundred-person company with a twenty-person growth team, that avoids asking twenty people to connect Meta ads separately. Separate personal connections also create ambiguity for proactive work: when several accounts are available, which one should the agent use? A shared company connection makes that choice clearer, provided its scope is appropriate.

Wiatrowski frames Viktor as a hire, then tells a customer story that reveals the limits of that metaphor. At an unnamed large US e-commerce brand, an administrator installed Viktor and connected personal Gmail as the first team integration. Teammates then began discussing the administrator’s emails with Viktor. The administrator complained that the product was leaking personal data.

Wiatrowski’s response was to ask whether the administrator would give a newly hired employee access to personal email. But the incident also prompted a product change: the team added scoped integrations, so connections were no longer necessarily shared. A user could connect a personal account and invoke it in a DM or publicly. The described change controls who can use a connection; the talk does not detail the enforcement mechanics or what information may safely be displayed in a public response.

Wiatrowski encourages the technical audience to build its own version, organizing the work around three requirements:

• Gets work done. He considers current models capable enough to act and recommends Pipedream for connecting integrations.
• Knows the company. Slack provides context, but the application must use it effectively. Distribution also brings the practical burden of Slack’s approval process, which he describes as difficult and tedious.
• Is friendly. The team must enjoy working with the agent. Mutual affinity is part of making it a recurring participant in company work.

These requirements join execution, context, and social behavior in the same product: connecting tools alone does not create a coworker people will keep involving.

The broader vision is that every company will employ AI workers. Wiatrowski connects that prediction to Gottfried Leibniz’s seventeenth-century work on calculators, treating the desire to mechanize calculation as an antecedent of today’s ambition to automate cognitive work. He argues that the opportunity now extends far beyond arithmetic, and closes the historical analogy with a quotation he attributes to Leibniz about freeing people from hours of calculation. It is a vision for the scope of automation, rather than an implementation claim about what Viktor can already do.

The recording ends with an invitation to scan the displayed QR code, select signup, and add Viktor to Slack. Wiatrowski offered everyone in the room $100 in free credits, with no strings attached. That was an audience-specific offer at the event. He said users could remove Viktor at any time and offered direct help if it failed to deliver value.