Gluesync AI Hub · Spark agents on schedules, events, and signals

From one good answer to work that runs itself.

AI Workflows connect the Spark agents you publish in AI Studio to the triggers your operation already has: Chronos schedules, Core Hub platform events, inbound webhooks, chained pipeline steps, your applications, and even a SQL row. Each run is durable, idempotent, budgeted, and auditable, and every write still waits for a person.

  1. 01 Publish an immutable Spark agent version
  2. 02 Pick the trigger: schedule, event, webhook, chain, API, or SQL
  3. 03 Runs are durable, idempotent, budgeted, and approved where they write

How it works

Publish once. Trigger from anywhere. Keep the brake.

  1. 01

    Publish

    Freeze the agent

    In AI Studio, instructions, skill versions, routing policy, step and duration limits, cost ceiling, and output contract become an immutable agent version with a content hash. Automation always calls a version, never a moving target.

  2. 02

    Trigger

    Let the operation fire it

    Chronos fires ai_agent_run from a cron schedule, a platform event, or a webhook, and as a step in a chained event after snapshots, CDC, Validator, or Query Studio work. Applications post runs to the API. SQL clients ask through gluesync.ai.

  3. 03

    Run and verify

    Durable, bounded, reviewable

    Every run moves through QUEUED, ROUTING, and RUNNING to a terminal state with a redacted outcome and an ordered SSE timeline. Idempotency keys absorb retries, budgets stop runaway spend, and writes wait for a signed-in approval.

Workflow recipes

Six workflows teams run in the first month.

Each recipe uses a published agent version, a Chronos trigger, and the Core Hub tools on that agent's allow-list. Swap the pipeline names and they are yours.

Operations

Overnight sync digest

TriggerChronos schedule · 0 8 * * 1-5

  1. Fire the published ops-digest agent version with a prompt template that names the pipelines to review
  2. The agent reads pipeline status, per-entity progress, agent metrics, and webhook dead letters
  3. send_email_notification and send_webhook_notification deliver the digest at the severity it decided
Outcome

The team reads a correlated summary before stand-up. Idempotency key ops-digest-{{date}} means a retried schedule never sends it twice.

Triage sync health →

On-call

Every CRITICAL alert arrives explained

TriggerPlatform event · notification created, severity CRITICAL

  1. Chronos passes the allow-listed notification fields into the prompt template
  2. The agent gets a read-only tool set scoped to the alert's pipeline, agent, and entity, plus documentation and support knowledge search
  3. The explanation is posted back through the configured webhook channel
Outcome

The person on call opens the alert with the likely cause and the documented next step already attached. The loop guard ensures the agent's own AI_RUN_* events never re-trigger it.

Explain this alert →

Support

Helpdesk ticket triage

TriggerWebhook trigger flow · POST from the ticketing system

  1. The payload allow-list admits ticket.id, ticket.subject, and ticket.body; everything else is dropped before the prompt
  2. The published triage agent classifies the ticket and checks the affected pipeline's current status
  3. Idempotency key ticket-{{ticket.id}} returns the existing run on a duplicate delivery instead of starting a second one
Outcome

Duplicate webhooks are harmless, the model only ever sees the fields you chose, and the run outcome is stored redacted in Core Hub.

Embed in applications →

Data quality

Snapshot, validate, explain

TriggerChained event · Sunday 02:00

  1. Stop CDC, run a one-time snapshot of CUSTOMERS, start CDC again
  2. Run a Validator comparison between source and target as the next synchronous step
  3. Fire the reconciliation agent with the comparison id; it summarizes the differences in business terms and emails the owner
Outcome

Monday starts with proof that source and target agree, and a plain-language note on the rows that do not.

Validate and reconcile →

Compliance

Monthly PII sweep

TriggerChronos schedule · first of the month

  1. The agent calls classify_schema on every SQL-capable agent in the billing pipeline; it receives labels, never cell values
  2. It compares the result with the field functions already masking columns on the target
  3. New findings go to compliance by email, with the documentation reference for masking
Outcome

An auditable record every month that sensitive columns are known, and that nobody had to SELECT * from production to produce it.

Hunt for sensitive columns →

Analytics

A saved query becomes a narrated report

TriggerChained event · Chronos Query Studio action, then ai_agent_run

  1. Chronos runs the saved Query Studio query the analyst reviewed, read-only
  2. The published reporting agent reopens the same query with get_saved_query and reads the fresh numbers
  3. It writes the narrative, cites the tables through the Enterprise brain, and sends it through the webhook into the team channel
Outcome

The analyst keeps ownership of the SQL. The agent only adds the words, on a schedule, with a budget.

SQL AI →

Controls

The guardrails that make automation acceptable to security

An agent that runs unattended needs tighter rules than one that runs in a chat window. AI Workflows inherit every control from AI Studio and add the ones only automation needs.

Identity

The owner's permissions

A Chronos or API-key run executes as its owner through existing Core Hub RBAC and Query Studio data-access rules. There is no privileged automation account.

  • Owner recorded on every run
  • Per-agent MCP tool allow-list
  • Read-only deployments with one setting

Payload

Prompt templates with an allow-list

Templates reference trigger fields as {{dotted.path}} tokens. Only fields on the allow-list are substituted; everything else never reaches the model.

  • Structured agent_input beside the prompt
  • 64 KiB cap on webhook bodies
  • Credentials scrubbed before provider or history
Chronos AI agent runs →

Duplicates

Idempotency and correlation

An idempotency key template such as ticket-{{ticket.id}} returns the existing run on redelivery. A correlation id ties the run to the event, chain, or request that caused it.

  • 409 on a conflicting payload under the same key
  • Cancellation from the Runs workspace or API
  • AMBIGUOUS outcome instead of a pretended success

Loops

Loop guards and stop reasons

AI_RUN_* events never trigger another AI run, webhook chains get one hop, and the in-run loop policy bounds steps, repeated calls, failure streaks, duration, and cost.

  • Max duration from 1 second to 1 hour per version
  • Identical-call fingerprints
  • A recorded stop reason when the guard fires

Spend

Budgets, keys, rate limits

Owner and platform-key budgets with soft and hard limits, scoped gsa_ keys with agent and model allow-lists, requests per minute, and expiry.

  • 402 BUDGET_EXCEEDED before the provider call
  • Optional token prices for estimated spend
  • Usage accounting per owner, key, and model
Governance and developer API →

Writes

Approvals and confirmations

Writes requested by a Chronos or API-key run pause at WAITING_APPROVAL until someone signed in approves or rejects. Remote company-tool calls count as writes.

  • Destructive tools park with Confirm or Cancel
  • Pending pipeline changes expire after five minutes
  • Approval recorded on the run timeline

Delivery

Report through approved channels

Agents report through the webhooks and SMTP configuration Core Hub already has, at INFO, WARNING, or CRITICAL severity, so nothing new has to be opened on the network.

  • send_webhook_notification and send_email_notification
  • Delivery logs and dead letters are inspectable
  • Company tools such as GitLab or Notion when approved
Skills and company tools →

Evidence

Timelines and audit

Every provider and capability step of a published run is persisted, so a Core Hub restart resumes what is safe and marks an at-most-once write ambiguous rather than lost.

  • Ordered SSE event history per run
  • Redacted errors and outputs
  • Safe audit records without provider secrets

Routing

Deterministic model selection

A workflow should not break because one provider is down. The routing policy ranks catalog models by capability, residency, health, price, latency, and quality, with ranked fallbacks and circuit breaking.

  • Preview inclusions and exclusions before a run
  • model: auto on the OpenAI-compatible API
  • Local Ollama models for data that must not leave
Models and routing →

FAQ

AI Workflows: questions we hear

What exactly does Chronos fire?

A published, immutable Spark agent version. The Chronos action is AI agent run (task type ai_agent_run): you pick the agent slug and version, a prompt template with allow-listed {{dotted.path}} tokens from the trigger payload, optional structured agent_input, and an idempotency key template. The run then follows the same lifecycle as any other run: QUEUED, ROUTING, RUNNING, then SUCCEEDED, FAILED, CANCELLED, or AMBIGUOUS.

How do I stop a workflow from looping?

Chronos ignores AI_RUN_* platform events as triggers for AI agent runs, so a run can never fire the chain that started it, and a webhook-triggered chain is allowed one hop. Inside the run, the loop policy bounds steps, identical-call fingerprints, failure streaks, duration (1 second to 1 hour), and cost, and records a stop reason when it intervenes.

Can a scheduled agent change my pipelines or data?

Only through tools on its allow-list, with the permissions of the owner it runs as, and never silently. Writes started by an API key or by Chronos pause at WAITING_APPROVAL until someone signed in approves or rejects them. Destructive tools park in chat with Confirm or Cancel. Read-only deployments hide every write tool with one setting.

What happens when a webhook is delivered twice?

The idempotency key returns the existing run instead of starting a new one, and a conflicting payload under the same key is rejected with 409. Trigger bodies are capped at 64 KiB, and only payload fields on the allow-list ever reach the prompt template.

How do I bound what an automated agent can spend?

Budgets per owner or per platform key with soft and hard limits; a hard limit returns 402 BUDGET_EXCEEDED before the provider is called. Scoped gsa_ keys carry agent and model allow-lists, requests-per-minute limits, and expiry. Every run records the selected model, usage, and a redacted outcome you can audit.

Can a workflow live outside Gluesync?

Yes. Your own scheduler or application can start runs through the native /api/ai/v1 contract or the OpenAI-compatible endpoints, follow progress on the SSE event stream, and read results back. External MCP clients such as Claude or Cursor can call start_agent_run and get_agent_run with the caller's token.

Gluesync AI Hub

Automate the answer, not the accountability.

Publish the agent, choose the trigger, bound the spend, and keep every write behind a person. AI Workflows ship with Gluesync 2.3 as part of AI Hub, with Chronos, Query Studio, and Validator as the steps around them.