When the SOP becomes the agent: Stonly's process-agent pattern (and why the pattern matters more than the brand)

On September 17, 2026, Stonly announced Business Process Agents (BPAs): agents that execute the same structured Guides (steps, branches, required information, policies, and actions) that human agents and self-service already use. One process definition; three runtimes (human, self-service, autonomous or semi-autonomous AI).

That design choice is the story. Most shops that try to automate complex support end up maintaining one SOP for people and a second pile of prompts, retrieval rules, and workflow logic for AI. Drift is inevitable. An agent that runs the Guide you already trust is a different failure mode, and usually a better one.

What the product claims to do

Per the release, a BPA can:

• Follow a Guide step by step, including decision branches and required checks.
• Ask the customer for information, take action in connected systems, and continue until the issue resolves or human judgment is required.
• Run fully autonomous, pause for approval on key decisions, or prep work and hand off to a person with context and next step ready.

Targeted work includes troubleshooting, eligibility, intake, account changes, and other policy-heavy "it depends" cases: the volume that eats agent time after FAQ bots have skimmed the easy questions.

Why thin support orgs should care about the pattern

If you run a 20 to 500 person company with a small support team, your SOPs are already the operating system. The pattern to evaluate, whether in Stonly or elsewhere, is:

1. Single source of process truth: change the Guide once; humans and agents pick it up. If your vendor still requires a parallel "AI version," you are buying duplicate maintenance.
2. Partial autonomy with gates: refund thresholds, identity checks, and exception paths stay behind approval. Full autonomy is optional, not the default.
3. Handoff with context: when the agent stops, the human gets the trail and the next step, not a cold ticket.
4. Readable ownership: support and knowledge teams can edit the process without waiting on a prompt engineer. If only specialists can change behavior, adoption dies after launch.

This is controlled partial autonomy in product form: automate the procedural middle, keep humans on judgment and irreversible actions.

Fit / skip

Fit if your painful tickets already live in written, branched procedures; you are tired of chatbot answers that ignore policy; and you can name an owner for Guide quality. The SOP-as-agent pattern reduces the "AI that ignores how we work" failure mode.

Skip or wait if your procedures exist only in tribal knowledge, availability is still beta for your segment, or you cannot define approval gates for money and account changes. An agent that follows a bad or incomplete Guide will scale the bad process faster.

Stonly is one vendor shipping this idea. The operator decision is whether your knowledge is structured enough to be an agent runtime, and whether approval gates are first-class, not a slide. Brand second; pattern first.