Agentic execution

When the platform runs your agents.

Prompt templates don't run themselves. Attach one to a hook and the platform invokes it at the moment you choose — during a form submission, after a record changes, or on a daily rhythm. This page covers the three kinds of moments, the hook points you can listen on, and the agents that already run in every workspace.

Three moments an agent can run

Every agent in wrk!ng is a prompt template attached to a hook. The hook decides when the template is invoked. There are three kinds of hooks, matched to the three moments your automation might need to act.

Moment	Hook type	What it's good for
While a user is filling in a form or advancing a workflow	Workflow hook	Validate a submission, enrich a record before it saves, gate a step transition, surface suggestions inline.
Right after a record is created, updated, or archived	Event hook	Tag a new task, auto-follow up on a new client, draft a recognition post when an employee hits an anniversary.
On a recurring daily rhythm	Scheduled agent	Morning digests, wellness nudges, birthday round-ups, short AI tips, calendar reminders.

All three are configured the same way: through the admin UI under Automation → Prompt hooks, or through a pack manifest that ships the prompt template and hook together.

Workflow hook points

A workflow hook fires inline during the request that triggered it. The LLM response is part of the same transaction as the originating write, which means a pre_* hook can rewrite the submission, enrich it with additional data, or return a validation error that blocks the save.

Hook point	Fires…	Can block the write?
`pre_create`	Before a new record is inserted	Yes
`post_create`	Immediately after insert	No
`pre_update`	Before an update is applied	Yes
`post_update`	Immediately after update	No
`pre_step_transition`	Before a workflow instance advances to the next step	Yes
`post_step_transition`	After the step transition commits	No
`pre_submit`	Before a terminal workflow submission is accepted	Yes
`post_submit`	After a submission is recorded	No
`on_validation`	During validation, so the prompt can return structured errors or suggestions	Yes

A hook can be scoped to every record of a workflow, to a single step, or to a specific form element — bind it to whichever level matches the behaviour you want.

Embedded forms fire the same hooks

A post_create hook on a client workflow fires whether the record was created by a signed-in admin or by an anonymous visitor submitting a <wrk-form> on your marketing site. The hook layer does not distinguish between authenticated and embed traffic.

Event hooks

Event hooks subscribe to lifecycle events by name and run after the originating write has committed. They cannot reject the write; their output is a new action — a task, a feed post, a notification, a follow-up record.

Attach an event hook by selecting one or more event types when you create the hook:

{
  "hook_point": "on_event",
  "event_types": ["client.created", "client.updated"],
  "prompt_template": "crm-new-client-follow-up"
}

Typical patterns:

Auto-tagging — on task.created, a hook picks tags from a controlled vocabulary via an MCP tool.
Follow-up drafting — on client.created, a hook writes a welcome email and stores it as a task assigned to the relationship manager.
Recognition posts — on employee.anniversary, a hook posts a short celebratory message to the Digital Cafe feed.
External mirroring — on *.archived, a hook ships the record to an external knowledge base through an MCP-backed tool call.

The same events that drive event hooks are also available over webhooks and SSE if you'd rather act on them from your own service.

Event hooks cannot veto the write

Because they run after commit, their output can't reshape or reject the change that produced the event. If you need the LLM to block or rewrite a submission, use a workflow hook on pre_create, pre_update, or on_validation instead.

What runs throughout the day

Every workspace ships with a handful of scheduled agents. They run on wall-clock rhythms and quietly skip any organisation that hasn't installed the relevant pack or configured an AI provider. You don't wire them up — they come with the platform.

Weekday mornings: Brewster's strategic plan digest. A short cafe-manager post grounded in your active OGSM plan, posted to the Digital Cafe feed for leadership to anchor the day.
Every morning: Daily celebrations. Birthdays, work anniversaries, and team milestones, rolled up into a single friendly post so nothing slips through.
Weekday afternoons: Tia's wellness check-in. A late-afternoon nudge — a breath, a stretch, a reminder that the inbox can wait — delivered to everyone active in the workspace.
Twice a day, weekdays: Bev's AI tips. A short prompt-engineering trick or model-behaviour note, posted mid-morning and mid-afternoon for anyone building automation.
Throughout the day: Calendar reminders. Participants of upcoming calendar events are notified a few minutes before each one starts, so nobody needs a separate reminder app.

Each scheduled agent runs one prompt template against one audience. You can replace the template in the admin UI — point Brewster at your own OGSM phrasing, soften Tia's tone, swap Bev's tips for internal engineering prompts — without touching the schedule itself.

Shipping agents in a pack

The durable way to deliver an agent to a customer workspace is as part of a pack. A pack is a signed bundle that declares prompt templates, hooks, and any scheduled behaviour the installer should receive. Installing the pack registers the template, binds the hook, and (if the pack declares one) turns on the schedule — atomically, with a rollback path if the install fails.

At a conceptual level, a pack's agentic content looks like this:

{
  "prompt_templates": [
    {
      "slug": "new-client-welcome",
      "label": "New client welcome",
      "system_prompt": "You are a relationship manager…",
      "user_prompt_template": "A new client {{client.name}} was created. Draft a short welcome email…",
      "model_provider": "openai",
      "model_name": "gpt-4o"
    }
  ],
  "prompt_hooks": [
    {
      "hook_point": "on_event",
      "event_types": ["client.created"],
      "prompt_template_slug": "new-client-welcome"
    }
  ],
  "scheduled_agents": [
    {
      "slug": "friday-digest",
      "cadence": "weekly",
      "prompt_template_slug": "friday-digest"
    }
  ]
}

See Getting started → Packs for the full pack manifest contract.

Cadence, not cron

Scheduled agents in packs declare a cadence (daily, weekly, weekday_mornings, …) rather than a raw cron expression. The platform picks a reasonable time in the workspace's timezone and runs each org independently so multi-tenant workspaces don't stampede a single minute.

Tool calls from an agent

Prompt templates can invoke external data and actions through the MCP server. When you bind one or more MCP servers to a template, the LLM gets those tools in its function-calling surface and can call them during the same invocation — read a record, send an email, post to the feed, open a task — without a separate round-trip through your code.

Every tool call is logged against the prompt invocation and appears in the execution log alongside the LLM input and output, so you can replay what happened step by step.

Observing agent runs

Every agent invocation records an entry in the execution log, visible in the admin UI under Automation → Execution log. Each entry captures:

The template that ran and the hook that triggered it.
The rendered user prompt and the LLM's full response.
Any MCP tool calls the LLM made and their results.
Any records the agent wrote (task IDs, post IDs, notification IDs).
Latency, token counts, and any error returned by the provider.

The same data is available on the event stream as prompt.invoked, prompt.succeeded, and prompt.failed lifecycle events — subscribe through webhooks or SSE to pipe agent activity into your own observability stack.

Related references

AI integration — prompt template contract, providers, rate limits.
Events & SSE — the event names you can attach an event hook to.
Webhooks — deliver the same events to an external service if you'd rather handle them off-platform.
MCP server — tools an agent can call during a prompt invocation.
Getting started — auth, request lifecycle, and pack installation.