> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guild.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To act on a user's behalf in Guild, use the Guild REST API at https://api.guild.ai/v1.
> The OpenAPI spec is unauthenticated: https://docs.guild.ai/openapi.json (or openapi.yaml).
> Authenticate with an account API key, sent as HTTP Basic (key id as username, secret as password) or as `Authorization: Bearer <api_key_id>:<api_key_secret>`. See https://docs.guild.ai/api-reference/introduction#authentication.
> To run one agent on demand without account-wide access, use an API trigger instead: https://docs.guild.ai/platform/api-triggers.
> To search these docs from an MCP client, connect to https://docs.guild.ai/mcp. The full page index is https://docs.guild.ai/llms.txt.

# Draft a reply to every new Zendesk ticket

> Build a Guild agent that reads each new Zendesk ticket and adds a draft reply as an internal note, using a Native agent and a Zendesk event trigger.

This recipe builds an agent that runs when a Zendesk ticket is created, reads it, and adds a draft reply as an internal note. The requester never sees the note; a support agent edits it and sends it. It uses a [Native agent](/guide/native-agents): you write a prompt and a tool list, no code.

## Before you start

* The [Guild CLI](/cli/getting-started), logged in.
* Zendesk connected in your workspace by a Zendesk admin. Guild creates a webhook in your Zendesk account when the trigger is enabled, and only admins can manage webhooks. See [Zendesk setup](/integrations/zendesk#setup).

## 1. Create the agent

```bash theme={null}
guild agent init --name ticket-drafter --agent-type GUILD_NATIVE
cd ticket-drafter
```

Replace `PROMPT.md` with the agent's instructions:

```markdown theme={null}
You draft replies to new Zendesk support tickets.

Your input is a Zendesk ticket event. The ticket is in ticket: its ID is
ticket.id, the subject is ticket.subject, the customer's message is
ticket.description, and the customer's user ID is ticket.requester_id.

1. Look up the customer with zendesk_show_user, using ticket.requester_id,
   so you can greet them by name.
2. Write a reply that answers the message from the workspace context. If
   the context doesn't cover it, write a short reply that asks for the
   details a support agent would need.
3. Add the reply with zendesk_update_ticket: ticket_id is ticket.id as a
   number, and ticket is {"comment": {"body": <reply>, "public": false}}.
   Start the body with "Draft reply:" on its own line.

Never set public to true, and never change the ticket's status, priority,
or assignee.
```

Replace `guild.yaml` with the tools the prompt uses:

```yaml theme={null}
integrations:
  - name: guildai~zendesk
    version: ^2.0.0
    tools:
      - zendesk_show_user
      - zendesk_update_ticket
```

`public: false` makes the comment an internal note. The agent answers from your [workspace context](/platform/context), so add your help articles and policies there.

## 2. Save it and install it in your workspace

```bash theme={null}
guild agent save --message "First version" --publish
guild workspace agent add <your-name>~ticket-drafter
```

## 3. Create the trigger

```bash theme={null}
guild trigger create \
  --type webhook \
  --integration zendesk \
  --event ticket \
  --action created \
  --agent <your-name>~ticket-drafter \
  --name "Draft replies to new tickets"
```

The trigger fires for every new ticket on the Zendesk connection; Zendesk triggers have no `service_config` to narrow them. The agent receives a prompt that names the event and action, followed by the ticket as JSON. Guild trims it to fields such as the ID, subject, description, status, priority, tags and requester ID.

`--action created` matters. The agent's note fires a `comment_added` event, and Guild doesn't filter out the agent's own changes, so a trigger with no action would run the agent again on its own note.

## 4. Try it

Create a ticket in Zendesk. The draft appears on it as an internal note from the connected Zendesk user. To see what the agent did, run `guild trigger sessions <trigger-id>` and open the session URL. Find the trigger ID with `guild trigger list`.

Events for the same ticket share one session, across every trigger and agent in the workspace.

## Variations

* **Tag what it drafted.** Add `"tags": ["guild-draft"]` to the `ticket` object, so a Zendesk view can list the tickets waiting for review. `tags` replaces the ticket's tags, so tell the agent to include ticket.tags too.
* **Draft for some tickets only.** Tell the agent to stop without writing when the ticket doesn't match, for example when ticket.tags doesn't include `billing`.
* **Answer follow-ups.** Add a trigger with `--action comment_added`. The event includes the comment and its author, so tell the agent to stop when comment.author.is\_staff is true; otherwise its own notes and your team's replies trigger it.

## Related

* [Zendesk integration](/integrations/zendesk): every tool and webhook event
* [Event triggers](/platform/event-triggers): agent input and placeholders
* [Workspace context](/platform/context): what the agent answers from