You have probably thought about giving your team an AI teammate. What usually stops people is not the setup. It is the blank page. "Answer questions" is not a job, and it is hard to write a job description for something you have never watched work.
Viktor and Runbear both answer that with an MCP server for Claude Code, and they answer it very differently. We build Runbear, so the framing here is ours; the capabilities below are linked to their sources at the bottom.
| If this is you | Fits | Because |
| A teammate already answers in your Slack and you want your code to reach it | Viktor MCP | The agent exists. You need a door in, not a builder |
| You have no teammate yet and you are not sure what it should do | Runbear MCP | You can assemble one without deciding the whole job first |
If the second row is you, that install is one line:
claude mcp add --transport http runbear https://api.runbear.io/mcp/ccAdding the server writes one line to your client config and nothing else. The first Runbear command opens a sign-in, with no key to paste. Runbear bills for the model work a task actually uses rather than per seat: Team is $79 a month for 20,000 credits and 5 builders, Business is $319 for 100,000 and 10, with no markup on model costs. The MCP server is in early access and its tool set is still expanding.
Viktor is for teams who already know what the teammate does
Viktor is a finished AI employee that works in Slack and Teams. You hire it, and it answers your team where they already talk. Its MCP server is the door in from your own code: one ask_viktor call opens a thread, runs it, waits, and returns the answer, or you can drive those steps yourself for longer work. Thirteen tools cover that surface, a request can ask for the answer in a fixed JSON shape, and a scoped API key decides which of the thirteen your key even sees. You are using the teammate, not building it. If that is the job, Viktor MCP is the better fit and nothing below changes that.
Runbear is for people who work it out while building it
Runbear is for the person staring at the blank page. Say the job is billing triage: decide whether an incoming message is about billing, find who owns that account, answer the easy ones and escalate the rest. You do not have to settle all four before you start. You describe the mess in Claude Code, get asked back about the parts you have not worked out, hand over any skill folders you already wrote, and say when and where it should answer. The spec and the agent get finished at the same time.
A form makes you decide first. A conversation lets you decide as you go.
That is the difference, and it is structural. A settings form cannot accept a half-finished answer: every required field has to be filled before anything is saved. A conversation can. You start with the part you are sure about, get asked about the rest, and change your mind about one piece without redoing the others. Below is one session in three frames, same terminal each time, further along.
1. The rule gets settled mid-conversation
The request goes in unfinished on purpose, and a form would have to reject it. Claude Code asks back instead. Here the answer happens to be an existing skill; if you have none, the same question is answered by describing the rule in a sentence.
2. Capabilities go on one at a time
Nothing was restarted, so the frame above is still on screen. Each skill goes on by itself, so changing your mind about one does not undo the rest.
3. The schedule is a sentence, and then it ships
"Run it every weekday at 9am" replaces a five-field cron widget, and the channel is the line after it. Neither was decided before the session opened.
It only enters a channel on the turn you name one
Worth knowing before you try this on a work laptop. Both products gate Slack access, at different points. Viktor sees a channel only once it is invited there. Runbear splits it one step further: building an agent and putting it in Slack are separate scopes, write:agents and deploy:agents, so you can build, run and fix it with nothing in a channel at all.
| Step | What happens | Who can see it |
| Add the MCP server | A line is written to your client config | Nobody |
| Build and change the agent | It lives in your Runbear org, undeployed | Nobody outside your Runbear org |
| Read its execution trace | You see what it actually did | You, if you are an Admin or Owner |
| Deploy it to Slack | It goes live in a channel | Everyone in that channel |
One caveat. If your request already names where the agent should answer, the deploy runs in that same turn, as the third frame shows. To keep it out of Slack, leave the channel out of the sentence.
You describe the outcome; Claude Code picks the tools
This is where the two servers meet the same moment from opposite sides. With Viktor, your code names the call. With Runbear, you write the outcome and the calls are chosen for you:
You wrote the first line. Five calls ran under it, from create_agent to deploy_to_slack, and you named none of them. Because that sentence named #standup, the deploy is part of the same turn. The Zoom event comes from the Pipedream catalog that Runbear resolves against, so it fires for meetings you host.
Illustrative example below, composed to show the shape of the output.
What each one cannot do yet
Runbear: two things still need the Runbear dashboard, advanced model settings and knowledge-base sync, and a scheduled job can currently post only to Slack channels and DMs. Creating the schedule itself is a chat command. Uploading a skill folder takes a second plugin, skill-uploader, and it only uploads to agents built on the Claude Agent SDK. Viktor: its MCP server does not create or configure an agent, so there is nothing to assemble from your terminal.
Try it, and back it out in one line
Add the server:
claude mcp add --transport http runbear https://api.runbear.io/mcp/ccThen say this in Claude Code:
Create a Runbear agent called Billing Triage that answers in a friendly, direct voice
and escalates billing questions to whoever owns the account. Then show me what you made.If you would rather not keep it, one line removes it:
claude mcp remove runbearSources, observed 2026-08-07: Runbear MCP reference — OAuth, scopes, tool list and limitations · Runbear Agent Skills — the Claude Agent SDK requirement for skill uploads · runbear-io/skills, for the skill-uploader plugin · Runbear pre-built MCP servers, for Granola · Runbear pricing, for credits, plan prices and builder caps · Pipedream zoom-meeting-ended, for the trigger and its host restriction · Claude Code MCP docs, for add and remove · Viktor MCP server, for the thirteen tools, structured output and key scopes · viktor.com, for what Viktor is. Viktor is described from its published tool set. viktor.com, the AI employee in Slack and Teams, is a different product from VIKTOR.AI (viktor.ai). Terminal frames are real sessions; the Slack frame is labelled as illustrative where it appears.