Guide: build a support workflow

How to set up a customer support operation in your gcontext workspace: tickets come in from your queue, your agent consults its playbooks, executes the fix through your integrations with you approving every write, logs what it did, and folds what it learned back into the playbooks.

You start with zero playbooks. The agent writes them: after a few months of real tickets, the playbook library IS your support knowledge base. This guide was extracted from a production workspace that has resolved hundreds of tickets this way.

Each step below ends in a prompt to paste into your AI client. The last one hands your agent this very page, which also contains the templates it needs (the "For the agent" section at the end).

What you'll build

/workflows/support/
  workflow.md        the Workflow instance: purpose, how to run
  steps.md           the six-phase procedure the agent follows per ticket
  playbooks/         one doc per recurring task type, written by the agent
  logs/YYYY-MM/      one log per resolved ticket
/_commands/support-task.md    so "/support-task SUP-42" runs the whole loop

And the loop each ticket goes through:

1. Intake from your queue (Linear, Zendesk, Intercom, GitHub Issues...).
2. Plan from playbooks/: a match becomes the plan; no match means propose one.
3. Execute: reads run freely, every write waits for your approval.
4. Log the run under logs/YYYY-MM/.
5. Learn: update the playbook with what the run taught, or create one.
6. Close the ticket with a comment a human can act on without re-investigating.

Phase 5 is the point: every run makes the next run of the same task type cheaper.

Before you start

You need a connected AI client (see Setup in your dashboard) and about half an hour. Have the API credentials for your ticket system at hand; credentials for the systems your fixes touch (Stripe, your database...) help but can be added later.

Step 1: Enable the Workflow type

In your dashboard, open Settings and switch on the Workflow type. This adds its definition to your workspace's /_types.md, which is how your agent learns the shape. (Or skip the dashboard and just tell your agent to enable it.)

Step 2: Connect your ticket queue

Your agent needs an Integration folder for wherever tickets live. Paste:

Using the gcontext MCP: set up an integration for my ticket system. Ask me which service it is (Linear, Zendesk, Intercom, GitHub Issues...) and what marks a ticket as a support ticket (a team, a label, a view). Create the integration folder, register the secret NAMES it needs, and open the local secrets form so I can fill the values (they stay on my machine). Then VERIFY it: fetch one real ticket from my support queue and show it to me. Don't consider this done until that fetch works.

The verification matters. Don't move on until the agent shows you a real ticket and you've confirmed it's looking at the right queue.

Step 3: Connect the systems your fixes touch

Repeat for each system a support fix actually changes: your payment provider, your database, your admin API. Paste, once per system:

Using the gcontext MCP: set up an integration for {service}. Register its secret names, open the local secrets form for me, then verify with one harmless read (list one customer, select one row) and show me the result.

Read-only credentials are enough to start: the agent can diagnose tickets with reads and ask you to execute writes manually until you trust it with write access.

Step 4: Scaffold the workflow

Now the folder itself. Paste:

Using the gcontext MCP: fetch https://gcontext.ai/docs/support-workflow and follow its "For the agent: scaffolding" section. Interview me as it says, then build /workflows/support and the /support-task command from its templates, filled in with my answers.

The agent will ask you four things: how tickets are identified in your queue and what the "in progress" and "done" states are called, which integrations map to which services, what needs your approval (default: every write), and who reads the closing comments. Answer and let it build.

Step 5: Resolve one real ticket

The setup is done when a ticket has been through it, not when the folders exist. Pick a real, ideally simple ticket and paste:

/support-task {your ticket id}

Walk it through together: confirm the plan, approve the writes, read the log it produces. This first run creates your first playbook and surfaces anything the interview got wrong while it's still cheap to fix. From then on, it's /support-task next whenever you sit down to do support.

Beyond support

The same skeleton (steps + playbooks + logs + a learn phase) fits any recurring operational queue: refund processing, customer onboarding, incident triage. Change the queue, the integrations map and the phase details; keep the loop.

For the agent: scaffolding

You were sent here by the Step 4 prompt. The user has (or should have) working, verified integrations for their ticket queue and fix-target systems; if any is missing or has never returned data, set that up and verify it first (Steps 2-3 above). Track your progress in a Task folder if the setup spans sessions.

Interview the user, in one message:

1. Ticket queue: what marks a ticket as support (team, label, view)? Exact state names for "being worked on" and "done"?
2. Systems map: which integration handles which service, and which credentials are read-only vs read-write?
3. Approval rules: default is every write to any system waits for explicit human approval, with one exception: setting the ticket to "in progress" at intake is automatic. Adjust to the user's tolerance.
4. Audience: who reads the closing comment? Write for them: plain language, name the affected customer and what changed, no internal IDs.

Then create:

/workflows/support/
  workflow.md               type: Workflow frontmatter, purpose, "follow steps.md"
  steps.md                  the template below, with the interview answers filled in
  llms.txt                  index of this folder
  playbooks/
    llms.txt                "# Playbooks" + empty "## Playbooks" list
    _integrations.md        the map from question 2: service -> integration -> secrets
  logs/
    llms.txt                "# Logs" + empty month list
/_commands/support-task.md  the command template at the end

playbooks/_integrations.md matters more than it looks: playbooks name services abstractly ("Service: Stripe") so they survive credential and tooling changes; this file is the one place that resolves each name to the integration module and secret names actually loaded in this workspace.

steps.md template

Fill the {placeholders}; keep the phase structure.

# Support Task Workflow

**Role:** {company} support operations agent.
**Objective:** resolve a ticket from {queue}: consult playbooks, execute through
the loaded integrations, record a log and a playbook update.
**Before anything:** read `playbooks/_integrations.md`.

## Phase 0: Input
Input is a ticket ID or "next". "next" = highest-priority unstarted ticket in
{queue}, confirm before proceeding. Set the ticket to "{in-progress state}"
immediately: this is the one automatic write.

## Phase 1: Intake
Fetch the full ticket: title, description, priority, comments. Identify the
{customer/account} and a task-type slug (e.g. "swap-membership").
Present: "Ticket {id}: {title}. {Account}: {name}. Type: {slug}."

## Phase 2: Plan
Read `playbooks/llms.txt`, find a match by slug or description.
Playbook exists: read it fully, present its steps as the plan, note variations.
No playbook: propose a plan; per step name the integration and Read vs Write.
Wait for confirmation before executing.

## Phase 3: Execute
Keep a running operations log. Per step:
- Read: execute immediately.
- Write: present What / Command / Impact, wait for explicit approval, execute,
  report.
- Manual step: describe what the user must do, wait, record what they did.
On failure: report, propose an adjusted plan, continue after confirmation.

## Phase 4: Log
Create `logs/{YYYY-MM}/{ticket-id}-{slug}.md` (create the month folder + llms.txt
if absent, update the indexes). Sections: one-line summary, Task (ticket, account,
dates, type), Operations Performed (per step: service, operation, details, result),
Human Steps, Outcome, Playbook Reference.

## Phase 5: Learn
No playbook yet: create `playbooks/{slug}.md`, generalize IDs to {placeholders},
sections: When to Use / Prerequisites / Steps / Common Variations / Notes. Index it.
Playbook exists: fold in new variations and gotchas, or report "matched, no changes".

## Phase 6: Close
Comment the resolution on the ticket and set it to "{done state}" (writes: present
and wait for approval). Write the comment so {audience} can act without
re-investigating: plain language, no internal IDs, name the affected customer,
state what changed and what is still pending.

## Report
Summary, path to the log, path to the playbook, final ticket status.

What a playbook looks like

One markdown doc per recurring task type, written in Phase 5 and refined on every subsequent run. Shape:

# Reset Session Counter

## When to Use
Ticket asks to correct a member's remaining class/session count after a manual
booking error.

## Prerequisites
- {account} resolved to its database ID
- Read access confirmed on {database integration}

## Steps
1. Look up the member document at `{collection}/{member_id}` (Service: database).
2. Compare `sessionsUsed` against actual attendance (Service: database, read).
3. Present the corrected value; on approval write it back (Service: database, write).
4. Verify the app shows the corrected count.

## Common Variations
- Counter is on the bundle, not the member doc: fix the bundle document instead.

## Notes
- Never adjust both the counter and the bundle in one write; verify between steps.

/_commands/support-task.md template

---
description: Resolve a support ticket end-to-end via the support workflow
---

Input: "{{input}}": a ticket ID, "next", or empty (ask which ticket).

Read `/workflows/support/steps.md` and follow its phases exactly, using the input
as the Phase 0 input. That file is the source of truth; do not improvise a
different procedure. Before executing anything, read
`/workflows/support/playbooks/_integrations.md`.