Reverse-engineering Viktor and making it Open Source

In the middle of February Zeta Labs announced Viktor, an AI coworker that connects to 3,000+ tools and "does the work".

Check out the announcement

It quickly gained popularity collecting millions of impressions on x.com. The team even claimed reaching 1M ARR in 3h [sic].

Driven by curiosity and envy, I tested it out.

It's not a review so I will skip the details, but my curious engineering mind had an idea:

Viktor happily creating a workspace backup, 164 files, 3 MB

Wait, sdk/ directory? logs/ directory? Surely it's just something that Viktor himself generated, I'm sure they don't just keep logs in agent's workspace.

Full backup, 12 MB, 944 files

Let's give it a look.

The SDK

sdk/ is Viktor's internal toolkit, the code the agent uses to interact with the outside world.

sdk/
  internal/
    client.py                    # HTTP client for the Tool Gateway
  tools/
    github_tools.py
    mcp_posthog.py
    slack_admin_tools.py
    viktor_spaces_tools.py
    ...15 modules total
  docs/
    tools.md
    available_integrations.json  # 3,141 lines
  utils/
    slack_reader.py              # parses local Slack history
    heartbeat_logging.py
    browser.py

All tool calls route through a single "Tool Gateway" at POST {TOOL_GATEWAY_URL}/v1/tools with bearer auth. The available_integrations.json is where the "3,000+ tools" claim comes from. Most are Pipedream-proxied third-party APIs.

The Logs

16 days of daily global.log files. Structured entries with timestamps, routing paths, and event types like [webhook], [slack_received], [slack_sent], [task_triggered].

[2026-03-12 08:57:08] [/slack/Mateusz Jacniacki/...] [webhook] dm from DM
[2026-03-12 08:57:40] [/agent_runs/slack/.../threads/...] [slack_sent] Hey! Yep, I'm here.
[2026-03-12 08:08:42] [/heartbeat] [task_triggered] Scheduled task triggered

You can trace entire conversations end-to-end, from the user's Slack message arriving as a webhook to the response being sent back.

The Skills

19 folders, each with a SKILL.md.

skills/
  workflow_discovery/   # 6-phase process for finding automation opportunities
  viktor_spaces_dev/    # full-stack Convex+Vercel app builder
  codebase_engineering/
  browser/
  remotion_video/
  pdf_creation/
  ...19 folders total

Okay, prompts, great. Are they any interesting? Surprisingly... yes. As an example workflow_discovery contains a full 6-phase recipe for mining business processes out of Slack conversations, something that definitely required time and experiments to tune. It's hardcoded business logic, but in prompt instead of code.

So What?

So far the things we discovered look innocent. Yes it lights up a warning sign in my head that I can access logs with such ease. But it makes sense, Zeta Labs wanted to give Viktor as much ability as they can, including ability to debug itself.

There is nothing truly remarkable in the workspace, no API keys, no data of other users. The system was designed to give the agent this information, it shares a lot, but that was the point.

At this moment I had a realization. I have most of the prompts Viktor uses, I know its workflows, I have API endpoint schemas and error logs. I can learn a lot about the design of the system based on that.

So naturally I dumped all files into Claude Code and dug into it.

Generated architecture diagram of Viktor

Woah! It's very detailed, but I have no idea how much of it is guessed vs based on real information, so from that point on I directed Claude to gather supporting evidence for all claims he made about Viktor.

Soon enough Claude also found the getviktor website, and on it in plain sight were technical blogs.

Again a common practice in the world of SaaS and AI, it's innocent until someone actually wants to reverse-engineer your whole system.

After a few iterations of this I had a detailed specification of Viktor's architecture, infrastructure, internal workflows, API schemas, prompts, error handling strategy... Everything.

I bet I have better documentation of Viktor than Zeta Labs at this point, and it took me 2 hours.

Reverse-engineered documentation, architecture diagrams, API references, deep research reports

My curious engineering mind had the next natural temptation: implement it. Implement the whole system based on the docs we gathered.

So I ran with it.

The main question I wanted to answer was if it was even possible. Yes, the docs look promising but I have no idea if they actually cover the system in enough detail to reimplement it. And even if yes, how hard is it really to recreate the whole thing.

I will spare the details of my coding workflow (I already made this sin 6 months ago, ages like milk), every heavy user of coding agents knows how to take it from here, using their favorite tools and practices.

OpenViktor

After two days of coding, debugging and spelunking I had a final version.

You can self-host it with a single setup script.

To make trying it out easier I also deployed a managed instance, free for everyone, limits apply though

github.com/zggf-zggf/openviktor