AI Assistant

Connect the shared assistant to your existing Event Scheduler with createSchedulerAiActions from @revolist/scheduler. Scheduler remains the owner of events, permissions, conflicts, selection and history.

Try it without a backend

Try the Event Scheduler assistant

Choose a suggested request below. This scripted demo runs entirely in your browser, with no backend, model key or model calls. It recognizes only the suggested requests.

Try it: Read the scheduled events, then rename Customer workshop. Cancel keeps the original title; submit again and Apply to update the booking. Select Customer workshop to select it in the timeline. Times are shown in UTC.

The demo loads when visible.

Reset demo

Reset demo restores the original sample data and clears its conversation. To use your own prompts, follow the API-client setup guide.

Connect your scheduler

Start with a working Event Scheduler. Include AiAssistantPlugin alongside EventSchedulerPlugin before mounting your grid, and import both packages’ styles:

import { EventSchedulerPlugin, createSchedulerAiActions } from '@revolist/scheduler';
import { AiAssistantPlugin, type AiViewInterpreter } from '@revolist/revogrid-pro';
import '@revolist/revogrid-pro/styles.css';
import '@revolist/scheduler/styles.css';

grid.plugins = [EventSchedulerPlugin, AiAssistantPlugin]; // Keep your other plugins.
// Continue your scheduler configuration, resources, source and mount setup.

Add a container next to the grid, such as <div id="scheduler-assistant"></div>. Once the grid is mounted and its initial schedule has loaded, connect the native instance:

async function connectSchedulerAssistant(
  grid: HTMLRevoGridElement,
  host: HTMLElement,
  interpret: AiViewInterpreter,
) {
  const plugins = await grid.getPlugins();
  const scheduler = plugins.find(
    (plugin): plugin is EventSchedulerPlugin => plugin instanceof EventSchedulerPlugin,
  );
  const assistant = plugins.find(
    (plugin): plugin is AiAssistantPlugin => plugin instanceof AiAssistantPlugin,
  );
  if (!scheduler?.getProjection() || !assistant) {
    throw new Error('Load the scheduler with both plugins before connecting.');
  }
  grid.aiAssistant = {
    mountTo: host,
    interpret,
    fields: [],
    executor: {
      read: () => ({ sort: [] }),
      async apply() { throw new Error('Use native Scheduler actions for this view.'); },
    },
    actions: createSchedulerAiActions(scheduler, {
      read: { fields: ['id', 'title', 'startDateTime', 'endDateTime'], maxEvents: 20 },
      select: {},
      update: { fields: ['title', 'startDateTime', 'endDateTime', 'resourceId'] },
    }),
    ui: { mode: 'chat', suggestions: ['Read the scheduled events'] },
  };
  return () => { grid.aiAssistant = undefined; };
}

// A deterministic interpreter verifies the connection without a model or HTTP route.
const interpret: AiViewInterpreter = async () => ({
  kind: 'action', name: 'scheduler.readEvents', input: { limit: 3 },
});
const host = document.getElementById('scheduler-assistant');
if (!host) throw new Error('Missing Scheduler assistant container.');
const disconnectAssistant = await connectSchedulerAssistant(grid, host, interpret);
// Call disconnectAssistant() when your application view unmounts.

grid is your existing mounted grid. This interpreter always reads up to three permitted events. Replace it with your authenticated API-client interpreter for natural-language requests. Forward its signal, return the parsed assistant response, and keep provider keys on your backend. See the API-client setup and backend guide.

Keep fields: [] and the action-only executor: generic grid filtering, sorting or cell edits must not operate on Scheduler’s generated projection. Recreate the actions when disclosure or update policies change.

Supported event actions

No actions are enabled by default. Each option explicitly registers its corresponding operation.

Action	Behavior	Input example
scheduler.readEvents	Read allowlisted fields from loaded projected events.	{ "limit": 3 }
scheduler.selectEvents	Replace native selection by stable ID; [] clears selection.	{ "ids": ["booking-1"] }
scheduler.updateEvent	Preview a local event patch, then Apply or Cancel.	{ "id": "booking-1", "patch": { "title": "Product workshop" } }

For example, your backend can return the following response using a real event ID from your application:

{
  "kind": "action",
  "name": "scheduler.updateEvent",
  "input": { "id": "booking-1", "patch": { "title": "Product workshop" } }
}

The assistant shows current and proposed values. Cancel leaves the event unchanged. Apply calls native editEvent; locked/read-only events, editing permissions, conflict rules and cancelable before-change events still apply. Changed projections invalidate pending previews. Native history records accepted edits when configured through Scheduler history.

Update fields are title, startDateTime, endDateTime, resourceId, resourceIds, status and progress. Reads also support id, locked and readonly. Updates must use your explicitly allowed subset. Supply valid datetimes and existing resource IDs; native validation rejects invalid ranges or blocking conflicts. Omitted fields remain unchanged. This adapter does not create or delete events.

Disclosure and remote schedules

Reads accept optional ids and limit, return at most 50 events and 16 KiB, and include scope: 'loaded-projection' plus remote enabled/partial flags. They do not query the entire remote schedule. Selection accepts up to 100 loaded event IDs; string and numeric IDs remain distinct.

Use read.canRead, select.canSelect and update.canUpdate to narrow per-event policy. Configured read permission also applies to explicitly targeted selections and updates. Only disclosed read fields appear in results; notes and metadata are excluded. Results remain in the host UI unless you explicitly configure evidence forwarding to the model.

Remote schedules support reads and selection. AI updates require a local schedule and are rejected when remote mode is enabled, including at Apply. For saved remote data, provide application-owned prepared actions backed by your authorized service. See remote mutations.

Your backend must authenticate users and enforce its own action, field and evidence policies. Client action descriptors describe available operations; they do not grant server authorization.