Introducing Edge Delta Workflows: AI-Powered Investigation Meets Deterministic Automation

Trigger Nodes

The trigger node is the entry point into a Workflow, and it supports four distinct trigger types:

• Monitor events: Any Edge Delta monitor (metric threshold, pattern anomaly, synthetic check, log threshold, composite) can trigger a Workflow when it fires.
• Connector events: GitHub pull requests, PagerDuty incidents, CircleCI build completions, and 60+ other event types from your connected integrations.
• Scheduled runs: Cron-based periodic execution with timezone support. Run a health check Workflow every morning, or a compliance scan every Friday.
• Manual execution: Trigger a Workflow on demand when you need it.

AI Teammate Nodes

The AI Teammate node prompts a Teammate of your choice to run a full investigation using the tools it has access to, such as GitHub, Jira, PagerDuty, and Edge Delta’s MCP Server. Instead of responding with freeform text, the Teammate returns a JSON-schema-validated response that downstream nodes can parse, evaluate, and branch on for future logic.

If/Else Nodes

If/else nodes are simple JavaScript statements evaluated against structured data from upstream nodes that allow teams to build conditionality into their Workflows. For example, the following statement allows the Workflow to route differently based on the values of `data.severity` and `data.confidence`:
data.severity === “critical” && data.confidence > 0.8

Transform Nodes

Transform nodes reshape data between steps. For example, this node type can aggregate findings, extract fields, and format payloads. Each transform runs sandboxed JavaScript with access to the current data, previous node results, and Workflow state. 

Action Nodes

Action nodes are where deterministic execution happens. At launch, our Workflows support 21 specific operations across five platforms:

Slack (11 actions): Send messages to channels, create new channels, invite users, set channel topics and descriptions, list channels and members, archive channels.

Jira (4 actions): Create issues with specific project, type, assignee, and priority. Add comments to existing issues. Transition issue statuses. Retrieve issue details.

PagerDuty (3 actions): List services, get the current on-call user for a schedule, create incidents with defined urgency and type.

Microsoft Teams (3 actions): Find users, send messages to team channels with mentions, reply to existing message threads.

Email: Send emails with recipients, CC, BCC, and templated content.

Every action node supports configurable retry logic, with intervals up to 60 seconds and up to five retry attempts.

Building Workflows in Edge Delta

Edge Delta makes building Workflows intuitive. First, navigate to the Workflows tab in your AI Teammates account and click the “New Workflow button”:

From there, you can drag nodes onto the canvas, configure their parameters, connect them, and define when and how they run, including schedules and conditional branching:

For more detailed information on workflows, be sure to check out our official documentation.

The Structured Output Bridge

When an AI Teammate node runs inside a Workflow, you define a JSON schema for its output. The Teammate investigates freely, querying logs, checking metrics, reviewing deployments, but its final response is validated against that schema. In practice, it might look something like what’s shown below, where a Teammate investigates a latency spike and returns the following JSON:

{
  "severity": "critical",
  "affected_service": "checkout-api",
  "estimated_user_impact": "high",
  "error_rate_change": "12x baseline",
  "correlated_deployment": "deploy-a1b2c3",
  "root_cause_hypothesis": "Memory leak in connection pooling after v2.4.1 merge",
  "confidence": 0.91
}

The next node then checks whether data.severity === “critical” && data.estimated_user_impact === “high”:

The structured JSON output enables downstream agents and nodes to query the data, evaluate conditions, and trigger the appropriate actions. In this case, if the severity is critical and estimated user impact is high, the following action node creates a PagerDuty incident using those structured fields. The Slack message includes the root cause hypothesis and the correlated deployment, and the corresponding Jira ticket references the affected service and the deployment hash: 

Monitor-Triggered Incident Automation

A synthetic monitor detects your checkout API returning 503s, triggering the associated Workflow:

An AI Teammate node kicks off an investigation, searching application logs around the failure window, querying error rate and latency metrics, checking GitHub for recent merges to the checkout service, and reviewing PagerDuty for related open incidents. It then returns a structured output containing severity, affected service, user impact assessment, correlated deployment, and confidence score. 

From there, an if/else node evaluates severity and confidence to determine the path forward. On the critical path, a PagerDuty incident is created with full structured context, a dedicated Slack channel (#inc-checkout-031) is spun up, the on-call engineer and service owner are invited, and an investigation summary is posted. On the low-severity path, a Jira ticket is created in the backlog with the Teammate’s findings, a summary is posted to the team Slack channel, and no page is sent.

Deployment Verification via GitHub Events

A GitHub deployment event fires when a service is pushed to production, triggering the Workflow shown below:

An AI Teammate node waits five minutes before evaluating error rates, latency percentiles, and log volume anomalies against pre-deploy baselines. It returns a structured output containing the deployment health status, metric deltas, and any anomaly findings. An if/else node then evaluates whether degradation was detected. If it was, a Jira ticket is created for rollback evaluation, the deployer is notified in Slack with the specific metrics in question, and the service owner is added to the thread. If the deployment looks healthy, the deployment thread is simply updated with “Verified — no anomalies detected post-deploy.”

Scheduled Operational Health Check

Every weekday at 9:00 AM, a cron job triggers this operational health check Workflow:

An AI Teammate node first reviews overnight monitor activity and checks for unresolved alerts, then queries resource utilization trends across key services. From there, a transform node aggregates the findings into a structured daily report, covering open issues, trending risks, and service health scores, which is posted to #ops-daily in Slack.