Workflow Event-Driven Trigger Agent Prompt

This prompt is for platform engineers and workflow builders who need to convert a natural-language description of a business event into a strict, machine-readable event subscription definition. The core job-to-be-done is wiring a reactive agent system to an event bus, where the system must know exactly what events to listen for, how to filter them, how to deduplicate them, and which agent or workflow to trigger. The ideal user is someone building an agent orchestrator who needs a reliable contract between the event source and the consuming agent graph, not someone designing a simple notification service.

Use this prompt when the event schema is not yet fully specified in code and you need to generate a structured definition that can be consumed directly by a workflow engine like Temporal, an event mesh like Solace, or a custom agent orchestrator. The output is designed to be a configuration artifact, including filter criteria, a payload schema, a deduplication key, and a routing target. This is appropriate for high-cardinality event sources where manual definition writing is error-prone, such as a stream of CRM updates, IoT device state changes, or multi-tenant platform events. Do not use this prompt for simple notification routing (e.g., 'send a Slack message on form submit') or for workflows where the event schema is already fully defined and versioned in a protobuf or JSON Schema registry.

Before using this prompt, you must have a clear, unambiguous description of the business event, including its trigger conditions, the data it carries, and the downstream agent or workflow it should activate. You should also know the constraints of your event bus, such as supported filter syntax, payload size limits, and deduplication window. If the event source is unreliable or the business description is vague, the generated subscription definition will be brittle. In high-risk scenarios, such as financial transaction triggers or healthcare event routing, always pair this prompt's output with a human review step and a dry-run validation against a test event stream before deploying to production.

This prompt template is designed to be embedded in your workflow engine's trigger configuration step. It instructs the model to produce a structured event subscription definition—not to execute the agent itself. The output is a machine-readable contract that your orchestration layer uses to register listeners, validate incoming event payloads, and route events to the correct agent while preventing duplicate processing.

textCopy
You are an event-driven workflow architect. Your task is to produce a strict event subscription definition for a reactive agent workflow. Do not execute the agent or simulate the workflow. Output only the subscription definition in the specified schema.

## EVENT SOURCE
[EVENT_SOURCE_DESCRIPTION]

## TARGET AGENT
- Agent ID: [AGENT_ID]
- Agent Capability: [AGENT_CAPABILITY_SUMMARY]
- Agent Input Contract: [AGENT_INPUT_SCHEMA]

## SUBSCRIPTION REQUIREMENTS
Define an event subscription with the following components:

1. **Event Type**: The specific event type string this subscription listens for.
2. **Filter Criteria**: Conditions that must be true for the event to trigger the agent. Use field paths, operators, and values. Include both inclusion and exclusion rules where relevant.
3. **Payload Mapping**: How raw event fields map to the agent's input contract. Specify field transformations, defaults for missing fields, and any required enrichment.
4. **Deduplication Key**: A composite key derived from event fields that uniquely identifies a logical event instance. This prevents duplicate processing.
5. **Idempotency Window**: The time window (in seconds) during which duplicate events with the same deduplication key should be discarded.
6. **Trigger Constraints**: Any rate limits, concurrency caps, or time-of-day restrictions on firing this trigger.
7. **Dead Letter Handling**: What to do when the event payload fails validation or the agent rejects the input. Specify retry policy, fallback queue, or escalation path.

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "subscription_id": "string",
  "event_type": "string",
  "filter_criteria": {
    "include": [{"field": "string", "operator": "string", "value": "any"}],
    "exclude": [{"field": "string", "operator": "string", "value": "any"}]
  },
  "payload_mapping": {
    "agent_input_field": "event_field_path or literal value",
    "_missing_field_defaults": {"agent_input_field": "default_value"},
    "_required_fields": ["field1", "field2"]
  },
  "deduplication": {
    "key_fields": ["field1", "field2"],
    "window_seconds": 3600
  },
  "trigger_constraints": {
    "max_invocations_per_minute": null,
    "max_concurrency": 1,
    "allowed_time_windows": []
  },
  "dead_letter": {
    "on_validation_failure": "dlq: [QUEUE_NAME]",
    "on_agent_rejection": "escalate: [ESCALATION_PATH]",
    "max_retries": 3
  }
}

## CONSTRAINTS
- The deduplication key must include at least one immutable event field (e.g., event_id, correlation_id).
- Filter criteria must not create circular dependencies with other subscriptions.
- If the event source is high-risk ([RISK_LEVEL] = "high"), add a human-approval gate before agent invocation.
- Do not invent event fields not described in [EVENT_SOURCE_DESCRIPTION].

To adapt this template, replace each square-bracket placeholder with your concrete details. The [EVENT_SOURCE_DESCRIPTION] should describe the upstream system emitting events, including available fields and their semantics. The [AGENT_INPUT_SCHEMA] must match the exact input contract of the agent you are routing to—mismatched field names here will cause silent payload rejection in production. Set [RISK_LEVEL] to "high" for any workflow involving financial transactions, PII access, or irreversible side effects; this gates the trigger behind human approval. After generating the subscription definition, validate it against your orchestration engine's schema before registering it. Test with both valid and intentionally malformed events to confirm that filter criteria, deduplication, and dead-letter routing behave as expected.

This prompt is designed to be called by an orchestration engine—not a chat UI. It expects structured input describing an event source and returns a machine-readable subscription definition. The harness must validate the output against the expected schema before registering the subscription in your event bus or workflow engine. Treat the model output as a proposed configuration that requires programmatic validation, not as a directly executable artifact.

Validation and Deduplication: Parse the JSON output and validate that subscription_id is present, filter_criteria is a non-empty object, and payload_schema contains at least one required field. The deduplication_key must reference a field that exists in payload_schema. Reject any subscription where the deduplication key is absent from the schema. Before registering, check your event bus for an existing subscription with the same event_source and filter_criteria combination to prevent duplicate subscriptions. If a conflict is detected, log the collision and either skip registration or flag for human review depending on your [RISK_LEVEL] configuration.

Retry and Model Selection: Use a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku) for this prompt since the output is a constrained schema. Implement a retry loop with up to 3 attempts if JSON parsing fails or schema validation errors occur. On each retry, append the validation error message to the prompt as additional context. If all retries fail, log the raw output, emit an alert to the platform operations channel, and do not register a partial or invalid subscription. For high-risk event sources (e.g., payment webhooks, auth events), require a human operator to approve the subscription definition before it goes live. Wire this approval step into your workflow engine as a manual task with a timeout—if no human responds within the SLA window, the subscription is rejected by default.