The most useful support automation at Runbear did not begin as a platform project. It began on one operator's laptop.
The procedures were practical: inspect an agent, trace a failed run, prepare the daily support queue, connect a conversation to the right account, and record a learning before it disappeared into chat history. They worked because they captured the judgment our customer success team used every day.
They also had a serious limitation. A procedure that only one person can run is not an operating system for a team. It is personal leverage.
We moved selected procedures into a reviewed internal toolkit, then used Runbear's shared-agent dogfooding path to make the right workflows available beyond the original machine. The result is not a promise that every support task should be autonomous. It is a repeatable boundary for turning proven operating knowledge into a shared AI capability.
The problem was not missing knowledge
Support teams already have playbooks. The problem is that the real playbook is rarely in one place.
Part of it lives in documentation. Part of it lives in saved replies, Slack threads, ticket macros, and internal dashboards. The most valuable part often lives in an experienced operator's sequence of actions:
- Check the customer and organization context.
- Inspect the relevant agent or workflow.
- Review recent traces before changing anything.
- Decide whether the next step is investigation, remediation, escalation, or a customer reply.
- Record the result where the next operator can find it.
An AI agent can help with this work, but a long prompt is not the same as a maintained procedure. Prompts drift. Context gets copied incompletely. One person's local setup becomes a hidden dependency.
Agent Skills provide a more durable unit. A skill can package instructions and supporting resources so an agent loads the relevant operating procedure when the task calls for it. Anthropic describes this as progressive disclosure: the agent sees lightweight skill metadata first, then loads the detailed instructions and resources only when needed.
For us, the important idea was not "give the model more context." It was "give the team a reviewed procedure with an owner and a boundary."
We treated the playbook like software
Our internal CS toolkit is now a versioned plugin rather than a folder of personal notes. The verified toolkit release for this case study is version 1.11.6. It contains 17 registered skills inside an internal marketplace with eight plugins.
The first migration moved ten recurring CS procedures into the toolkit. Later work moved shared runbooks out of local memory and into reviewed team references.
That separation matters:
- Personal preferences stay in personal memory.
- Team operating knowledge goes into shared references.
- Executable procedures become skills with clear triggers and steps.
- Changes travel through version control and review.
The procedures cover several kinds of support work: issue operations, customer and system investigation, trace review, reporting, safe remediation, and capturing new operating knowledge.
We did not move everything at once. A useful local shortcut is not automatically a good shared procedure. Before a workflow enters the toolkit, we want to know what it does, what evidence it relies on, what it may change, and where a person must stay in the loop.
The upload boundary is deliberately narrow
Runbear's internal v0 dogfooding path accepts one reviewed SKILL.md at a time for a Claude Agent SDK agent.
That narrow shape is intentional. The uploader validates the requested slug and content, then rejects additional files, scripts, environment files, configuration, and obvious secret material. The accepted file is materialized in the agent workspace at .claude/skills/{slug}/SKILL.md.
The new procedure becomes available on the agent's next activation. It is not injected into runtime memory, and it is not an instant hot reload.
This is a smaller feature than a general skill-package deployment system. It does not upload an entire local agent project. It does not support arbitrary scripts or reference bundles. It creates a controlled path for one reviewed procedure.
That constraint gave us a useful operational question: can the procedure stand on its own as a clear set of instructions, or is it hiding undeclared dependencies on one person's machine?
If the answer was the latter, the procedure was not ready to share.
A shared skill is only one layer
The skill describes how to perform a task. It does not decide every time the task should run, which systems the agent can access, or whether an action needs approval.
Those controls live in the surrounding Runbear runtime.
Runbear MCP provides management surfaces for agents, contexts, integrations, external triggers, schedules, Slack deployment, and traces. Connected events can enter through Pipedream-backed triggers. Recurring checks can run through Runbear schedules. Execution history remains inspectable through traces.
This creates a useful separation:
- The skill defines the operating procedure.
- Integrations provide scoped access to the systems involved.
- A trigger or schedule decides when work begins.
- The agent gathers context and follows the procedure.
- Slack keeps a person in the loop when judgment or approval is required.
- Traces preserve a record of what ran.
The result is more maintainable than burying the entire workflow in one giant prompt. A team can change the procedure without redesigning the trigger. It can change the schedule without rewriting the skill. It can tighten an integration permission without changing the editorial knowledge inside the playbook.
Slack is where the boundary becomes visible
Some support steps are safe to run automatically. Others need a decision.
Runbear's choice prompt creates real interactive Slack buttons. The agent can present bounded options, pause, and resume after a person clicks the selected action.
That interaction is important because "human in the loop" should not mean "the agent posts a paragraph and waits for someone to invent the next prompt." A useful approval point names the decision, provides the evidence needed to make it, and offers actions with different consequences.
For example, an investigation procedure can inspect recent traces and determine that a known remediation may apply. The agent can then offer three paths:
- Review the supporting traces.
- Prepare the safe remediation for approval.
- Escalate because the evidence is incomplete.
The skill provides the sequence. Slack exposes the decision. The runtime resumes from the explicit choice.
What we deliberately did not automate
The most important part of this project was deciding what not to claim and what not to automate.
We did not upload the entire private toolkit to one agent. The toolkit contains 17 skills, but this case study only supports the narrower statement that selected procedures moved through the internal dogfooding path.
We did not turn personal memory into shared policy. Personal preferences stay personal. Team rules must be reviewed and maintained as team knowledge.
We did not create a native trigger for every support platform. Runbear's external event path is Pipedream-backed, so a connected event is not the same thing as a first-party native trigger.
We did not treat every known fix as safe for automatic execution. Permissions, reversibility, evidence quality, and customer impact still determine whether an action can run, needs approval, or should escalate.
And we are not publishing a performance claim. This project established a shared operating boundary. Measuring adoption, execution quality, and downstream support outcomes is a separate step.
What changed for the team
The immediate change was not "AI does support now." It was more concrete.
A useful procedure no longer had to remain a private prompt on one laptop. It could become a versioned team artifact, pass through review, enter a shared agent workspace through a constrained upload path, and run inside a system with integrations, triggers, schedules, Slack decisions, and traces.
That gives support leaders a better unit of improvement.
When a workflow fails, the team can ask:
- Is the procedure wrong?
- Is the shared reference incomplete?
- Did the trigger fire with the wrong context?
- Does the integration have the right scope?
- Should the action require a Slack decision?
- Does the trace show that the procedure was followed?
Those questions are much easier to answer than "why did the chatbot do that?"
Start with one procedure the team already trusts
The best candidate is not the most impressive demo. It is a recurring procedure that an experienced operator already performs reliably.
Write down the actual sequence. Separate personal preference from team policy. Identify every external system and every consequential action. Decide what can run automatically, what requires a bounded Slack choice, and what must escalate.
Then share the smallest reviewed unit that can stand on its own.
Runbear's MCP server provides the management surface for agents, integrations, triggers, schedules, Slack deployment, and traces. If you are building a shared agent operating layer for your team, start with the Runbear MCP server documentation.
One trusted procedure is enough to begin. The goal is not to make every support workflow autonomous. The goal is to stop letting the team's best operating knowledge live on one laptop.