Version: Peki

Agents working together

A team answers while a customer waits: the main agent asks its specialists and writes one reply. Real work often goes the other way. One agent notices something, others act on it, a person approves the risky step, and someone checks the result later, with no customer message anywhere.

This page covers the pieces that make that possible:

Events an agent publishes, such as stock_low.
Subscriptions: an automation of another agent that starts on that event.
The team inside automation tasks: the deciding agent asks its specialists.
Flows: every run in the chain is tied together, with limits, and shown on one page.

Example: an Inventory agent checks stock every 15 minutes. When basil runs low it publishes stock_low. The main agent hears it, asks the Sales and Menu agents what to do and proposes a campaign. A manager approves it, and the Menu agent applies it. All of it is one flow.

Let the Copilot build it

Describe the chain in one sentence to the main agent's Copilot ("when inventory runs low, have sales and menu propose a campaign and ask me to approve it"). It creates the agents, the event, the automations and tests the whole chain before you switch anything on. See Working with the Copilot.

Events an agent publishes

An event is something an agent tells the other agents of the workspace, with a small payload. Open the agent and click Events in the sidebar to add one:

Setting	What it is	Limit
Key	The event's name, like `stock_low`.	Lowercase letters, digits and `_`, starting with a letter, up to 50 characters. Unique in the agent.
What it means and when it is published	Read by people and by the Copilot of every agent that subscribes.	Required, up to 500 characters
Fields	The payload's shape. The same field types as Records (text, number, money, date, choice and so on), except references and files. Each has a key, a type, a description and Required.	Up to 20 fields
Publish the same alert once per	The dedupe window.	1 to 168 hours, default 24

An agent can have up to 20 events. They are part of the agent's draft, so they are versioned and published like tools. Other agents see only published events: until you publish the agent, the event shows Draft and the page says Publish the agent so other agents can subscribe.

Each event card also shows Published by (the agent's publish_ tool and the Functions that publish it) and Subscribers (the automations that listen, with paused next to any that stopped).

Publishing

There are two ways to publish.

From a model run. In a conversation, an automation task or a team call, the agent gets one tool per event, named publish_<key> (for example publish_stock_low). The model fills the fields; they are checked against the event, and a payload that doesn't fit is not published.
From code, with no model. A Function that runs as an automation's check or action calls:
```
await ctx.events.publish('stock_low', { product: 'Basil', remaining: 3, level: 'critical' }, { dedupeKey: 'basil-2026-11-07' });
```
Because no model runs, a check every 15 minutes costs almost nothing until it finds something. A run may publish at most 10 events.

A payload is at most 8 KB. Customer personal data stays as placeholders when a conversation run publishes, the same rule as team briefs.

Dedupe

Alerts tend to come back. Give the event a dedupe key (dedupeKey), for example the product and the day. The same dedupe key from the same agent and event, within the event's window, is dropped and recorded as Deduped instead of being published again. Without a dedupe key, nothing is deduped. A dedupe key is up to 200 characters.

Tests never reach subscribers

Dry runs and test conversations don't publish real events. The event shows as Simulated ("Would publish") in the run and in the flow, and no real subscriber starts. To follow a published event down the chain without side effects, use Test a flow.

An automation can start on another agent's event.

Open the deciding agent's Automations and create or open an automation.
Under When, choose Peki event, then the event Another agent's event.
Pick the Agent, then the Event. Only published events are listed. If none exist you see No agent publishes an event yet. Add one under the agent's Events and publish it.
Optionally add rules on the event's data: all must hold for the automation to run, for example level equals critical or remaining is less than 10.

Everything after the trigger (check, continue when, action, task, notify, limits) works as in Automations. The agent's Events page also lists Events of other agents you can subscribe this agent to.

The check and the action Function receive the event in ctx.trigger.payload:

Another agent's event
{
  "from": { "id": "6720…", "name": "Inventory" },
  "key": "stock_low",
  "data": { "product": "Basil", "remaining": 3, "level": "critical" },
  "flowId": "6721…"
}

The task gets a short, size-capped summary of the same payload. A run started this way is labelled Agent event: stock_low in the Runs tab.

Notes:

Only agents of the same workspace can subscribe. An agent can subscribe to its own events too.
Every subscriber runs independently. Delivery is at least once.
Events from tests never start a real subscriber.
If the source goes away, the subscriber pauses itself with "Source event no longer exists: the agent that published it removed it or was deleted. Pick another event, then resume." This happens when the source agent removes the event or is deleted.

The team in an automation task

An automation's task can ask the agent's team, the same way a customer reply does. Under Allowed actions, add the team's ask_<name> tools. Each is listed with the member's name ("asks Sales").

The ask_ tools don't count as write actions, so adding them needs no write approval. The same goes for the agent's own publish_<key> tools, which an automation's task can use to publish events.
The member has to be on the agent's team and published, and the tool has to exist in the published version for an automation that is on.
Members work in delegate mode: they never write to a channel or a customer. Only the automation's own Notify sends messages, and only through its own agent's channels.
Their calls are the run's Team calls, linked to the automation run and shown under the member's Inbox → Team calls. The rules of Agent teams apply, including members having to be published.

Put the decision and the approvals in the main agent, and the doing in the specialists.

Flows

A flow is one chain of work. Peki ties together every run that one starting point causes, so you can read the whole story in one place.

A flow begins at an origin: a customer message, a schedule, a webhook request, Run now, or a Peki event. The origin creates a flow id, and everything it causes joins the same flow:

automation runs and the team calls they make,
events published,
records written,
approval requests, and the runs an approval decision starts (approval.decided carries the flow on).

A hop is one step along an event or an approval, counted from the origin. Team calls are depth, not hops. A flow has a status: Running, Waiting for approval, Done or Stopped.

Limits

Every flow has limits so that a chain can't run away. A run that would break a limit isn't started: it is recorded as Skipped — flow limit and the flow ends Stopped, with the reason.

Limit	Default	Allowed range
Hops	6	1 to 20
Runs per flow	30	1 to 500
Credits per flow	500 credits	1 to 100,000
Hours per flow (waiting for an approval counts)	24	1 to 168

Admins can change them under Settings → Workspace → Flow limits. Credits are charged as always: each run costs what it costs, and the flow only adds them up.

Loop protection

An automation is never started by an event it caused, directly or through other runs. Peki carries the chain of automations behind each event; if the automation that would start is in that chain, the run is recorded as Skipped — loop. This chain follows the events an automation publishes, the records it saves and the approvals it asks for.

Fan-out is not a loop: if one run publishes three stock_low events, the subscriber runs three times, once per event. The flow limits bound that. The one exception is an automation that continues after an approval it asked for.

If an automation already has 100 runs waiting, a new event is recorded as Skipped — previous run still going and dropped. See Triggers.

The Flows page

Click Flows in the sidebar. The page lists every flow of the workspace, newest first, with the origin, the agents involved, the status, the number of hops and runs, the credits and the duration. Filter by Agent and Status. Flows are kept for 30 days.

Open a flow to see it two ways:

Flow diagram. Each step is a box: which agent ran, and whether it was Done, Running, Waiting, Skipped or Failed. The boxes are linked in the order things happened.
Selected step. Click a box to see what that step did, under the diagram:
- how it was started (its schedule, "Started by stock_low from Inventory", an approval decision and so on),
- the Check result and the Answer,
- the Events published, each marked Published, Deduped, Simulated or Not published,
- the Team calls it made,
- the Records written,
- the Approvals,
- the Messages sent,
- its credits and time.
Links open the run, the conversation, the approval or the record. Open in Copilot asks the Copilot to look at the flow and say whether anything is wrong. A timeline below lists the same steps in order.

Test a flow

Before you switch a chain on, run all of it without side effects. On the starting automation, open Run once and click Test flow. Peki runs the automation and everything it starts as dry runs of the drafts:

published events reach their subscribers as dry runs,
writes are simulated,
nothing is sent,
every approval is assumed approved, and marked so.

You get the flow's page, tagged Test, with the full diagram. Check that each step you expect is there.

The Copilot does the same with its test_flow tool, and starts from an automation or from one of the agent's events as if it had just been published.

Limits at a glance

Limit	Value
Events per agent	20
Fields per event	20
Event payload	8 KB
Events published by one Function run	10
Dedupe window	1 to 168 hours, default 24
Hops / runs / credits / hours per flow	6 / 30 / 500 / 24 by default, editable by admins
Flows kept	30 days

Events an agent publishes​

Publishing​

Dedupe​

Tests never reach subscribers​

Subscribe to another agent's event​

The team in an automation task​

Flows​

Limits​

Loop protection​

The Flows page​

Test a flow​

Limits at a glance​

Related​