🚧

UNDER CONSTRUCTION

Ambient agents live in the background, continuously listen for signals across the enterprise, and step in at the right moment to automate business processes. In short, ambient agents are event-driven in their initiation and autonomous in their execution.

How Ambient Agents Work

Ambient agents rely on system triggers to initiate execution. These triggers detect events, changes, or timed conditions across integrated systems. Once triggered, the agent runs a predefined process, a compound action that may include HTTP actions, data validation, conditional branching, user interactions (e.g., notifications or approvals), and more. Developers configure triggers and processes in the Plugin Workspace, where the Agentic Automation Engine orchestrates execution, handles errors, and ensures idempotency for reliable runs.

Imagine an e-commerce platform where a Proactive Agent is configured to listen for a webhook from a payment gateway. When a customer completes a purchase, the gateway sends a notification to the agent with details like the transaction ID, amount, and customer email. The agent immediately processes this data: it updates the inventory database to reflect the sold items, logs the transaction in an analytics system, and triggers an email service to send a personalized confirmation to the customer—all without any manual input. This real-time automation ensures the system stays in sync and the customer receives prompt feedback.

Use Cases

Ambient agents enable powerful automations across various business functions. Here are some real-world examples:

• SaaS License Reclamation: An ambient IT agent that scans weekly for inactive SaaS licenses, confirms inactivity with the user, reclaims the unused licenses, and saves real dollars every week.
• Support Ticket Auto-Triage: An ambient customer support agent that triages new high-priority Jira tickets, attempts to reproduce issues using internal tools, looks for related open tickets, and summarizes its findings, all before a human support agent even opens the ticket.
• Supply-Chain Disruption Response: An ambient supply chain agent that detects potential disruptions, diagnoses the root cause, and then recommends and executes adjustments once approved.

The Ambient Foundation: System Triggers

Ambient agents don’t just wait around to be prompted; they need to listen for events across the enterprise and know when it’s time to act. System triggers perform this function by initiating workflows based on specific events or conditions, and they’re the foundation of ambient agents. There are three flavors of system triggers:

Triggers

More Detail on System Triggers

Architecture Diagrams for Ambient Agents

Ambient agents can leverage different trigger types, each with its own architecture for handling events, changes, or scheduled tasks. Below are sequence diagrams illustrating the flow for each trigger type.

Webhook Trigger Architecture

This diagram shows an ambient agent responding to a real-time webhook event, such as monitoring CPU usage and scaling resources if needed.

sequenceDiagram
    participant A as Admin
    participant P as Ambient Agent
    participant B1 as Backend System 1
    P->>B1: Monitor Webhook Trigger
    B1->>P: Send Webhook Event (CPU Usage)
    P->>P: Interpret and Validate Event
    P->>P: Check: Is CPU Usage > 80%?
    alt CPU Usage > 80%
        P->>B1: Execute Action (Scale Resources)
        B1->>P: Return Result
    else CPU Usage ≤ 80%
        P->>P: Log Event
    end
    P->>A: Deliver Notification

Scheduled Trigger Architecture

This diagram depicts an ambient agent executing a workflow at a predefined time, such as generating a report on new feature requests every Monday morning.

sequenceDiagram
    participant A as Admin
    participant P as Ambient Agent
    participant B1 as Backend System 1
    participant B2 as Backend System 2
    P->>P: Scheduled Trigger (Every Monday @ 9am)
    P->>B1: Get All New Feature Requests
    B1->>P: Return Feature Request Data
    P->>P: Compare to WIP Memos
    P->>P: Identify Relevant PM
    P->>B2: Assign Task to PM
    B2->>P: Return Assignment Result
    P->>P: Generate Summary Report
    P->>A: Deliver Report
    A->>A: Receive Report

Poller Trigger Architecture

This diagram illustrates an ambient agent using a poller to periodically check for changes, such as monitoring open tickets and alerting if they exceed a threshold.

sequenceDiagram
    participant A as Admin
    participant P as Ambient Agent
    participant B1 as Backend System 1
    participant B2 as Backend System 2
    P->>P: Periodic Polling Task
    P->>B1: Poll Open Tickets
    B1->>P: Return Ticket Data
    P->>P: Check: Are Open Tickets > 50?
    alt Open Tickets > 50
        P->>B2: Send Alert
        B2->>A: Deliver Alert
        A->>A: Receive Alert
    else Open Tickets ≤ 50
        P->>P: Generate Ticket Report
    end
    P->>P: Log Outcome
    P->>B2: Send Report (Periodic)
    B2->>A: Deliver Report
    A->>A: Receive Report