Our best customer-support workflows lived in one teammate's local Claude Code. Anyone else who needed them had to ask him to run them.
Two changes fixed that. First we made one reviewed procedure available through a shared Runbear Agent. Then we let requests, events, and schedules start it, while the consequential decision stayed with a person in Slack.
The bottleneck was a person, not a tool
Our Customer Success work had become a set of practical skills: look up an organization, inspect an agent, trace a failed conversation, draft a Pylon reply, connect a support issue to engineering work.
They were good. They were also stuck. The skills ran in one operator's local environment, so every investigation depended on that operator being available.
Collecting them in an internal repository made them easier to review. It did not make them runnable by anyone else.
A workflow that only runs on one laptop is not a team capability. It is a personal advantage with a human dependency.
Stage one: share the procedure, not the workspace
We moved one reviewed SKILL.md into a shared Runbear Agent through an internal dogfooding path.
We deliberately did not clone the operator's environment. Scripts, settings, secrets, and session memory stayed where they were.
The narrow boundary is what makes the shared version reviewable: the team can see which procedure was shared and what was deliberately left behind. It also means the shared Agent needs its own connected tools and credentials rather than inheriting the operator's.
A shared skill still waits to be asked
That removed the person-shaped bottleneck and left a smaller one. Someone still had to notice the situation and remember to ask.
For recurring support work, the signal usually already exists somewhere else: in a connected system, or on a schedule.
Stage two: let the signal start the work
We gave the same procedure three supported ways to start: a teammate request, an event from a connected app such as a new Linear issue, or a schedule.
The start signal changes. The procedure does not, though each trigger arrives with its own permissions and its own level of trust.
Reversible, pre-authorized actions finish on their own and get recorded. A consequential action, like rolling back a customer's configuration, stops and waits for a person.
The handoff has to be a decision, not a notification
A ping that says something broke just moves the investigation back to a human. The useful handoff carries the finding, the evidence behind it, the recommended action, and the choices available right now.
Illustrative mockup of the Slack decision point, reconstructed from a real run. The agent proposes; the person decides.
The person is still in the workflow. Their attention just moved to the boundary where judgment and accountability actually matter.
We configured all of it in plain English
The shared runtime was set up from Claude Code through the Runbear MCP server, with no new local script and no separate console.
Illustrative mockup of the setup prompt and the Runbear MCP calls it made.
The MCP calls found the shared Agent, created the schedule, connected the Slack destination, and kept the approval boundary. The resulting configuration belongs to the shared runtime, not to one person's terminal history.
First share the expertise, then make it proactive
The order mattered more than the automation. Sharing the reviewed procedure removed the dependency on its author. Letting events and schedules start it removed the dependency on someone remembering to ask.
Together they turn a personal AI workflow into a team one without hiding the human decision.
The SKILL.md upload described here is an internal v0 dogfooding path, not the public setup flow. Today teams configure shared Agents, triggers, schedules, and Slack destinations through the Runbear MCP server in natural language.