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.
