Publish and Trigger the Plugin

The plugin is the deployable wrapper around the capability you built. It defines when execution starts, what body runs, and which access dependencies execution requires.

Choose the Plugin Shape

Configure Conversational Retrieval

The Manifest Generator uses plugin metadata to create the model-facing tool description. Write metadata that distinguishes the capability from similar plugins.

Title

Name the business capability:

Manage Product Feature Requests

Avoid implementation names:

Purple Community PATCH Wrapper

Description

Explain what the plugin can do, which records it works with, and important boundaries:

Find a product feature request and update its current status.
Use this plugin when a user wants to view, triage, or move a feature request
to another supported status. Do not use it to create roadmap commitments.

Triggering Examples

Add at least five varied positive examples:

• “Move the dark mode request to Planned.”
• “Update a feature request’s status.”
• “Mark dark mode as delivered.”
• “What status is the SSO reporting request in?”
• “Triage my product feedback request.”

Add negative examples that clarify nearby capabilities:

• “Create a Jira issue.”
• “Show the engineering sprint roadmap.”
• “Approve this purchase request.”

Examples shortlist relevant plugins. The reasoning engine still uses the description and context to choose among them.

Bind the Conversation Process

Select the process that:

1. Collects or resolves the feature request.
2. Collects and validates the target status.
3. Confirms the write when required.
4. Calls the compound action.
5. Exposes a concise result.

Test the process directly before relying on plugin retrieval.

Configure a System Trigger

For a webhook or schedule, map the trigger body into the action or compound action inputs:

feature_request_id: data.event.feature_request_id
new_status: data.event.target_status

The exact root path depends on the trigger payload schema. Inspect the event in trigger logs and map only documented values.

Use Notify as an Explicit Handoff

An ambient workflow can notify a resolved user and offer a button that starts a conversation.

Webhook or schedule
        ↓
Resolve recipient
        ↓
Compound action notify block
        ↓
User receives notification
        ↓
User selects the action
        ↓
New conversation process starts with mapped inputs

The notify block does not retroactively add conversational user context to the ambient execution. User context begins in the new conversation after the user acts. Map ambient data through conversation_action.input_args; each key must match a declared slot in the target conversation process. Use resources separately when the model needs optional supporting context. Resources do not populate declared slots.

Configure Launch Access

Check every dependency:

Execution can start
        ↓
Plugin can use its configured body
        ↓
Conversational: process → action
System: HTTP or compound action
        ↓
Nested actions can use connectors
        ↓
Connector credentials can perform downstream operations

A failure at any layer can prevent execution.

For both shapes, verify that logs do not expose secrets or sensitive payloads.

Build Along: Publish the PurpleSuite Plugin

Create a conversational plugin with:

Move <a live feature request name> to Planned.

Use the description and triggering examples from this chapter, then add at least three nearby negative examples. Publish the plugin and test that:

1. A direct request to update a feature request retrieves the plugin and runs the resolver’s list GET.
2. A vague reference produces resolver disambiguation.
3. A Jira or roadmap request does not retrieve it.
4. Rejecting confirmation performs no PATCH request.
5. Accepting confirmation runs one PATCH followed by one verification GET.
6. The assistant returns only the verified request name and new status.

Your checkpoint is a published, access-limited conversational plugin that retrieves for the intended language and rejects nearby capabilities.

Trigger Design Checklist

• One plugin uses one trigger paradigm.
• The title names the capability, not the implementation.
• The description states supported outcomes and boundaries.
• Positive examples cover varied user language.
• Negative examples separate nearby capabilities.
• A conversational plugin binds one tested process.
• A system trigger maps its payload into explicit inputs.
• A scheduled trigger is published and Active.
• Ambient execution does not assume a user profile.
• Notify crosses into conversation through an explicit user handoff.
• Access includes every dependency; only conversational plugins use a launch audience.

Deep Dives

• Natural Language Triggers
• Manifest Generator
• Webhook Triggers
• Scheduled Triggers
• Connect Ambient Agents to Conversational Agents
• Launch Configuration

Next, compare your assets with the PurpleSuite build reference.