@electric-ax/agents 0.2.1 → 0.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/entrypoint.js +5 -3
- package/dist/index.cjs +5 -3
- package/dist/index.js +5 -3
- package/docs/entities/agents/horton.md +89 -0
- package/docs/entities/agents/worker.md +102 -0
- package/docs/entities/patterns/blackboard.md +111 -0
- package/docs/entities/patterns/dispatcher.md +77 -0
- package/docs/entities/patterns/manager-worker.md +127 -0
- package/docs/entities/patterns/map-reduce.md +81 -0
- package/docs/entities/patterns/pipeline.md +101 -0
- package/docs/entities/patterns/reactive-observers.md +125 -0
- package/docs/examples/mega-draw.md +106 -0
- package/docs/examples/playground.md +46 -0
- package/docs/index.md +208 -0
- package/docs/quickstart.md +201 -0
- package/docs/reference/agent-config.md +82 -0
- package/docs/reference/agent-tool.md +58 -0
- package/docs/reference/built-in-collections.md +334 -0
- package/docs/reference/cli.md +238 -0
- package/docs/reference/entity-definition.md +57 -0
- package/docs/reference/entity-handle.md +63 -0
- package/docs/reference/entity-registry.md +73 -0
- package/docs/reference/handler-context.md +108 -0
- package/docs/reference/runtime-handler.md +136 -0
- package/docs/reference/shared-state-handle.md +74 -0
- package/docs/reference/state-collection-proxy.md +41 -0
- package/docs/reference/wake-event.md +132 -0
- package/docs/usage/app-setup.md +165 -0
- package/docs/usage/clients-and-react.md +191 -0
- package/docs/usage/configuring-the-agent.md +136 -0
- package/docs/usage/context-composition.md +204 -0
- package/docs/usage/defining-entities.md +181 -0
- package/docs/usage/defining-tools.md +229 -0
- package/docs/usage/embedded-builtins.md +180 -0
- package/docs/usage/managing-state.md +93 -0
- package/docs/usage/overview.md +284 -0
- package/docs/usage/programmatic-runtime-client.md +216 -0
- package/docs/usage/shared-state.md +169 -0
- package/docs/usage/spawning-and-coordinating.md +165 -0
- package/docs/usage/testing.md +76 -0
- package/docs/usage/waking-entities.md +148 -0
- package/docs/usage/writing-handlers.md +267 -0
- package/package.json +2 -1
- package/skills/quickstart/scaffold/package.json +16 -3
- package/skills/quickstart/scaffold/tsconfig.json +8 -3
- package/skills/quickstart/scaffold/vite.config.ts +21 -0
- package/skills/quickstart/scaffold-ui/index.html +12 -0
- package/skills/quickstart/scaffold-ui/main.tsx +235 -0
- package/skills/quickstart.md +244 -334
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Map-Reduce
|
|
3
|
+
titleTemplate: '... - Electric Agents'
|
|
4
|
+
description: >-
|
|
5
|
+
Parallel processing pattern that splits work into chunks, processes simultaneously, and reduces results.
|
|
6
|
+
outline: [2, 3]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Map-Reduce
|
|
10
|
+
|
|
11
|
+
Pattern: split input into chunks, process all in parallel, collect results.
|
|
12
|
+
|
|
13
|
+
**Source:** [`packages/agents-runtime/skills/designing-entities/references/patterns/map-reduce.md`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/map-reduce.md)
|
|
14
|
+
|
|
15
|
+
## Registration
|
|
16
|
+
|
|
17
|
+
```ts
|
|
18
|
+
export function registerMapReduce(registry: EntityRegistry) {
|
|
19
|
+
registry.define(`map-reduce`, {
|
|
20
|
+
description: `Map-reduce orchestrator that splits input into chunks, processes them in parallel with worker agents, then synthesizes results`,
|
|
21
|
+
state: {
|
|
22
|
+
children: { primaryKey: `key` },
|
|
23
|
+
},
|
|
24
|
+
|
|
25
|
+
async handler(ctx) {
|
|
26
|
+
ctx.useAgent({
|
|
27
|
+
systemPrompt: MAP_REDUCE_SYSTEM_PROMPT,
|
|
28
|
+
model: `claude-sonnet-4-5-20250929`,
|
|
29
|
+
tools: [...ctx.electricTools, createMapChunksTool(ctx)],
|
|
30
|
+
})
|
|
31
|
+
await ctx.agent.run()
|
|
32
|
+
},
|
|
33
|
+
})
|
|
34
|
+
}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## How it works
|
|
38
|
+
|
|
39
|
+
The agent exposes a `map_chunks` tool. When called:
|
|
40
|
+
|
|
41
|
+
1. **Map phase** -- spawns one worker per chunk simultaneously. All workers run in parallel.
|
|
42
|
+
2. Returns immediately. The entity is re-invoked as each worker finishes.
|
|
43
|
+
3. The LLM synthesizes results once all workers have reported in via wake events.
|
|
44
|
+
|
|
45
|
+
## Core
|
|
46
|
+
|
|
47
|
+
```ts
|
|
48
|
+
// Map phase - spawn all workers in parallel
|
|
49
|
+
for (let i = 0; i < chunks.length; i++) {
|
|
50
|
+
spawnCounter++
|
|
51
|
+
const id = `chunk-${i}-${Date.now()}-${spawnCounter}`
|
|
52
|
+
const child = await ctx.spawn(
|
|
53
|
+
`worker`,
|
|
54
|
+
id,
|
|
55
|
+
{ systemPrompt: task, tools: [`read`] },
|
|
56
|
+
{
|
|
57
|
+
initialMessage: chunks[i],
|
|
58
|
+
wake: `runFinished`,
|
|
59
|
+
}
|
|
60
|
+
)
|
|
61
|
+
ctx.db.actions.children_insert({
|
|
62
|
+
row: { key: id, url: child.entityUrl, chunk: i },
|
|
63
|
+
})
|
|
64
|
+
}
|
|
65
|
+
|
|
66
|
+
return {
|
|
67
|
+
content: [
|
|
68
|
+
{
|
|
69
|
+
type: `text` as const,
|
|
70
|
+
text: `Spawned ${chunks.length} parallel workers. You will be woken as each finishes with its output in finished_child.response.`,
|
|
71
|
+
},
|
|
72
|
+
],
|
|
73
|
+
details: { chunkCount: chunks.length },
|
|
74
|
+
}
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## State collections
|
|
78
|
+
|
|
79
|
+
| Collection | Purpose |
|
|
80
|
+
| ---------- | ---------------------------------------------- |
|
|
81
|
+
| `children` | Spawned chunk workers (key, URL, chunk index). |
|
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Pipeline
|
|
3
|
+
titleTemplate: '... - Electric Agents'
|
|
4
|
+
description: >-
|
|
5
|
+
Sequential processing pattern where each stage's output feeds into the next via state transitions.
|
|
6
|
+
outline: [2, 3]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Pipeline
|
|
10
|
+
|
|
11
|
+
Pattern: sequential stages where each stage's output feeds into the next.
|
|
12
|
+
|
|
13
|
+
**Source:** [`packages/agents-runtime/skills/designing-entities/references/patterns/pipeline.md`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/pipeline.md)
|
|
14
|
+
|
|
15
|
+
## Registration
|
|
16
|
+
|
|
17
|
+
```ts
|
|
18
|
+
export function registerPipeline(registry: EntityRegistry) {
|
|
19
|
+
registry.define(`pipeline`, {
|
|
20
|
+
description: `Pipeline orchestrator that chains sequential worker stages, feeding each stage output into the next`,
|
|
21
|
+
state: {
|
|
22
|
+
children: { primaryKey: `key` },
|
|
23
|
+
},
|
|
24
|
+
|
|
25
|
+
async handler(ctx) {
|
|
26
|
+
ctx.useAgent({
|
|
27
|
+
systemPrompt: PIPELINE_SYSTEM_PROMPT,
|
|
28
|
+
model: `claude-sonnet-4-5-20250929`,
|
|
29
|
+
tools: [...ctx.electricTools, createRunStageTool(ctx)],
|
|
30
|
+
})
|
|
31
|
+
await ctx.agent.run()
|
|
32
|
+
},
|
|
33
|
+
})
|
|
34
|
+
}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## How it works
|
|
38
|
+
|
|
39
|
+
The pipeline agent exposes a `run_stage` tool. The LLM drives the pipeline one stage at a time:
|
|
40
|
+
|
|
41
|
+
1. The LLM calls `run_stage` with an instruction and input for the current stage.
|
|
42
|
+
2. The tool spawns a worker with the instruction as its system prompt and the input as `initialMessage`, using `wake: 'runFinished'`.
|
|
43
|
+
3. The tool returns immediately. The pipeline entity is re-invoked when the worker finishes.
|
|
44
|
+
4. On each re-invocation, the wake event contains `finished_child.response` with the stage's output. The LLM then calls `run_stage` again with the next stage's instruction and the previous output as input.
|
|
45
|
+
5. This repeats until all stages are complete.
|
|
46
|
+
|
|
47
|
+
## Stage tool
|
|
48
|
+
|
|
49
|
+
```ts
|
|
50
|
+
function createRunStageTool(ctx: HandlerContext): AgentTool {
|
|
51
|
+
let stageCount = 0
|
|
52
|
+
|
|
53
|
+
return {
|
|
54
|
+
name: `run_stage`,
|
|
55
|
+
label: `Run Stage`,
|
|
56
|
+
description: `Spawns a worker for one pipeline stage.`,
|
|
57
|
+
parameters: Type.Object({
|
|
58
|
+
instruction: Type.String({
|
|
59
|
+
description: `The instruction for this stage.`,
|
|
60
|
+
}),
|
|
61
|
+
input: Type.String({ description: `The input for this stage.` }),
|
|
62
|
+
}),
|
|
63
|
+
execute: async (_toolCallId, params) => {
|
|
64
|
+
const { instruction, input } = params as {
|
|
65
|
+
instruction: string
|
|
66
|
+
input: string
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
stageCount++
|
|
70
|
+
const parentId = entityIdFromUrl(ctx.entityUrl)
|
|
71
|
+
const id = `${parentId}-stage-${stageCount}`
|
|
72
|
+
|
|
73
|
+
const child = await ctx.spawn(
|
|
74
|
+
`worker`,
|
|
75
|
+
id,
|
|
76
|
+
{ systemPrompt: instruction, tools: [`read`] },
|
|
77
|
+
{ initialMessage: input, wake: `runFinished` }
|
|
78
|
+
)
|
|
79
|
+
ctx.db.actions.children_insert({
|
|
80
|
+
row: { key: id, url: child.entityUrl, stage: stageCount },
|
|
81
|
+
})
|
|
82
|
+
|
|
83
|
+
return {
|
|
84
|
+
content: [
|
|
85
|
+
{
|
|
86
|
+
type: `text` as const,
|
|
87
|
+
text: `Stage ${stageCount} spawned. You will be woken when it finishes.`,
|
|
88
|
+
},
|
|
89
|
+
],
|
|
90
|
+
details: { stage: stageCount },
|
|
91
|
+
}
|
|
92
|
+
},
|
|
93
|
+
}
|
|
94
|
+
}
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
## State collections
|
|
98
|
+
|
|
99
|
+
| Collection | Purpose |
|
|
100
|
+
| ---------- | --------------------------------------------------- |
|
|
101
|
+
| `children` | Spawned worker references (key, URL, stage number). |
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Reactive observers
|
|
3
|
+
titleTemplate: '... - Electric Agents'
|
|
4
|
+
description: >-
|
|
5
|
+
Pattern for entities that watch others and react to changes using ctx.observe() with wake conditions.
|
|
6
|
+
outline: [2, 3]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Reactive observers
|
|
10
|
+
|
|
11
|
+
Pattern: entities that watch other entities and react to changes.
|
|
12
|
+
|
|
13
|
+
**Source:** [`packages/agents-runtime/skills/designing-entities/references/patterns/reactive-observers.md`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/reactive-observers.md)
|
|
14
|
+
|
|
15
|
+
## Core mechanism
|
|
16
|
+
|
|
17
|
+
An entity calls `ctx.observe(entity(entityUrl), { wake: { on: 'change', collections: [...] } })` to start watching another entity. The `entity()` helper (imported from `@electric-ax/agents-runtime`) wraps a raw URL into the correct observe target. When the observed entity has new activity in the specified collections, the observer is woken.
|
|
18
|
+
|
|
19
|
+
## Monitor example
|
|
20
|
+
|
|
21
|
+
The monitor watches multiple entities and reports status changes.
|
|
22
|
+
|
|
23
|
+
**Source:** [`packages/agents-runtime/skills/designing-entities/references/patterns/reactive-observers.md`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/reactive-observers.md)
|
|
24
|
+
|
|
25
|
+
```ts
|
|
26
|
+
export function registerMonitor(registry: EntityRegistry) {
|
|
27
|
+
registry.define(`monitor`, {
|
|
28
|
+
description: `Health dashboard agent that watches multiple entities and reports status changes and anomalies`,
|
|
29
|
+
state: {
|
|
30
|
+
status: { primaryKey: `key` },
|
|
31
|
+
},
|
|
32
|
+
|
|
33
|
+
async handler(ctx) {
|
|
34
|
+
if (ctx.firstWake) {
|
|
35
|
+
ctx.db.actions.status_insert({ row: { key: `current`, value: `idle` } })
|
|
36
|
+
}
|
|
37
|
+
const baseObserveTool = createObserveTool(ctx)
|
|
38
|
+
const observeTool = {
|
|
39
|
+
...baseObserveTool,
|
|
40
|
+
execute: async (toolCallId: string, params: unknown) => {
|
|
41
|
+
ctx.db.actions.status_update({
|
|
42
|
+
key: `current`,
|
|
43
|
+
updater: (draft) => {
|
|
44
|
+
draft.value = `observing`
|
|
45
|
+
},
|
|
46
|
+
})
|
|
47
|
+
return baseObserveTool.execute(toolCallId, params)
|
|
48
|
+
},
|
|
49
|
+
}
|
|
50
|
+
|
|
51
|
+
ctx.useAgent({
|
|
52
|
+
systemPrompt: MONITOR_SYSTEM_PROMPT,
|
|
53
|
+
model: `claude-sonnet-4-5-20250929`,
|
|
54
|
+
tools: [...ctx.electricTools, observeTool],
|
|
55
|
+
})
|
|
56
|
+
await ctx.agent.run()
|
|
57
|
+
},
|
|
58
|
+
})
|
|
59
|
+
}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
The monitor wraps the base observe tool to also transition its own state to `observing`.
|
|
63
|
+
|
|
64
|
+
## The observe tool
|
|
65
|
+
|
|
66
|
+
The `observe_entity` tool lets the LLM decide what to watch:
|
|
67
|
+
|
|
68
|
+
```ts
|
|
69
|
+
import { entity } from '@electric-ax/agents-runtime'
|
|
70
|
+
|
|
71
|
+
export function createObserveTool(ctx: HandlerContext): AgentTool {
|
|
72
|
+
return {
|
|
73
|
+
name: `observe_entity`,
|
|
74
|
+
label: `Observe Entity`,
|
|
75
|
+
description: `Start observing another entity by its URL. The current entity will wake with a change payload when the observed entity has new activity.`,
|
|
76
|
+
parameters: Type.Object({
|
|
77
|
+
entity_url: Type.String({
|
|
78
|
+
description: `The URL of the entity to observe`,
|
|
79
|
+
}),
|
|
80
|
+
collections: Type.Optional(
|
|
81
|
+
Type.Array(Type.String(), {
|
|
82
|
+
description: `Which collections to watch (default: all). Options: texts, textDeltas, runs, toolCalls, childStatus`,
|
|
83
|
+
})
|
|
84
|
+
),
|
|
85
|
+
}),
|
|
86
|
+
execute: async (_toolCallId, params) => {
|
|
87
|
+
const { entity_url, collections } = params as {
|
|
88
|
+
entity_url: string
|
|
89
|
+
collections?: string[]
|
|
90
|
+
}
|
|
91
|
+
try {
|
|
92
|
+
await ctx.observe(entity(entity_url), {
|
|
93
|
+
wake: { on: `change`, collections },
|
|
94
|
+
})
|
|
95
|
+
return {
|
|
96
|
+
content: [
|
|
97
|
+
{
|
|
98
|
+
type: `text`,
|
|
99
|
+
text: `Now observing entity: ${entity_url}. You will be woken when new activity is detected.`,
|
|
100
|
+
},
|
|
101
|
+
],
|
|
102
|
+
details: {},
|
|
103
|
+
}
|
|
104
|
+
} catch (err) {
|
|
105
|
+
return {
|
|
106
|
+
content: [
|
|
107
|
+
{
|
|
108
|
+
type: `text`,
|
|
109
|
+
text: `Error observing entity: ${err instanceof Error ? err.message : `Unknown error`}`,
|
|
110
|
+
},
|
|
111
|
+
],
|
|
112
|
+
details: {},
|
|
113
|
+
}
|
|
114
|
+
}
|
|
115
|
+
},
|
|
116
|
+
}
|
|
117
|
+
}
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
## Other reactive variants
|
|
121
|
+
|
|
122
|
+
- **Summarizer** -- observes an entity's `texts` and `textDeltas` collections and produces progressive summaries of its output.
|
|
123
|
+
- **Guardian** -- observes an entity's `texts` and `toolCalls` collections and evaluates output quality, checking for hallucination signals, safety issues, and formatting problems.
|
|
124
|
+
|
|
125
|
+
All three follow the same structure: register an entity, wrap `createObserveTool` with a state transition, configure the agent with the observe tool, and run.
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Mega Draw
|
|
3
|
+
titleTemplate: '... - Electric Agents'
|
|
4
|
+
description: >-
|
|
5
|
+
Multi-agent collaborative drawing example with coordinator-worker patterns and 100 tile agents.
|
|
6
|
+
outline: [2, 3]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Mega Draw
|
|
10
|
+
|
|
11
|
+
A collaborative multi-agent drawing app where 100 AI agents each own a tile of a shared 1000x1000 pixel canvas and work together to produce a drawing from a single text prompt. Located at `examples/mega-draw/` in the repository.
|
|
12
|
+
|
|
13
|
+
## What it demonstrates
|
|
14
|
+
|
|
15
|
+
- **Coordinator + worker pattern** at scale (1 coordinator spawning 100 tile agents)
|
|
16
|
+
- **Custom drawing tools** --- `fill_rect`, `draw_line`, `draw_circle`, `fill_gradient`, `set_pixels`
|
|
17
|
+
- **Shared canvas** --- in-memory pixel buffer flushed to PNG, served via a live viewer
|
|
18
|
+
- **Follow-up instructions** --- send a new prompt and only affected tiles get re-instructed
|
|
19
|
+
- **Two-pass workflow** --- coordinator does a quick first pass for backgrounds, then a detail pass
|
|
20
|
+
|
|
21
|
+
## Architecture
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
User
|
|
25
|
+
│
|
|
26
|
+
│ spawn /coordinator/my-drawing
|
|
27
|
+
│ send "Draw a sunset over mountains"
|
|
28
|
+
▼
|
|
29
|
+
┌────────────────────────────────┐
|
|
30
|
+
│ Coordinator Agent │
|
|
31
|
+
│ - Receives prompt │
|
|
32
|
+
│ - Plans composition + palette │
|
|
33
|
+
│ - Spawns 100 tile agents │
|
|
34
|
+
│ - Can re-instruct tiles │
|
|
35
|
+
└──────────┬─────────────────────┘
|
|
36
|
+
│ spawn tile-agent (10×10 grid)
|
|
37
|
+
▼
|
|
38
|
+
┌────────┐ ┌────────┐
|
|
39
|
+
│Tile 0,0│ │Tile 1,0│ ... (10 columns)
|
|
40
|
+
└────────┘ └────────┘
|
|
41
|
+
┌────────┐ ┌────────┐
|
|
42
|
+
│Tile 0,1│ │Tile 1,1│ ...
|
|
43
|
+
└────────┘ └────────┘
|
|
44
|
+
... ... (10 rows = 100 tiles)
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Each tile agent:
|
|
48
|
+
|
|
49
|
+
- Owns a 100x100 pixel region
|
|
50
|
+
- Can **see** 50px beyond its borders (200x200 viewport) for edge coordination
|
|
51
|
+
- Can only **draw** within its own tile
|
|
52
|
+
- Receives drawing instructions from the coordinator
|
|
53
|
+
|
|
54
|
+
## Key files
|
|
55
|
+
|
|
56
|
+
### `src/server.ts`
|
|
57
|
+
|
|
58
|
+
Entry point. Creates the registry, runtime handler, and two HTTP servers (one for the Electric Agents webhook, one for the canvas viewer).
|
|
59
|
+
|
|
60
|
+
```ts
|
|
61
|
+
const registry = createEntityRegistry()
|
|
62
|
+
registerCoordinator(registry, WEB_PORT)
|
|
63
|
+
registerTileAgent(registry)
|
|
64
|
+
|
|
65
|
+
const runtime = createRuntimeHandler({
|
|
66
|
+
baseUrl: ELECTRIC_AGENTS_URL,
|
|
67
|
+
serveEndpoint: `${SERVE_URL}/webhook`,
|
|
68
|
+
registry,
|
|
69
|
+
})
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
### `src/coordinator.ts`
|
|
73
|
+
|
|
74
|
+
The coordinator entity. Defines two custom tools:
|
|
75
|
+
|
|
76
|
+
- `set_drawing_plan` --- sets the composition description and color palette
|
|
77
|
+
- `instruct_tile` --- spawns or re-instructs a tile agent with drawing directions
|
|
78
|
+
|
|
79
|
+
### `src/tile-agent.ts`
|
|
80
|
+
|
|
81
|
+
The tile agent entity. Each instance gets drawing tools scoped to its tile:
|
|
82
|
+
|
|
83
|
+
- `read_viewport` --- see current pixel state (own tile + neighbors)
|
|
84
|
+
- `fill_rect`, `draw_line`, `draw_circle`, `fill_gradient`, `set_pixels`
|
|
85
|
+
|
|
86
|
+
All coordinates are tile-relative (0--99) and automatically clipped to tile bounds.
|
|
87
|
+
|
|
88
|
+
## Running it
|
|
89
|
+
|
|
90
|
+
```bash
|
|
91
|
+
cd examples/mega-draw
|
|
92
|
+
pnpm install
|
|
93
|
+
cp ../../.env.template .env # Set ANTHROPIC_API_KEY
|
|
94
|
+
pnpm dev
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
Requires a running Electric Agents runtime server at `http://localhost:4437`.
|
|
98
|
+
|
|
99
|
+
Then in another terminal:
|
|
100
|
+
|
|
101
|
+
```bash
|
|
102
|
+
npx electric-ax agents spawn /coordinator/my-drawing
|
|
103
|
+
npx electric-ax agents send /coordinator/my-drawing 'Draw a sunset over mountains'
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
View the canvas live at `http://localhost:3000/my-drawing` --- it auto-refreshes as tiles draw.
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Pattern references
|
|
3
|
+
titleTemplate: '... - Electric Agents'
|
|
4
|
+
description: >-
|
|
5
|
+
Electric Agents pattern references for standalone, coordination, blackboard, and reactive designs.
|
|
6
|
+
outline: [2, 3]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Pattern references
|
|
10
|
+
|
|
11
|
+
Electric Agents pattern references live in the monorepo under `packages/agents-runtime/skills/designing-entities/references/patterns/`.
|
|
12
|
+
|
|
13
|
+
## What it includes
|
|
14
|
+
|
|
15
|
+
The patterns are organized into four categories.
|
|
16
|
+
|
|
17
|
+
### Standalone
|
|
18
|
+
|
|
19
|
+
- `single-agent` --- one entity handles the full task itself
|
|
20
|
+
|
|
21
|
+
### Coordination
|
|
22
|
+
|
|
23
|
+
- `manager-worker` --- multi-perspective analysis (optimist/pessimist/pragmatist)
|
|
24
|
+
- `dispatcher` --- routes tasks to the appropriate agent type
|
|
25
|
+
- `pipeline` --- sequential worker stages
|
|
26
|
+
- `map-reduce` --- parallel chunk processing
|
|
27
|
+
|
|
28
|
+
### Blackboard (shared state)
|
|
29
|
+
|
|
30
|
+
- `blackboard` --- multiple workers coordinate through shared state
|
|
31
|
+
|
|
32
|
+
### Reactive
|
|
33
|
+
|
|
34
|
+
- `reactive-observers` --- observes entity streams and reacts to changes
|
|
35
|
+
|
|
36
|
+
## Source references
|
|
37
|
+
|
|
38
|
+
- [`single-agent`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/single-agent.md)
|
|
39
|
+
- [`manager-worker`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/manager-worker.md)
|
|
40
|
+
- [`dispatcher`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/dispatcher.md)
|
|
41
|
+
- [`pipeline`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/pipeline.md)
|
|
42
|
+
- [`map-reduce`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/map-reduce.md)
|
|
43
|
+
- [`blackboard`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/blackboard.md)
|
|
44
|
+
- [`reactive-observers`](https://github.com/electric-sql/electric/blob/main/packages/agents-runtime/skills/designing-entities/references/patterns/reactive-observers.md)
|
|
45
|
+
|
|
46
|
+
See [Agents & Patterns](../usage/spawning-and-coordinating.md) for detailed documentation of each pattern.
|
package/docs/index.md
ADDED
|
@@ -0,0 +1,208 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Electric Agents
|
|
3
|
+
titleTemplate: '... - Electric Agents'
|
|
4
|
+
description: >-
|
|
5
|
+
The durable runtime for long-lived agents — entities, handlers, wakes, agent loops, and coordination, built on Electric Streams, TanStack DB, and pi.
|
|
6
|
+
outline: [2, 3]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
<script setup>
|
|
10
|
+
import EntityOverviewDiagram from '../../src/components/agents-home/EntityOverviewDiagram.vue'
|
|
11
|
+
</script>
|
|
12
|
+
|
|
13
|
+
# Electric Agents
|
|
14
|
+
|
|
15
|
+
Electric Agents is **the durable runtime for long-lived agents**. It's a runtime and communication fabric for spawning and scaling collaborative agents on serverless compute, using your existing web and AI frameworks.
|
|
16
|
+
|
|
17
|
+
Each agent is an **entity** — an addressable, schema-typed unit of state at `/{type}/{id}`. An entity's session and state live on a durable [Electric Stream](/streams/) of events.
|
|
18
|
+
|
|
19
|
+
Entities **wake** when something happens — a message arrives, a child finishes, state changes, or a scheduled time elapses. When woken, the entity's handler runs. It can configure an LLM agent loop, update state, spawn children, and coordinate with other entities.
|
|
20
|
+
|
|
21
|
+
Every step — runs, tool calls, text deltas, state changes — is appended to the entity's stream as it happens. Agents scale to zero and survive restarts. Any session can be replayed or [forked](/blog/2026/04/15/fork-branching-for-durable-streams) from any point, and observed in real time by any number of users and entities, both inside the system and from external apps.
|
|
22
|
+
|
|
23
|
+
<EntityOverviewDiagram />
|
|
24
|
+
|
|
25
|
+
Start with the [Quickstart](/docs/agents/quickstart) to run the built-in `horton` agent and connect your own app in a few minutes. The [Usage overview](/docs/agents/usage/overview) summarises the full developer surface in a single page.
|
|
26
|
+
|
|
27
|
+
## How it works
|
|
28
|
+
|
|
29
|
+
The runtime SDK is a layer over three foundations:
|
|
30
|
+
|
|
31
|
+
- **[Electric Streams](/streams/)** — durable, ordered event log per entity.
|
|
32
|
+
- **[TanStack DB](https://tanstack.com/db)** — typed local reads and writes via collections.
|
|
33
|
+
- **Mario Zechner's [pi](https://github.com/badlogic/pi-mono) toolkit** — `pi-ai` (unified multi-provider LLM API) and `pi-agent-core` (agent runtime) for the LLM agent loop.
|
|
34
|
+
|
|
35
|
+
**One stream per entity.** The runtime projects that stream into a typed local DB of collections — an `EntityStreamDB`. Inside a handler, that DB is `ctx.db`: writes go through `ctx.db.actions` (which append events to the stream), reads come from `ctx.db.collections`. The runtime ships [built-in collections](#built-in-collections) for runs, tool calls, text deltas, errors, inbox, and more, and you add your own typed [state](#state) collections per entity type.
|
|
36
|
+
|
|
37
|
+
**Inside a handler.** When a handler calls `ctx.useAgent()`, the runtime configures the agent on its behalf and routes every step — model call, text delta, tool invocation, error — through the same projection, so the agent loop becomes durable events on the entity's stream.
|
|
38
|
+
|
|
39
|
+
**Outside the handler.** Any app or other entity can call [`createAgentsClient().observe(entity('/type/id'))`](/docs/agents/usage/clients-and-react) to load an entity's stream into a local DB and react to changes in real time, with the same schemas and types as the handler.
|
|
40
|
+
|
|
41
|
+
## Entities
|
|
42
|
+
|
|
43
|
+
Use entities to model anything long-lived and addressable — an agent session, a chat thread, a research job, a coordinator, a worker. You register a **type** with [`registry.define()`](/docs/agents/reference/entity-registry) and spawn **instances** at `/{type}/{id}`. Each instance has its own state, handler, and event stream. See [Defining entities](/docs/agents/usage/defining-entities).
|
|
44
|
+
|
|
45
|
+
```ts
|
|
46
|
+
const registry = createEntityRegistry()
|
|
47
|
+
|
|
48
|
+
registry.define('assistant', {
|
|
49
|
+
description: 'A general-purpose AI assistant',
|
|
50
|
+
async handler(ctx) {
|
|
51
|
+
// ...
|
|
52
|
+
},
|
|
53
|
+
})
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Handlers
|
|
57
|
+
|
|
58
|
+
The function that runs when an entity wakes. Receives a [`HandlerContext`](/docs/agents/reference/handler-context) (`ctx`) and a [`WakeEvent`](/docs/agents/reference/wake-event) (`wake`). The handler decides how to respond: configure an agent, update state, spawn children, or any combination. See [Writing handlers](/docs/agents/usage/writing-handlers).
|
|
59
|
+
|
|
60
|
+
```ts
|
|
61
|
+
registry.define('support', {
|
|
62
|
+
async handler(ctx, wake) {
|
|
63
|
+
if (wake.type === 'message_received') {
|
|
64
|
+
ctx.useAgent({
|
|
65
|
+
systemPrompt: 'You are a support agent.',
|
|
66
|
+
model: 'claude-sonnet-4-5-20250929',
|
|
67
|
+
tools: [...ctx.electricTools, searchKbTool],
|
|
68
|
+
})
|
|
69
|
+
await ctx.agent.run()
|
|
70
|
+
}
|
|
71
|
+
},
|
|
72
|
+
})
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Wakes
|
|
76
|
+
|
|
77
|
+
Events that trigger a handler invocation. Wake sources include incoming messages, child completion, state changes, and timers (scheduled sends, cron, timeouts). The [`WakeEvent`](/docs/agents/reference/wake-event) tells the handler why it was woken. See [Waking entities](/docs/agents/usage/waking-entities).
|
|
78
|
+
|
|
79
|
+
```ts
|
|
80
|
+
async handler(ctx, wake) {
|
|
81
|
+
// wake.type — "message_received", "wake", etc.
|
|
82
|
+
// wake.source — who triggered the wake
|
|
83
|
+
// wake.payload — message content or wake data
|
|
84
|
+
|
|
85
|
+
if (wake.type === "message_received") {
|
|
86
|
+
const userMessage = wake.payload
|
|
87
|
+
// handle incoming message
|
|
88
|
+
}
|
|
89
|
+
}
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## State
|
|
93
|
+
|
|
94
|
+
Custom persistent collections on the entity. Defined as part of the [entity definition](/docs/agents/reference/entity-definition) and accessed through `ctx.db` alongside the [built-in collections](#built-in-collections). State is local to the entity, typed, and survives restarts. Use it for things that belong to the entity but aren't part of the agent's event stream — an order's items, a research job's findings, a chat session's TODOs. See [Managing state](/docs/agents/usage/managing-state).
|
|
95
|
+
|
|
96
|
+
```ts
|
|
97
|
+
registry.define('tracker', {
|
|
98
|
+
state: {
|
|
99
|
+
items: {
|
|
100
|
+
schema: z.object({
|
|
101
|
+
key: z.string(),
|
|
102
|
+
name: z.string(),
|
|
103
|
+
done: z.boolean(),
|
|
104
|
+
}),
|
|
105
|
+
primaryKey: 'key',
|
|
106
|
+
},
|
|
107
|
+
},
|
|
108
|
+
async handler(ctx) {
|
|
109
|
+
// read
|
|
110
|
+
const item = ctx.db.collections.items.get('item-1')
|
|
111
|
+
|
|
112
|
+
// write
|
|
113
|
+
ctx.db.actions.items_insert({
|
|
114
|
+
row: { key: 'item-2', name: 'New', done: false },
|
|
115
|
+
})
|
|
116
|
+
},
|
|
117
|
+
})
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
## Agent loop
|
|
121
|
+
|
|
122
|
+
The core pattern is [`ctx.useAgent()`](/docs/agents/reference/agent-config) followed by `ctx.agent.run()`. This runs the LLM in a loop — it generates text, calls tools, and continues until it has nothing left to do. All activity is automatically persisted to the entity's stream. See [Configuring the agent](/docs/agents/usage/configuring-the-agent).
|
|
123
|
+
|
|
124
|
+
```ts
|
|
125
|
+
ctx.useAgent({
|
|
126
|
+
systemPrompt: 'You are a helpful assistant.',
|
|
127
|
+
model: 'claude-sonnet-4-5-20250929',
|
|
128
|
+
tools: [...ctx.electricTools, myCustomTool],
|
|
129
|
+
})
|
|
130
|
+
|
|
131
|
+
await ctx.agent.run()
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
## Tools
|
|
135
|
+
|
|
136
|
+
Functions the LLM can call during the agent loop. Each tool has a name, description, parameters (defined with [TypeBox](https://github.com/sinclairzx81/typebox) or any [Standard Schema](https://standardschema.dev) validator), and an execute function. Tools run in the handler's context and have access to the entity's state and coordination primitives. See [Defining tools](/docs/agents/usage/defining-tools) and the [`AgentTool` reference](/docs/agents/reference/agent-tool).
|
|
137
|
+
|
|
138
|
+
```ts
|
|
139
|
+
const searchKbTool: AgentTool = {
|
|
140
|
+
name: 'search_kb',
|
|
141
|
+
label: 'Search knowledge base',
|
|
142
|
+
description: 'Search the knowledge base',
|
|
143
|
+
parameters: Type.Object({
|
|
144
|
+
query: Type.String({ description: 'Search query' }),
|
|
145
|
+
}),
|
|
146
|
+
execute: async (_toolCallId, params) => {
|
|
147
|
+
const { query } = params as { query: string }
|
|
148
|
+
const results = await searchKnowledgeBase(query)
|
|
149
|
+
return {
|
|
150
|
+
content: [{ type: 'text', text: JSON.stringify(results) }],
|
|
151
|
+
details: {},
|
|
152
|
+
}
|
|
153
|
+
},
|
|
154
|
+
}
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
## Coordination
|
|
158
|
+
|
|
159
|
+
Entities interact through structured primitives. An entity can `spawn` children, `observe` other entities, `send` messages, and [share state](/docs/agents/usage/shared-state). These operations are all durable — they survive restarts and are tracked in the event stream. See [Spawning and coordinating](/docs/agents/usage/spawning-and-coordinating).
|
|
160
|
+
|
|
161
|
+
```ts
|
|
162
|
+
async handler(ctx) {
|
|
163
|
+
// spawn a child entity — wake parent when it finishes
|
|
164
|
+
const child = await ctx.spawn(
|
|
165
|
+
"worker",
|
|
166
|
+
"task-1",
|
|
167
|
+
{
|
|
168
|
+
systemPrompt: "Analyse the report",
|
|
169
|
+
tools: ["read"],
|
|
170
|
+
},
|
|
171
|
+
{ initialMessage: "Find the top three issues", wake: "runFinished" }
|
|
172
|
+
)
|
|
173
|
+
|
|
174
|
+
// send a message to another entity
|
|
175
|
+
ctx.send("/notify/alerts", { level: "info", text: "Task started" })
|
|
176
|
+
|
|
177
|
+
// observe another entity's state changes
|
|
178
|
+
await ctx.observe(entity("/order/99"), {
|
|
179
|
+
wake: { on: "change", collections: ["status"] },
|
|
180
|
+
})
|
|
181
|
+
}
|
|
182
|
+
```
|
|
183
|
+
|
|
184
|
+
## Built-in collections
|
|
185
|
+
|
|
186
|
+
Every entity automatically has collections for runs, steps, texts, tool calls, errors, inbox, and more. These are populated by the runtime as the agent operates and give you live observability into every step of the agent loop — useful for chat UIs, debugging tools, dashboards, and analytics. Query them from the handler or observe them externally. See the [Built-in collections reference](/docs/agents/reference/built-in-collections).
|
|
187
|
+
|
|
188
|
+
```ts
|
|
189
|
+
// from inside a handler
|
|
190
|
+
const allRuns = ctx.db.collections.runs.toArray
|
|
191
|
+
const lastError = ctx.db.collections.errors.toArray.at(-1)
|
|
192
|
+
|
|
193
|
+
// from outside — load an entity's stream into a local DB
|
|
194
|
+
const client = createAgentsClient({ baseUrl: 'http://localhost:4437' })
|
|
195
|
+
const db = await client.observe(entity('/support/ticket-42'))
|
|
196
|
+
console.log(db.collections.texts.toArray)
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
## Next steps
|
|
200
|
+
|
|
201
|
+
- [Quickstart](/docs/agents/quickstart) — run the built-in `horton` agent and connect your own app.
|
|
202
|
+
- [Usage overview](/docs/agents/usage/overview) — the full developer surface on one page.
|
|
203
|
+
- [Defining entities](/docs/agents/usage/defining-entities) — entity types, schemas, and configuration.
|
|
204
|
+
- [Writing handlers](/docs/agents/usage/writing-handlers) — handler lifecycle and the `ctx` API.
|
|
205
|
+
- [Configuring the agent](/docs/agents/usage/configuring-the-agent) — `useAgent`, models, tools, and streaming.
|
|
206
|
+
- [Spawning & coordinating](/docs/agents/usage/spawning-and-coordinating) — multi-entity topologies and shared state.
|
|
207
|
+
- [Built-in agents](/docs/agents/entities/agents/horton) — Horton and Worker, the agents that ship with the runtime.
|
|
208
|
+
- [Examples](/docs/agents/examples/playground) — pattern walkthroughs and demo apps.
|