agentnet 0.0.1 → 0.0.3
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/README.md +317 -364
- package/_OLD_README.md +554 -0
- package/assets/network01.png +0 -0
- package/examples/customer-support/README.md +66 -0
- package/examples/customer-support/agents.yaml +457 -0
- package/examples/customer-support/index.js +408 -0
- package/examples/event-planner/README.md +69 -0
- package/examples/event-planner/agents.yaml +318 -0
- package/examples/event-planner/index.js +547 -0
- package/{src/examples → examples/simple}/simple.js +2 -2
- package/{src/examples → examples/smartness}/agents-smartness.yaml +8 -17
- package/{src/examples/def3.js → examples/smartness/index.js} +9 -9
- package/jest.config.js +1 -0
- package/package.json +6 -3
- package/src/agent/agent-loader.js +75 -12
- package/src/agent/agent.js +13 -3
- package/src/agent/runtime.js +9 -6
- package/src/llm/base.js +131 -0
- package/src/llm/gemini.js +137 -117
- package/src/llm/gpt.js +131 -104
- package/src/store/store.js +82 -48
- package/src/tests/agent.test.js +350 -0
- package/src/tools/migrate-version.js +250 -0
- package/src/transport/README.md +123 -0
- package/src/transport/base.js +237 -0
- package/src/transport/index.js +89 -0
- package/src/transport/kafka.js +474 -0
- package/src/transport/nats.js +521 -0
- package/src/transport/rabbitmq.js +722 -0
- package/src/transport/redis.js +532 -0
- package/src/utils/version.js +212 -0
- package/src/agent/runtimes/nats.js +0 -379
- package/src/examples/agents.yaml +0 -394
- package/src/examples/def.js +0 -74
- package/src/examples/def2.js +0 -65
package/_OLD_README.md
ADDED
|
@@ -0,0 +1,554 @@
|
|
|
1
|
+
# Agentnet
|
|
2
|
+
|
|
3
|
+
Agentnet is a flexible, extensible library for building and orchestrating LLM-powered agents that can communicate, collaborate, and leverage tools to solve complex tasks. It is specifically designed to develop autonomous networks of agents that can work together to accomplish sophisticated objectives with minimal human intervention.
|
|
4
|
+
|
|
5
|
+
## Table of Contents
|
|
6
|
+
|
|
7
|
+
- [Declarative Agent Definitions](#declarative-agent-definitions)
|
|
8
|
+
- [Static Definitions (YAML)](#static-definitions-yaml)
|
|
9
|
+
- [Dynamic Implementation (JavaScript)](#dynamic-implementation-javascript)
|
|
10
|
+
- [Multi-Agent Systems with YAML](#multi-agent-systems-with-yaml)
|
|
11
|
+
- [Key Features](#key-features)
|
|
12
|
+
- [Quick Start](#quick-start)
|
|
13
|
+
- [Core Concepts](#core-concepts)
|
|
14
|
+
- [Agents](#agents)
|
|
15
|
+
- [Agent Configuration](#agent-configuration)
|
|
16
|
+
- [Tool Binding](#tool-binding)
|
|
17
|
+
- [Transport Mechanisms](#transport-mechanisms)
|
|
18
|
+
- [Agent Auto-Discovery](#agent-auto-discovery)
|
|
19
|
+
- [Agent Handoffs](#agent-handoffs)
|
|
20
|
+
- [Advanced Usage](#advanced-usage)
|
|
21
|
+
- [Events and Hooks](#events-and-hooks)
|
|
22
|
+
- [Multi-Agent Systems](#multi-agent-systems)
|
|
23
|
+
- [Session State Management](#session-state-management)
|
|
24
|
+
- [Installation](#installation)
|
|
25
|
+
- [License](#license)
|
|
26
|
+
|
|
27
|
+
## Declarative Agent Definitions
|
|
28
|
+
|
|
29
|
+
A key feature of Agentnet is the ability to define agents declaratively using YAML files, separating the static definition of agents from their dynamic runtime behavior:
|
|
30
|
+
|
|
31
|
+
### Static Definitions (YAML)
|
|
32
|
+
|
|
33
|
+
Agents can be defined in YAML files that specify:
|
|
34
|
+
- Metadata (name, description)
|
|
35
|
+
- LLM configuration (provider, model, system instructions)
|
|
36
|
+
- Transport mechanisms (NATS, etc.)
|
|
37
|
+
- Tool schemas (name, description, parameters)
|
|
38
|
+
- Discovery schemas for inter-agent communication
|
|
39
|
+
|
|
40
|
+
Example YAML definition:
|
|
41
|
+
|
|
42
|
+
```yaml
|
|
43
|
+
---
|
|
44
|
+
apiVersion: agentnet.io/v1alpha1
|
|
45
|
+
kind: AgentDefinition
|
|
46
|
+
metadata:
|
|
47
|
+
name: bookingAgent
|
|
48
|
+
namespace: smartchat
|
|
49
|
+
spec:
|
|
50
|
+
io:
|
|
51
|
+
- type: NatsIO
|
|
52
|
+
bindings:
|
|
53
|
+
discoveryTopic: smartness.discovery
|
|
54
|
+
acceptedNetworks:
|
|
55
|
+
- "smartchat.*"
|
|
56
|
+
|
|
57
|
+
llm:
|
|
58
|
+
provider: Gemini
|
|
59
|
+
model: gemini-2.0-flash
|
|
60
|
+
systemInstruction: |
|
|
61
|
+
You are a highly advanced booking agent.
|
|
62
|
+
Prioritize clarity and helpfulness.
|
|
63
|
+
Use tools effectively to gather information.
|
|
64
|
+
config:
|
|
65
|
+
temperature: 0.5
|
|
66
|
+
toolConfig:
|
|
67
|
+
functionCallingConfig:
|
|
68
|
+
mode: 'auto'
|
|
69
|
+
|
|
70
|
+
tools:
|
|
71
|
+
- name: bookRoomTool
|
|
72
|
+
description: Book a room to a specific hotel and room.
|
|
73
|
+
parameters:
|
|
74
|
+
type: object
|
|
75
|
+
properties:
|
|
76
|
+
hotelName:
|
|
77
|
+
type: string
|
|
78
|
+
description: The name of the hotel.
|
|
79
|
+
roomName:
|
|
80
|
+
type: string
|
|
81
|
+
description: The name of the room.
|
|
82
|
+
checkinDate:
|
|
83
|
+
type: string
|
|
84
|
+
description: The check-in date.
|
|
85
|
+
checkoutDate:
|
|
86
|
+
type: string
|
|
87
|
+
description: The check-out date.
|
|
88
|
+
required:
|
|
89
|
+
- hotelName
|
|
90
|
+
- roomName
|
|
91
|
+
|
|
92
|
+
discoverySchemas:
|
|
93
|
+
- name: booking_agent_query
|
|
94
|
+
description: Perform a booking to a specific hotel and room.
|
|
95
|
+
parameters:
|
|
96
|
+
type: object
|
|
97
|
+
properties:
|
|
98
|
+
hotelName:
|
|
99
|
+
type: string
|
|
100
|
+
description: The name of the hotel.
|
|
101
|
+
roomName:
|
|
102
|
+
type: string
|
|
103
|
+
description: The name of the room.
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
You can define multiple agents in a single YAML file using YAML document separators (`---`). Each agent can have its own specialized role in a multi-agent system.
|
|
107
|
+
|
|
108
|
+
### Dynamic Implementation (JavaScript)
|
|
109
|
+
|
|
110
|
+
The YAML definitions are loaded at runtime, and tool implementations are dynamically bound using JavaScript:
|
|
111
|
+
|
|
112
|
+
```javascript
|
|
113
|
+
// Load all agents from a YAML file
|
|
114
|
+
const agents = await AgentLoaderFile('./agents.yaml', {
|
|
115
|
+
bindings: { [Bindings.NatsIO]: natsInstance }
|
|
116
|
+
});
|
|
117
|
+
|
|
118
|
+
// Access a specific agent
|
|
119
|
+
const bookingAgent = agents.bookingAgent;
|
|
120
|
+
const pricingAgent = agents.pricingAgent;
|
|
121
|
+
|
|
122
|
+
// Bind tool implementations
|
|
123
|
+
bookingAgent.tools.bookRoomTool.bind(async (state, input) => {
|
|
124
|
+
// Actual implementation to book a room
|
|
125
|
+
return {
|
|
126
|
+
confirmation: `Room ${input.roomName} booked at ${input.hotelName}
|
|
127
|
+
from ${input.checkinDate} to ${input.checkoutDate}`
|
|
128
|
+
};
|
|
129
|
+
});
|
|
130
|
+
|
|
131
|
+
// Customize prompt/response handling
|
|
132
|
+
bookingAgent.prompt((state, input) => {
|
|
133
|
+
// Pre-process input before sending to LLM
|
|
134
|
+
console.log(`Received booking request: ${input}`);
|
|
135
|
+
return input;
|
|
136
|
+
});
|
|
137
|
+
|
|
138
|
+
bookingAgent.response((state, conversation, result) => {
|
|
139
|
+
// Post-process response from LLM
|
|
140
|
+
return `Booking confirmation: ${result}`;
|
|
141
|
+
});
|
|
142
|
+
|
|
143
|
+
// Compile all agents to make them ready for use
|
|
144
|
+
await bookingAgent.compile();
|
|
145
|
+
await pricingAgent.compile();
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
This separation of concerns allows for:
|
|
149
|
+
- Version-controlled agent definitions
|
|
150
|
+
- Reusable tool schemas
|
|
151
|
+
- Dynamic runtime implementation
|
|
152
|
+
- Easy testing and deployment
|
|
153
|
+
- Clear separation between definition and implementation
|
|
154
|
+
|
|
155
|
+
### Multi-Agent Systems with YAML
|
|
156
|
+
|
|
157
|
+
The framework excels at creating autonomous multi-agent systems where specialized agents collaborate with minimal supervision. Each agent in the network can operate independently while maintaining awareness of other agents' capabilities. This creates a resilient, self-organizing system that can tackle complex tasks through agent collaboration. An example setup might include:
|
|
158
|
+
|
|
159
|
+
```javascript
|
|
160
|
+
// Load a set of specialized agents from YAML
|
|
161
|
+
const agents = await AgentLoaderFile('./agents-smartness.yaml', {
|
|
162
|
+
bindings: { [Bindings.NatsIO]: natsIO }
|
|
163
|
+
});
|
|
164
|
+
|
|
165
|
+
// Configure each agent with specific tool implementations
|
|
166
|
+
agents.accomodation.tools.getRoomsListTool.bind(async (state, input) => {
|
|
167
|
+
// Implementation for listing available rooms
|
|
168
|
+
return { rooms: ["Double room with sea view", "Single room with pool view"] };
|
|
169
|
+
});
|
|
170
|
+
|
|
171
|
+
agents.pricing.tools.getPricingTool.bind(async (state, input) => {
|
|
172
|
+
// Implementation for getting room prices
|
|
173
|
+
return { price: "200€ per night" };
|
|
174
|
+
});
|
|
175
|
+
|
|
176
|
+
agents.booking.tools.bookRoomTool.bind(async (state, input) => {
|
|
177
|
+
// Implementation for booking rooms
|
|
178
|
+
return { confirmation: "Booking confirmed" };
|
|
179
|
+
});
|
|
180
|
+
|
|
181
|
+
// Compile all agents
|
|
182
|
+
await Promise.all(Object.values(agents).map(agent => agent.compile()));
|
|
183
|
+
|
|
184
|
+
// Wait for agent discovery to complete
|
|
185
|
+
await new Promise(resolve => setTimeout(resolve, 2000));
|
|
186
|
+
|
|
187
|
+
// Query the main orchestrator agent
|
|
188
|
+
const client = AgentClient();
|
|
189
|
+
const response = await client.queryIo(
|
|
190
|
+
natsIO,
|
|
191
|
+
'entrypoint',
|
|
192
|
+
"What rooms do you have available for next weekend and how much do they cost?"
|
|
193
|
+
);
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
With this setup, the smartness agent will automatically discover and delegate to specialized agents for accommodation, pricing, and booking, creating an autonomous network that collectively solves the user's query.
|
|
197
|
+
|
|
198
|
+
## Key Features
|
|
199
|
+
|
|
200
|
+
- **Autonomous Agent Networks**: Create self-organizing networks of agents that can discover, communicate, and collaborate with minimal human intervention
|
|
201
|
+
- **Modular Agent Architecture**: Create specialized agents with distinct capabilities and compose them to solve complex problems
|
|
202
|
+
- **Transport Agnostic**: Work with agents directly or through transport mechanisms like NATS
|
|
203
|
+
- **Auto-Discovery**: Agents can discover each other's capabilities dynamically at runtime
|
|
204
|
+
- **Tool Binding**: Easily bind JavaScript functions to agent tools
|
|
205
|
+
- **Agent Handoffs**: Seamlessly delegate tasks between agents
|
|
206
|
+
- **LLM Provider Agnostic**: Support for multiple LLM providers (Gemini and extensible to others)
|
|
207
|
+
- **Persistent Sessions**: Maintain conversation context and state across interactions
|
|
208
|
+
|
|
209
|
+
## Quick Start
|
|
210
|
+
|
|
211
|
+
```javascript
|
|
212
|
+
import { Agent, Gemini, NatsIO } from "agentnet";
|
|
213
|
+
|
|
214
|
+
// Create a simple agent
|
|
215
|
+
const myAgent = Agent()
|
|
216
|
+
.setMetadata({
|
|
217
|
+
name: "myAgent",
|
|
218
|
+
description: "A helpful assistant"
|
|
219
|
+
})
|
|
220
|
+
.withLLM(Gemini, {
|
|
221
|
+
model: "gemini-pro",
|
|
222
|
+
systemInstruction: "You are a helpful assistant"
|
|
223
|
+
})
|
|
224
|
+
.addToolSchema({
|
|
225
|
+
name: "weatherTool",
|
|
226
|
+
description: "Get weather information",
|
|
227
|
+
parameters: {
|
|
228
|
+
location: "string"
|
|
229
|
+
}
|
|
230
|
+
});
|
|
231
|
+
|
|
232
|
+
// Bind tool implementation
|
|
233
|
+
const compiledAgent = await myAgent.compile();
|
|
234
|
+
compiledAgent.tools.weatherTool.bind(async (state, input) => {
|
|
235
|
+
return { weather: "Sunny", temperature: 25 };
|
|
236
|
+
});
|
|
237
|
+
|
|
238
|
+
// Query the agent
|
|
239
|
+
const response = await compiledAgent.query("What's the weather like in Paris?");
|
|
240
|
+
console.log(response);
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
## Core Concepts
|
|
244
|
+
|
|
245
|
+
### Agents
|
|
246
|
+
|
|
247
|
+
Agents are the core building blocks of the framework. Each agent:
|
|
248
|
+
|
|
249
|
+
- Has its own identity (name, description)
|
|
250
|
+
- Can be configured with an LLM provider
|
|
251
|
+
- Can define and implement tools
|
|
252
|
+
- Can discover and communicate with other agents
|
|
253
|
+
|
|
254
|
+
### Agent Configuration
|
|
255
|
+
|
|
256
|
+
Agents can be configured programmatically or via YAML definitions:
|
|
257
|
+
|
|
258
|
+
```javascript
|
|
259
|
+
// Programmatic configuration
|
|
260
|
+
const myAgent = Agent()
|
|
261
|
+
.setMetadata({ name: "myAgent" })
|
|
262
|
+
.withLLM(Gemini, { model: "gemini-pro" })
|
|
263
|
+
.addToolSchema(myToolSchema);
|
|
264
|
+
|
|
265
|
+
// YAML-based configuration
|
|
266
|
+
const agents = await AgentLoaderFile('./agents.yaml', {
|
|
267
|
+
bindings: { [Bindings.NatsIO]: natsInstance }
|
|
268
|
+
});
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
### Tool Binding
|
|
272
|
+
|
|
273
|
+
Tools allow agents to perform actions in the real world. Each tool:
|
|
274
|
+
|
|
275
|
+
- Has a schema that defines its interface (name, description, parameters)
|
|
276
|
+
- Has an implementation bound to it at runtime
|
|
277
|
+
|
|
278
|
+
```javascript
|
|
279
|
+
// Define tool schema
|
|
280
|
+
agent.addToolSchema({
|
|
281
|
+
name: "fetchData",
|
|
282
|
+
description: "Fetch data from an API",
|
|
283
|
+
parameters: {
|
|
284
|
+
url: "string",
|
|
285
|
+
method: "string"
|
|
286
|
+
}
|
|
287
|
+
});
|
|
288
|
+
|
|
289
|
+
// Bind implementation
|
|
290
|
+
agent.tools.fetchData.bind(async (state, input) => {
|
|
291
|
+
// Actual implementation
|
|
292
|
+
const response = await fetch(input.url, { method: input.method });
|
|
293
|
+
return await response.json();
|
|
294
|
+
});
|
|
295
|
+
```
|
|
296
|
+
|
|
297
|
+
### Transport Mechanisms
|
|
298
|
+
|
|
299
|
+
The framework supports different transport mechanisms for agent communication:
|
|
300
|
+
|
|
301
|
+
#### Direct Communication
|
|
302
|
+
|
|
303
|
+
Agents can be queried directly in the same process:
|
|
304
|
+
|
|
305
|
+
```javascript
|
|
306
|
+
const compiledAgent = await myAgent.compile();
|
|
307
|
+
const response = await compiledAgent.query("Hello, agent!");
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
#### NATS-based Communication
|
|
311
|
+
|
|
312
|
+
Agents can communicate through NATS for distributed deployments:
|
|
313
|
+
|
|
314
|
+
```javascript
|
|
315
|
+
// Initialize NATS transport
|
|
316
|
+
const natsIO = NatsIO({ servers: ['nats://localhost:4222'] });
|
|
317
|
+
|
|
318
|
+
// Configure agent with NATS transport
|
|
319
|
+
const myAgent = Agent()
|
|
320
|
+
.setMetadata({ name: "distributedAgent" })
|
|
321
|
+
.addIO(natsIO, {
|
|
322
|
+
bindings: {
|
|
323
|
+
discoveryTopic: "smartness.discovery",
|
|
324
|
+
acceptedNetworks: ["smartchat.*"]
|
|
325
|
+
}
|
|
326
|
+
})
|
|
327
|
+
.withLLM(Gemini, { model: "gemini-pro" });
|
|
328
|
+
|
|
329
|
+
// Query an agent through NATS
|
|
330
|
+
const client = AgentClient();
|
|
331
|
+
const response = await client.queryIo(natsIO, 'distributedAgent', "Hello!");
|
|
332
|
+
```
|
|
333
|
+
|
|
334
|
+
### Agent Auto-Discovery
|
|
335
|
+
|
|
336
|
+
Agents can discover each other's capabilities at runtime through a discovery protocol:
|
|
337
|
+
|
|
338
|
+
1. Agents publish their capabilities (available tools and schemas) to a discovery topic
|
|
339
|
+
2. Other agents subscribe to the discovery topic and build a catalog of available agents
|
|
340
|
+
3. Agents can then delegate tasks to the most appropriate agent
|
|
341
|
+
|
|
342
|
+
```javascript
|
|
343
|
+
// Auto-discovery happens automatically when agents share the same transport
|
|
344
|
+
// Just wait for discovery to complete
|
|
345
|
+
await new Promise(resolve => setTimeout(resolve, 2000));
|
|
346
|
+
|
|
347
|
+
// Now agents can communicate with each other
|
|
348
|
+
```
|
|
349
|
+
|
|
350
|
+
### Network Filtering
|
|
351
|
+
|
|
352
|
+
The framework provides a powerful network filtering mechanism that allows agents to control which other agents they communicate with. This is configured through the `acceptedNetworks` property:
|
|
353
|
+
|
|
354
|
+
```javascript
|
|
355
|
+
// Configure agent with network filtering
|
|
356
|
+
const myAgent = Agent()
|
|
357
|
+
.setMetadata({ name: "filteredAgent" })
|
|
358
|
+
.addIO(natsIO, {
|
|
359
|
+
network: "smartchat",
|
|
360
|
+
bindings: {
|
|
361
|
+
discoveryTopic: "smartness.discovery",
|
|
362
|
+
acceptedNetworks: ["smartchat.*", "finance.pricing"]
|
|
363
|
+
}
|
|
364
|
+
})
|
|
365
|
+
.withLLM(Gemini, { model: "gemini-pro" });
|
|
366
|
+
```
|
|
367
|
+
|
|
368
|
+
#### Wildcard Patterns
|
|
369
|
+
|
|
370
|
+
Network filtering supports various wildcard patterns:
|
|
371
|
+
|
|
372
|
+
1. **Full wildcard** (`*.*`): Accept all networks regardless of namespace or name
|
|
373
|
+
2. **Namespace wildcard** (`*.serviceName`): Accept any network with the specified service name, regardless of namespace
|
|
374
|
+
3. **Service wildcard** (`namespace.*`): Accept any service within the specified namespace
|
|
375
|
+
|
|
376
|
+
For example:
|
|
377
|
+
|
|
378
|
+
```yaml
|
|
379
|
+
io:
|
|
380
|
+
- type: NatsIO
|
|
381
|
+
network: smartchat
|
|
382
|
+
bindings:
|
|
383
|
+
discoveryTopic: smartness.discovery
|
|
384
|
+
acceptedNetworks:
|
|
385
|
+
- "smartchat.*" # Accept all services in smartchat namespace
|
|
386
|
+
- "finance.pricing" # Accept only the pricing service in finance namespace
|
|
387
|
+
- "*.analytics" # Accept analytics services from any namespace
|
|
388
|
+
```
|
|
389
|
+
|
|
390
|
+
This filtering system allows for fine-grained control over agent communication, enhancing security and improving the efficiency of the agent network. Agents will only process discovery messages from networks that match their acceptance patterns.
|
|
391
|
+
|
|
392
|
+
### Agent Handoffs
|
|
393
|
+
|
|
394
|
+
Agents can delegate tasks to other agents with the right capabilities:
|
|
395
|
+
|
|
396
|
+
1. An agent receives a task it can't handle directly
|
|
397
|
+
2. It identifies another agent with the required capability
|
|
398
|
+
3. It hands off the task to that agent
|
|
399
|
+
4. The specialized agent processes the task and returns the result
|
|
400
|
+
|
|
401
|
+
This happens transparently from the user's perspective, creating a seamless experience.
|
|
402
|
+
|
|
403
|
+
## Advanced Usage
|
|
404
|
+
|
|
405
|
+
### Events and Hooks
|
|
406
|
+
|
|
407
|
+
Customize agent behavior with event hooks:
|
|
408
|
+
|
|
409
|
+
```javascript
|
|
410
|
+
agent.prompt((state, input) => {
|
|
411
|
+
// Customize input before it reaches the LLM
|
|
412
|
+
return `[Processed] ${input}`;
|
|
413
|
+
});
|
|
414
|
+
|
|
415
|
+
agent.response((state, conversation, result) => {
|
|
416
|
+
// Process the result before returning to the user
|
|
417
|
+
return `Agent says: ${result}`;
|
|
418
|
+
});
|
|
419
|
+
```
|
|
420
|
+
|
|
421
|
+
### Multi-Agent Systems
|
|
422
|
+
|
|
423
|
+
Create autonomous networks of specialized agents that collaborate without human intervention:
|
|
424
|
+
|
|
425
|
+
```javascript
|
|
426
|
+
// Create specialized agents
|
|
427
|
+
const weatherAgent = Agent()
|
|
428
|
+
.setMetadata({ name: "weatherAgent" })
|
|
429
|
+
.addIO(NatsIO({ servers: ['nats://localhost:4222'] }), {
|
|
430
|
+
network: "smartchat",
|
|
431
|
+
bindings: {
|
|
432
|
+
discoveryTopic: "smartness.discovery"
|
|
433
|
+
}
|
|
434
|
+
})
|
|
435
|
+
.addToolSchema(weatherToolSchema);
|
|
436
|
+
|
|
437
|
+
const travelAgent = Agent()
|
|
438
|
+
.setMetadata({ name: "travelAgent" })
|
|
439
|
+
.addIO(NatsIO({ servers: ['nats://localhost:4222'] }), {
|
|
440
|
+
network: "smartchat",
|
|
441
|
+
bindings: {
|
|
442
|
+
discoveryTopic: "smartness.discovery"
|
|
443
|
+
}
|
|
444
|
+
})
|
|
445
|
+
.addToolSchema(travelToolSchema);
|
|
446
|
+
|
|
447
|
+
// The main agent that orchestrates others
|
|
448
|
+
const smartAgent = Agent()
|
|
449
|
+
.setMetadata({ name: "smartAgent" })
|
|
450
|
+
.addIO(NatsIO({ servers: ['nats://localhost:4222'] }), {
|
|
451
|
+
network: "smartchat",
|
|
452
|
+
bindings: {
|
|
453
|
+
discoveryTopic: "smartness.discovery",
|
|
454
|
+
acceptedNetworks: ["smartchat.*"]
|
|
455
|
+
}
|
|
456
|
+
})
|
|
457
|
+
.addDiscoverySchema(weatherDiscoverySchema)
|
|
458
|
+
.addDiscoverySchema(travelDiscoverySchema);
|
|
459
|
+
|
|
460
|
+
// Compile and connect all agents
|
|
461
|
+
await weatherAgent.compile();
|
|
462
|
+
await travelAgent.compile();
|
|
463
|
+
await smartAgent.compile();
|
|
464
|
+
|
|
465
|
+
// Query through the main agent
|
|
466
|
+
const response = await smartAgent.query(
|
|
467
|
+
"Plan a trip to Paris and tell me about the weather"
|
|
468
|
+
);
|
|
469
|
+
```
|
|
470
|
+
|
|
471
|
+
In this autonomous network:
|
|
472
|
+
- Each agent is responsible for a specific domain of expertise
|
|
473
|
+
- The orchestrator agent (smartAgent) discovers and routes requests to appropriate specialists
|
|
474
|
+
- The network can scale by adding more specialized agents without changing existing ones
|
|
475
|
+
- Agents can be deployed across different environments while maintaining communication
|
|
476
|
+
|
|
477
|
+
### Session State Management
|
|
478
|
+
|
|
479
|
+
The Agentnet framework provides robust session management for maintaining state across conversations and agent interactions:
|
|
480
|
+
|
|
481
|
+
```javascript
|
|
482
|
+
// Creating a message with session information
|
|
483
|
+
const message = new Message({
|
|
484
|
+
content: "What rooms do you have available?",
|
|
485
|
+
session: {
|
|
486
|
+
id: "67a71e42-a7d8-1db2-ad17-64e1c8546b21", // Reserved system ID
|
|
487
|
+
propertySetId: "123", // Custom session data
|
|
488
|
+
userPreferences: { roomType: "suite" } // Custom session data
|
|
489
|
+
}
|
|
490
|
+
});
|
|
491
|
+
|
|
492
|
+
// Query the agent with session context
|
|
493
|
+
const result = await agentInstance.query(message);
|
|
494
|
+
```
|
|
495
|
+
|
|
496
|
+
#### Session ID
|
|
497
|
+
|
|
498
|
+
The `id` keyword in the session object is reserved for the system. It's used to uniquely identify the session for:
|
|
499
|
+
- Loading session state from persistent storage
|
|
500
|
+
- Saving session state back to storage
|
|
501
|
+
- Tracking conversation history
|
|
502
|
+
|
|
503
|
+
#### State Propagation
|
|
504
|
+
|
|
505
|
+
Session variables have different scopes:
|
|
506
|
+
|
|
507
|
+
1. **Regular variables** (without underscore prefix) are propagated between agents during handoffs, ensuring continuity of context across the agent system.
|
|
508
|
+
|
|
509
|
+
2. **Private variables** (with underscore prefix `_`) are agent-specific and not shared during handoffs. For example:
|
|
510
|
+
```javascript
|
|
511
|
+
message.session._agentPrivateData = "This stays with the current agent";
|
|
512
|
+
message.session.sharedData = "This is passed between agents";
|
|
513
|
+
```
|
|
514
|
+
|
|
515
|
+
When a session is saved to storage, private variables (starting with `_`) are saved on the agent store, but removed from response to the calling agent to keep the session data clean and focused on shareable information.
|
|
516
|
+
|
|
517
|
+
#### Stores Configuration
|
|
518
|
+
|
|
519
|
+
Agentnet supports different storage backends for persisting session state:
|
|
520
|
+
|
|
521
|
+
```javascript
|
|
522
|
+
// Configure the agent with a Postgres store
|
|
523
|
+
const agents = await AgentLoaderJSON(agentDefinition, {
|
|
524
|
+
bindings: {
|
|
525
|
+
[Bindings.Postgres]: PostgresStore({
|
|
526
|
+
url: "postgres://postgres:postgres@localhost:5432/postgres"
|
|
527
|
+
})
|
|
528
|
+
}
|
|
529
|
+
});
|
|
530
|
+
|
|
531
|
+
// Or with an in-memory store for testing
|
|
532
|
+
const agents = await AgentLoaderJSON(agentDefinition, {
|
|
533
|
+
bindings: {
|
|
534
|
+
[Bindings.Memory]: MemoryStore()
|
|
535
|
+
}
|
|
536
|
+
});
|
|
537
|
+
```
|
|
538
|
+
|
|
539
|
+
#### Session Life Cycle
|
|
540
|
+
|
|
541
|
+
1. When an agent receives a query with a session ID, it attempts to load the existing session state
|
|
542
|
+
2. The state is merged with any new session data provided in the query
|
|
543
|
+
3. The agent processes the query with access to this state
|
|
544
|
+
4. Before responding, the updated state is saved back to storage
|
|
545
|
+
5. Private variables (with `_` prefix) are removed from the response
|
|
546
|
+
|
|
547
|
+
This mechanism allows agents to maintain context across multiple interactions while keeping appropriate boundaries between agent-specific and shared data.
|
|
548
|
+
|
|
549
|
+
## Installation
|
|
550
|
+
|
|
551
|
+
```bash
|
|
552
|
+
npm install agentnet
|
|
553
|
+
```
|
|
554
|
+
|
|
Binary file
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
# Customer Support Multiagent System
|
|
2
|
+
|
|
3
|
+
This example demonstrates a comprehensive customer support system built with multiple specialized agents that collaborate to handle customer inquiries.
|
|
4
|
+
|
|
5
|
+
## Overview
|
|
6
|
+
|
|
7
|
+
The system consists of six specialized agents:
|
|
8
|
+
|
|
9
|
+
1. **Triage Agent**: Greets customers, analyzes their query, and routes them to the appropriate specialist agent.
|
|
10
|
+
2. **Product Agent**: Answers questions about product features, specifications, and compatibility.
|
|
11
|
+
3. **Technical Agent**: Helps troubleshoot technical issues and provides step-by-step instructions.
|
|
12
|
+
4. **Billing Agent**: Handles payment-related inquiries, subscription questions, and refund requests.
|
|
13
|
+
5. **Escalation Agent**: Addresses complex issues that cannot be handled by other specialized agents.
|
|
14
|
+
6. **Follow-up Agent**: Checks in with customers after resolution to ensure satisfaction.
|
|
15
|
+
|
|
16
|
+
## Architecture
|
|
17
|
+
|
|
18
|
+
- Each agent is defined declaratively in YAML with its own system instructions, tools, and discovery schemas.
|
|
19
|
+
- Agents communicate with each other through NATS as the transport mechanism.
|
|
20
|
+
- The system maintains a shared session context to track customer interactions across agents.
|
|
21
|
+
- Tool implementations are bound to each agent to provide the actual functionality.
|
|
22
|
+
|
|
23
|
+
## How It Works
|
|
24
|
+
|
|
25
|
+
1. When a customer submits a query, it is first processed by the Triage Agent.
|
|
26
|
+
2. The Triage Agent categorizes the query and routes it to the appropriate specialist agent.
|
|
27
|
+
3. The specialist agent uses its tools to gather information and provide a solution.
|
|
28
|
+
4. For complex issues, escalation to a higher-tier agent is possible.
|
|
29
|
+
5. Once the issue is resolved, the Follow-up Agent checks in with the customer.
|
|
30
|
+
|
|
31
|
+
## Mock Data
|
|
32
|
+
|
|
33
|
+
For demonstration purposes, this example includes mock data for:
|
|
34
|
+
- Product information
|
|
35
|
+
- Customer accounts
|
|
36
|
+
- Known technical issues
|
|
37
|
+
- Support case histories
|
|
38
|
+
|
|
39
|
+
In a production environment, these would be connected to real databases and APIs.
|
|
40
|
+
|
|
41
|
+
## Running the Example
|
|
42
|
+
|
|
43
|
+
To run this example:
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
node examples/customer-support/index.js
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
## Example Workflow
|
|
50
|
+
|
|
51
|
+
The code demonstrates a complete workflow through these stages:
|
|
52
|
+
|
|
53
|
+
1. Customer query: "My SuperWidget Pro won't turn on after charging it overnight."
|
|
54
|
+
2. Triage Agent categorizes this as a technical issue.
|
|
55
|
+
3. Technical Agent provides troubleshooting steps.
|
|
56
|
+
4. The issue is marked as resolved in the system.
|
|
57
|
+
5. Follow-up Agent checks in to ensure customer satisfaction.
|
|
58
|
+
|
|
59
|
+
## Extending the Example
|
|
60
|
+
|
|
61
|
+
You can extend this example by:
|
|
62
|
+
- Adding more specialized agents
|
|
63
|
+
- Implementing real database connections
|
|
64
|
+
- Adding authentication and authorization
|
|
65
|
+
- Creating a user interface for customers
|
|
66
|
+
- Integrating with existing support ticketing systems
|