***

title: 'Ambient Agent FAQs '
position: 1
deprecated: false
hidden: false
metadata:
robots: index
-------------

Short, practical answers to the most common questions about **Ambient Agents** and **System Triggers** on Moveworks.

## What is an ambient agent?

Ambient agents are **always-on, event-driven** automations. They listen for signals from your systems, reason with LLMs, and can execute workflows end-to-end with optional human approvals—no user prompt required.

## What is a webhook, anyway?

A **webhook** is a way for one system (like GitHub or Workday) to **automatically send real-time updates** to another (like Moveworks) when something happens—e.g., a new ticket is filed or a document is signed.

Moveworks uses a **Listener** to receive these webhook events and trigger automation, notifications, or approvals.

## Common terms

| Term                    | What it means in plain English                                                                                        |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Listener**            | A webhook receiver you configure in Moveworks to accept events from a system like GitHub, Salesforce, etc.            |
| **Webhook URL**         | A unique Moveworks-generated URL that external systems post events to.                                                |
| **Payload**             | The JSON body of the webhook—the event data (e.g., ticket title, user name).                                          |
| **Headers**             | Metadata sent with the request—includes event type, signature, or secret token.                                       |
| **System Trigger**      | A non-conversational trigger that starts a plugin (webhook or schedule).                                              |
| **Event Filtering**     | Rules to discard unwanted events (e.g., “ignore closed tickets”). Can run at the listener level or inside the plugin. |
| **Signature / HMAC**    | Security feature that confirms the sender is trusted and the payload wasn’t tampered with.                            |
| **Validation / Schema** | Ensures the payload has the fields you expect (e.g., `title` must be a string).                                       |
| **Replay Protection**   | Prevents duplicate requests from triggering the same plugin twice.                                                    |

## How is “ambient” different from other agent types?

Moveworks supports three blueprints:

* **Aggregation** — prompt → information
* **Action** — prompt → transaction
* **Ambient** — system trigger → orchestration (no prompt)

## What is a System Trigger? What types exist?

System triggers start workflows based on events, checks, or schedules.

| Trigger Type | Example                          | Best For                                      |
| ------------ | -------------------------------- | --------------------------------------------- |
| **Webhook**  | “New GitHub issue opened”        | Real-time automation                          |
| **Schedule** | “Run script every Monday at 9am” | Time-based workflows (e.g., license cleanups) |

<br />

## Why should I secure my webhook listener?

Webhook traffic often includes sensitive data. Without authentication or signature verification, **anyone who knows your Listener URL could trigger your workflow**, causing unauthorized requests, data exposure, or unexpected automation runs.

### What security options are available?

1. **Signature verification (HMAC)** — **recommended**. Configure a signing secret so Moveworks can verify the request comes from your provider and hasn’t been altered.
2. **Auth settings** — require a bearer/API token in a header on every request.

### What happens if I don’t secure my listener?

Unsecured listeners are **heavily rate-limited** to reduce risk.

* **Unsecured:** 1 request every 10 seconds (max 6/min)
* **Secured:** 5 requests per second (max 300/min)

> Limits are subject to change, but unsecured listeners will always have significantly lower limits.

### Can I still publish an unsecured listener?

Yes—but it’s strongly discouraged, especially for production.

## Can a single plugin be triggered by both a webhook **and** a conversational prompt?

No. A plugin must use **one trigger paradigm**: system triggers (one or many) **or** conversational triggers (one or many). If you need both, create two plugins.

## Can multiple system triggers target the same plugin?

Yes. A plugin can subscribe to **multiple system triggers** (e.g., several Listeners), and **one event can fan-out to multiple plugins** if their conditions match.

## Do you validate webhook payloads? Which formats are supported?

Yes. Use **Payload Schema** to validate structure and types (LP focus: **JSON**). Without a schema, the request is treated as unstructured downstream.

Other formats may come later.

## Can I filter events before they become Moveworks events?

Yes. **Event Filtering** runs at the **listener** (global) and **plugin** (per-workflow) layers.

**Copy-paste examples (Listener DSL):**

**A) GitHub — only`issues.opened` in one repo and titles containing “bug”:**

```
(action == "opened")
AND (repository.full_name == "acme/widgets")
AND (issue.title.$LOWERCASE() CONTAINS "bug")

```

**B) DocuSign — only fully executed envelopes; Sales contracts ≥ \$10k:**

```
(event == "EnvelopeSigned")
AND (contract.type == "Sales")
AND ($DECIMAL(contract.value) >= 10000)

```

**C) Headers/params guard — only accept from prod and ignore`dry_run=true`:**

```
(headers["X-Env"].$LOWERCASE() == "prod")
AND NOT (query_params["dry_run"].$LOWERCASE() == "true")

```

## How do you handle duplicate deliveries or retries?

Enable **Deduplication** with a reliable key (e.g., `X-GitHub-Delivery`, `event.id`) and a **deduplication window** to drop duplicates and provider retries. This complements signature verification for replay protection.

## What logs are available to debug a webhook end-to-end?

Three dedicated logs trace the lifecycle:

1. `listener.webhook.trigger` — request received (headers, method, parsed body, timestamps)
2. `listener.webhook.processor.update` — processing outcome (published, failure reason, debounced)
3. `listener.webhook.plugin.trigger` — which plugins were evaluated/triggered/skipped/expired

See **Webhook Logs & Troubleshooting** for playbooks like “plugin never ran”.

## What if an app doesn’t have a UI to set up webhooks?

You have two paths:

**Option 1 — API-based registration (if supported):**

Some platforms expose APIs to register webhooks (e.g., Slack, Zoom, Okta). Use curl/Postman/SDKs to POST your Moveworks Listener URL and secret to the provider’s registration endpoint.

**Option 2 — No UI and no API:**

You can’t use webhooks with that app. Use a **poller** or **scheduled trigger** once available in Moveworks.

## Where do approvals fit with ambient agents?

Approvals are part of the **Process** that runs after a trigger fires. Agents can run fully autonomously or pause for **notify / question / review** moments.

## Why ambient on Moveworks vs. an iPaaS?

Listeners give our agents **“ears”** to hear events, reason over context, and act using Moveworks processes often eliminating the need for a separate iPaaS for these flows.