Three Ways to Trigger a Virtual Team

A virtual team becomes agentic when it can start work without waiting for a human to select it every time. The important design decision is not only what the agents do, but what is allowed to wake them up.

There are three practical trigger modes: a direct human command, a scheduled tick, and a callback or webhook from an external event. All three can launch the same team; they create very different operating models.

Three trigger modes

The same gateway can be reached from a chat channel, a timer, or another system. The distinction is who owns the decision to start:

Human command: a person chooses the channel, team, and moment.
Scheduled tick: an operating system timer checks whether the workflow should run.
Callback or webhook: an external event starts work as soon as it happens.

Three trigger paths — human command, scheduled tick, and external event — converge on a virtual team gateway. — Three trigger paths, one team gateway. Autonomy increases as the start decision moves from a person to time or events.

1. Direct human command

The most familiar mode is also the most visibly human-led: someone sends a message, selects a task, or calls an agent from a tool. In OpenClaw or Hermes, that command might arrive through Telegram, Discord, Slack, WhatsApp, or Microsoft Teams, then route into a shared gateway and its connected tools.

This is not a lesser pattern. It is the right choice for ambiguous work, approvals, exceptions, and tasks where context lives in a conversation. It also makes a useful control surface: a person can choose a role, add context, review the result, and decide what happens next.

The limitation is operational: if the person does not issue the command, the work does not start. A team that only responds to chat is an assistant. A team that can be called by schedules and events can become part of the operating system.

Direct command keeps selection and judgment with a person, while the gateway handles routing and execution.

2. Scheduled tick

A scheduled workflow starts because time has arrived: every five minutes, at 09:00 each weekday, or after a defined interval. Hermes documents a gateway cron scheduler that checks for due jobs and runs them in isolated sessions. OpenClaw likewise provides persistent cron jobs through its Gateway.

For business-critical timing, our preference is to separate the clock from the agent runtime. Put the precise, observable decision logic in a small script or application triggered by system cron on every tick. That application can check state, enforce idempotency, apply business rules, record evidence, and call the OpenClaw or Hermes Gateway API only when a real run is due.

This is a design recommendation, not a claim that built-in schedulers are unusable. It makes the timing contract easier to test and monitor, and it avoids treating a heartbeat — a periodic prompt intended to keep an agent aware — as a strict job scheduler. Use heartbeats for lightweight awareness; use a deterministic controller when missing or duplicating a run has a business cost.

System cron fires a controller on every tick; the controller checks state and calls a virtual team gateway only when a workflow is due. — Reliable scheduling puts the clock and idempotency check outside the model loop.

3. Callback or webhook

An external event starts the team when something meaningful happens: a payment fails, a pull request opens, a customer submits a form, or a deployment finishes. OpenClaw exposes authenticated HTTP endpoints for waking a main session or running an isolated agent turn. Hermes provides webhook subscriptions and routes for API calls and platform events.

Useful hook and event surfaces include:

OpenClaw webhooks: POST /hooks/wake for a system event and POST /hooks/agent for an isolated agent turn.
OpenClaw internal lifecycle hooks: command:new, command:reset, command:stop, session:compact:before, session:compact:after, session:auto-reset, agent:bootstrap, and message/session lifecycle events such as message:received.
OpenClaw plugin hooks: before_tool_call, after_tool_call, before_agent_reply, agent_end, gateway_start, gateway_stop, and cron lifecycle events such as cron_changed and cron_reconciled.
Hermes Gateway hooks: gateway:startup, session:start, session:end, session:reset, agent:start, agent:step, agent:end, and wildcard command:*.
Hermes plugin and shell hooks: pre_tool_call, post_tool_call, pre_llm_call, post_llm_call, on_session_start, on_session_end, subagent_start, and subagent_stop.

These are different layers, not one universal event list. Webhooks are ingress points from another service; lifecycle hooks observe or control work already inside the runtime. Keep authentication, replay protection, filtering, and an explicit action boundary around every external callback.

An external event provider sends an authenticated webhook to a gateway, which validates and routes the event to the appropriate virtual team. — Event-driven operation turns a business fact into a team action, with authentication and filtering before execution.

Key takeaway

Agentic operation is not defined by autonomy in the abstract. It is defined by whether the team can be triggered by time and events — with clear boundaries, evidence, and escalation — instead of waiting for a human prompt.

Make autonomy explicit

Start with the trigger that matches the risk. Keep direct commands for judgment-heavy work. Use a system-controlled tick for precise recurring checks. Use callbacks for facts that already exist elsewhere. In every case, define the owner, the acceptance rule, the retry behavior, and the human escalation path.

That is how a collection of agents becomes a virtual team: not by adding more model calls, but by giving the team dependable ways to enter the workday.

Documentation checked Aug 30, 2026

Join the discussion

Which trigger should start your next workflow: a human command, a dependable schedule, or an external business event?

Talk to us Browse the blog