Renewal risk usually does not fail because nobody saw a low health score. It fails because the next action never becomes a coordinated, approved workflow. A CSM has notes in a spreadsheet, RevOps has context somewhere else, the executive sponsor is in Slack, and the official plan gets written after the fact if the team has time.
The Renewal Risk Command Center is a focused Guild.ai agent demo for that coordination problem. It reads account health data from Google Sheets, identifies the riskiest renewal, posts a proposed mitigation plan to Slack, waits for a human approval message, creates the approved plan in Google Docs, and returns the document link to Slack.
The Human-in-the-Loop Pattern
The agent does not replace the renewal owner. It turns scattered renewal signals into a proposed action, keeps approval in the collaboration surface, and writes the approved plan into a durable artifact.
The Workflow Shape
The demo is intentionally narrow. Google Sheets stands in for the customer-success data layer. Slack is the human approval surface. Google Docs is the official plan destination. Guild.ai provides the TypeScript agent runtime, publishing flow, Slack trigger infrastructure, and OAuth-backed tool integrations.
Detect
The agent reads the Accounts sheet and selects the renewal with the lowest health score.
Approve
Slack receives a proposal with account, owner, ARR, renewal date, risk rationale, and approval instructions.
Document
After human approval, the agent creates and populates a Google Doc with the approved action plan.
That may sound simple, but the value is in the boundary. The agent is allowed to recommend and document. The human is still responsible for approval. In renewal workflows, that distinction matters because the action plan often touches commercial terms, executive relationships, discounting, support commitments, and forecast assumptions.
What Guild.ai Adds
Guild.ai is doing more here than hosting a prompt. The platform gives the workflow a deployable agent shape: a TypeScript SDK, packaged service tools, OAuth credential handling, Slack triggers, validation, publishing, and session-level operations for understanding what happened after a run. The Guild.ai docs are a useful starting point for the SDK, CLI, triggers, and service integrations.
That matters because business workflows rarely need a model in isolation. They need a model that can safely receive an event, call the right tools, ask for approval, leave an audit trail, and be versioned like software.
| Guild.ai Feature | What It Does | Why It Helps |
|---|---|---|
| TypeScript Agents SDK | Defines the agent as code with a clear description, tools, prompt, and runtime configuration. | Teams can review, version, build, and publish the agent like an application instead of managing a loose prompt. |
| Service tools | Packages integrations such as Slack, Google Docs, Google Sheets, GitHub, and other business systems. | The agent can operate across real tools without every project starting from raw API plumbing. |
| OAuth credentials | Connects service accounts through Guild.ai workspace credentials rather than hard-coding tokens in the agent. | Credential ownership stays with the workspace, which is cleaner for demos, handoff, and client-controlled deployments. |
| Webhook and Slack triggers | Starts an agent from events such as a Slack app_mention and passes the event payload into the run. |
The workflow begins where the team already works, with the Slack channel and thread context available to the agent. |
| Validation and publishing | Uses the Guild.ai CLI to save, validate, and publish an agent version to the workspace catalog. | Shipping the agent becomes repeatable: build it, validate it, publish it, and install or trigger the approved version. |
For the Renewal Risk Command Center, those features make the demo easier to explain and easier to extend. The repo contains a focused agent, but the behavior depends on platform pieces around it: connected credentials, a Slack event trigger, remote validation during save, and a published agent version that the workspace can run.
The platform benefit
Guild.ai turns the agent from "a script that can call APIs" into an installable workflow component: event-triggered, credential-aware, tool-connected, validated, and publishable for a workspace.
In this demo, governance is concrete rather than abstract. The agent does not get every available integration; it uses Guild.ai service tools selected with pick(), limited to Slack messaging, Google Sheets reads, and Google Docs creation/update. Credentials are managed through Guild.ai workspace credentials instead of being hard-coded into the repo. The Slack trigger defines how the agent is invoked, the approval step creates a human checkpoint, and publishing through Guild.ai gives the workflow a validated agent version rather than an untracked local script.
Why Slack Is the Approval Plane
For this version, the approval step lives in Slack because that is where renewal work already happens. My approach to designing agent systems is to meet users where they are: put the decision point in the surface where the team already coordinates, not in a separate portal or queue that someone must remember to check. A user mentions the Guild.ai agent, the agent posts the proposal, and the approver replies with @Guild APPROVE, @Guild REVISE, or @Guild HOLD.
View the Slack approval thread screenshot to see the scan request, human approval, and Google Docs handoff in one collaboration thread.
The agent acknowledges the request in the channel or thread where the work was initiated.
The proposal is explicit that it is awaiting human approval, not claiming that work has already been authorized.
Google Docs becomes the durable artifact, and Slack gets the final link for traceability.
The Tool Surface Stayed Focused
The agent is implemented as a TypeScript llmAgent with only the tools needed for the workflow. It can read spreadsheet values, post Slack messages, list Slack conversations as a fallback, create a Google Doc, and batch-update the document body. That is enough for the demo and intentionally less than a general-purpose business-systems agent.
| Tool Area | Role | Boundary |
|---|---|---|
| Google Sheets | Read account health rows from Accounts!A:L |
Spreadsheet-only demo data, not CRM authority |
| Slack | Receive the trigger, post the proposal, and capture approval | Approval stays human-readable and visible to the team |
| Google Docs | Create and populate the approved plan | No document is created before the approval step |
The prompt also includes operational guardrails: do not include internal Guild.ai URLs in Slack, disable link previews where supported, use the incoming Slack channel from the webhook payload when available, and do not claim a source system was updated. Those instructions are not decorative. They keep the agent aligned with what the demo actually does.
The Demo Data Is a Placeholder for a Real Command Center
The sample spreadsheet includes fields like account, segment, owner, renewal date, ARR, health score, risk status, primary risk, recommended action, executive sponsor, last touch, and notes. For the included sample data, the agent should identify Nimbus Health because it has the lowest health score and an executive sponsor change paired with declining product usage.
No CRM integration yet: account owner, opportunity stage, forecast data, and activity history are not connected.
No finance integration yet: ARR is present in the sheet, but billing status, invoices, and payment risk are not live signals.
No product or support telemetry yet: usage drop-off and escalation risk are represented as demo fields, not production integrations.
That limitation is the point of the demo. It shows the workflow skeleton before attaching every enterprise data source. In production, the same command-center pattern would pull from CRM, finance, product analytics, and support systems, then use Slack approval and a durable record to coordinate the response.
The Takeaway
Useful agents often start as coordination layers rather than autonomous decision-makers. The Renewal Risk Command Center does not try to become a complete revenue platform. It demonstrates a focused pattern: read trusted data, propose the next best action, wait for a human checkpoint, and create the approved artifact where the team can use it.
That pattern is portable. The specific inputs can change from spreadsheets to Salesforce, Gainsight, Stripe, product telemetry, or Zendesk. The important part is keeping the approval boundary explicit and making the agent responsible for moving work across systems after the human says yes.
Want to turn scattered account signals into an approved operating workflow? We build human-in-the-loop agents that connect the tools your team already uses.
./book-discovery