neoagent 2.4.4-beta.8 → 2.5.0
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/.env.example +17 -0
- package/README.md +64 -57
- package/docs/agent-run-lifecycle.md +65 -0
- package/docs/agents-and-users.md +48 -0
- package/docs/architecture.md +59 -0
- package/docs/automation-architecture.md +50 -0
- package/docs/automation.md +54 -70
- package/docs/capabilities.md +16 -118
- package/docs/clients-and-devices.md +43 -0
- package/docs/configuration.md +104 -116
- package/docs/development.md +82 -0
- package/docs/devices.md +62 -0
- package/docs/getting-started.md +47 -57
- package/docs/index.md +41 -30
- package/docs/integrations-architecture.md +48 -0
- package/docs/integrations.md +56 -51
- package/docs/memory-architecture.md +90 -0
- package/docs/memory.md +78 -0
- package/docs/migration.md +12 -5
- package/docs/models.md +64 -0
- package/docs/operations.md +46 -30
- package/docs/persistence.md +49 -0
- package/docs/recordings-and-health.md +41 -0
- package/docs/runtime-and-tools.md +52 -0
- package/docs/security-boundaries.md +65 -111
- package/docs/skills.md +32 -45
- package/docs/why-neoagent.md +47 -16
- package/flutter_app/lib/main_account_settings.dart +79 -15
- package/flutter_app/lib/main_chat.dart +155 -8
- package/flutter_app/lib/main_controller.dart +38 -4
- package/flutter_app/lib/main_devices.dart +9 -3
- package/flutter_app/lib/main_models.dart +32 -0
- package/landing/index.html +0 -4
- package/lib/install_helpers.js +1 -0
- package/lib/manager.js +63 -1
- package/package.json +2 -2
- package/server/admin/admin.js +151 -0
- package/server/admin/index.html +55 -3
- package/server/public/.last_build_id +1 -1
- package/server/public/flutter_bootstrap.js +1 -1
- package/server/public/main.dart.js +50995 -50850
- package/server/routes/account.js +2 -23
- package/server/routes/admin.js +18 -2
- package/server/routes/agents.js +5 -1
- package/server/routes/memory.js +2 -2
- package/server/services/account/service_email_settings.js +167 -0
- package/server/services/ai/engine.js +2 -17
- package/server/services/ai/rate_limits.js +150 -0
- package/server/services/ai/tools.js +11 -8
- package/server/services/memory/manager.js +0 -3
- package/server/services/websocket.js +5 -1
- package/docs/supermemory-memory-review.md +0 -852
package/.env.example
CHANGED
|
@@ -42,6 +42,11 @@ NEOAGENT_PROFILE=prod
|
|
|
42
42
|
# can always register regardless of this setting).
|
|
43
43
|
# NEOAGENT_ALLOW_SIGNUP=false
|
|
44
44
|
|
|
45
|
+
# Rolling per-user AI token limits. Users can have custom overrides in the
|
|
46
|
+
# admin dashboard.
|
|
47
|
+
NEOAGENT_RATE_LIMIT_4H=2500000
|
|
48
|
+
NEOAGENT_RATE_LIMIT_WEEKLY=10000000
|
|
49
|
+
|
|
45
50
|
# VM runtime settings used by `prod`.
|
|
46
51
|
# Set these before switching NEOAGENT_PROFILE=prod.
|
|
47
52
|
# The app can cache a shared base image automatically from a URL, then create
|
|
@@ -80,6 +85,18 @@ NEOAGENT_EMAIL_SMTP_HOST=
|
|
|
80
85
|
NEOAGENT_EMAIL_SMTP_PORT=587
|
|
81
86
|
NEOAGENT_EMAIL_SMTP_USER=
|
|
82
87
|
NEOAGENT_EMAIL_SMTP_PASS=
|
|
88
|
+
NEOAGENT_EMAIL_SMTP_SECURE=false
|
|
89
|
+
NEOAGENT_EMAIL_SMTP_REQUIRE_TLS=true
|
|
90
|
+
NEOAGENT_EMAIL_SMTP_REJECT_UNAUTHORIZED=true
|
|
91
|
+
NEOAGENT_EMAIL_REPLY_TO=
|
|
92
|
+
NEOAGENT_EMAIL_REQUIRE_SIGNUP_CONFIRMATION=true
|
|
93
|
+
NEOAGENT_EMAIL_REQUIRE_EMAIL_CHANGE_CONFIRMATION=true
|
|
94
|
+
NEOAGENT_EMAIL_NOTIFY_UNUSUAL_LOGIN=true
|
|
95
|
+
NEOAGENT_EMAIL_NOTIFY_ACCOUNT_CHANGES=true
|
|
96
|
+
NEOAGENT_EMAIL_BRAND_NAME=NeoAgent
|
|
97
|
+
NEOAGENT_EMAIL_SUPPORT_URL=
|
|
98
|
+
NEOAGENT_EMAIL_PUBLIC_URL=
|
|
99
|
+
NEOAGENT_EMAIL_TOKEN_TTL_HOURS=24
|
|
83
100
|
|
|
84
101
|
########################################
|
|
85
102
|
# Hosted AI providers
|
package/README.md
CHANGED
|
@@ -4,90 +4,97 @@
|
|
|
4
4
|
|
|
5
5
|
<h1 align="center">NeoAgent</h1>
|
|
6
6
|
|
|
7
|
-
<p align="center"><strong>
|
|
7
|
+
<p align="center"><strong>A self-hosted AI agent that can keep working after the chat ends.</strong></p>
|
|
8
8
|
|
|
9
|
-
<p align="center">
|
|
9
|
+
<p align="center">
|
|
10
|
+
NeoAgent runs as a service on your server. It can use a browser and terminal,
|
|
11
|
+
control Android devices, connect to your accounts, remember useful context,
|
|
12
|
+
and run scheduled or event-triggered work.
|
|
13
|
+
</p>
|
|
10
14
|
|
|
11
15
|
<p align="center">
|
|
12
16
|
<a href="https://www.npmjs.com/package/neoagent"><img src="https://img.shields.io/npm/v/neoagent?style=flat-square&label=npm" alt="npm version"></a>
|
|
13
|
-
<a href="https://nodejs.org"><img src="https://img.shields.io/badge/Node.js-20
|
|
14
|
-
<a href="
|
|
15
|
-
<a href="https://flutter.dev"><img src="https://img.shields.io/badge/Flutter-web%20%2B%20android-02569B?style=flat-square&logo=flutter&logoColor=white" alt="Flutter"></a>
|
|
16
|
-
<a href="LICENSE"><img src="https://img.shields.io/badge/License-AGPL--3.0-a855f7?style=flat-square" alt="License"></a>
|
|
17
|
+
<a href="https://nodejs.org"><img src="https://img.shields.io/badge/Node.js-20%2B-5fa04e?style=flat-square" alt="Node.js 20 or newer"></a>
|
|
18
|
+
<a href="LICENSE"><img src="https://img.shields.io/badge/license-AGPL--3.0-a855f7?style=flat-square" alt="AGPL-3.0 license"></a>
|
|
17
19
|
</p>
|
|
18
20
|
|
|
19
21
|
<p align="center">
|
|
20
|
-
<img src="demo.gif" alt="NeoAgent
|
|
22
|
+
<img src="demo.gif" alt="NeoAgent operator interface" width="100%">
|
|
21
23
|
</p>
|
|
22
24
|
|
|
23
|
-
##
|
|
24
|
-
|
|
25
|
-
| Android that the agent can operate | Credentials that stay server-side |
|
|
26
|
-
| --- | --- |
|
|
27
|
-
| NeoAgent can inspect the UI, take screenshots, tap, swipe, type, launch apps, install APKs, and run `adb shell` against a connected device or emulator. | API keys, OAuth tokens, messaging credentials, history, and runtime data are stored under `~/.neoagent` on the server, never in the client. |
|
|
25
|
+
## 🚀 Install
|
|
28
26
|
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
27
|
+
NeoAgent supports macOS and Linux hosts. You need Node.js 20 or newer; the
|
|
28
|
+
installer handles the rest of the application setup and attempts to install
|
|
29
|
+
QEMU for the isolated browser and terminal runtime.
|
|
32
30
|
|
|
33
31
|
```bash
|
|
34
32
|
npm install -g neoagent
|
|
35
33
|
neoagent install
|
|
36
34
|
```
|
|
37
35
|
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
36
|
+
Open `http://localhost:3333`, create the first account, and configure a model.
|
|
37
|
+
Local models can run through [Ollama](https://ollama.com/); hosted providers
|
|
38
|
+
can be configured in the application.
|
|
41
39
|
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
setup.
|
|
40
|
+
Read the [installation guide](docs/getting-started.md) before exposing the
|
|
41
|
+
service to a network.
|
|
45
42
|
|
|
46
|
-
## What
|
|
43
|
+
## ✨ What makes it different
|
|
47
44
|
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
- **Browser and shell**: an isolated browser runtime plus a full PTY terminal on the NeoAgent server.
|
|
51
|
-
- **Integrations**: Google Workspace, Microsoft 365, Notion, Home Assistant, Trello, Spotify, Slack, Figma, GitHub, and more.
|
|
52
|
-
- **Recordings and memory**: audio capture, transcription, transcript search, long-term memory, session history, and health summaries.
|
|
53
|
-
- **Model choice**: Anthropic, OpenAI, Gemini, Grok, MiniMax, NVIDIA NIM, OpenRouter, GitHub Copilot, OpenAI Codex, or local Ollama.
|
|
45
|
+
**It is a service, not just a chat window.** NeoAgent keeps tasks, integrations,
|
|
46
|
+
memory, connected devices, and messaging channels available between sessions.
|
|
54
47
|
|
|
55
|
-
|
|
48
|
+
**Memory is stored as structured local data.** Durable facts are separated from
|
|
49
|
+
conversation history, scoped by user and agent, and updated when newer
|
|
50
|
+
information replaces older information. NeoAgent can also index supported
|
|
51
|
+
integration content with source references. See [How memory works](docs/memory.md).
|
|
56
52
|
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
53
|
+
**It operates real devices.** The agent can use an isolated browser and shell,
|
|
54
|
+
control an Android device or emulator over ADB, or work through a paired Chrome
|
|
55
|
+
extension and desktop companion.
|
|
60
56
|
|
|
61
|
-
|
|
57
|
+
**Automation can start without a message.** Tasks can run on a schedule or from
|
|
58
|
+
supported Gmail, Outlook, Slack, Teams, personal WhatsApp, and weather events.
|
|
59
|
+
Android notifications can also start an agent run.
|
|
62
60
|
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
neoagent restart
|
|
68
|
-
neoagent update
|
|
69
|
-
neoagent fix
|
|
70
|
-
neoagent logs
|
|
71
|
-
```
|
|
61
|
+
**Agents and users have separate state.** Specialist agents can have their own
|
|
62
|
+
memory, settings, tools, account assignments, conversations, and task history.
|
|
63
|
+
Multi-user deployments include administrative account controls and optional
|
|
64
|
+
email confirmation.
|
|
72
65
|
|
|
73
|
-
|
|
66
|
+
**The same server has several interfaces.** NeoAgent includes web, Android,
|
|
67
|
+
desktop, and Android launcher clients, messaging bridges, a Chrome extension,
|
|
68
|
+
and firmware for a supported ESP32-S3 wearable.
|
|
74
69
|
|
|
75
|
-
|
|
76
|
-
please report failures with enough detail to reproduce them. Contributions to
|
|
77
|
-
the backend, Flutter clients, integrations, skills, tests, and documentation
|
|
78
|
-
are welcome.
|
|
70
|
+
## 🖥️ Interfaces
|
|
79
71
|
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
privately according to [SECURITY.md](SECURITY.md).
|
|
72
|
+
| Operator interface | Memory | Remote devices |
|
|
73
|
+
| --- | --- | --- |
|
|
74
|
+
|  |  |  |
|
|
84
75
|
|
|
85
|
-
##
|
|
76
|
+
## 🔎 NeoAgent, OpenClaw, and Hermes
|
|
86
77
|
|
|
87
|
-
|
|
78
|
+
NeoAgent is aimed at people who want a UI-first, self-hosted agent with
|
|
79
|
+
structured local memory, multi-user administration, automation, and direct
|
|
80
|
+
Android control in one installation.
|
|
88
81
|
|
|
89
|
-
|
|
82
|
+
OpenClaw has a broader gateway and node ecosystem. Hermes is oriented around a
|
|
83
|
+
terminal-first agent workflow. NeoAgent is a different tradeoff rather than a
|
|
84
|
+
blanket replacement for either project.
|
|
90
85
|
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
86
|
+
The [comparison page](docs/why-neoagent.md) records the concrete differences
|
|
87
|
+
and links to the source material used.
|
|
88
|
+
|
|
89
|
+
## 🧪 Project status
|
|
90
|
+
|
|
91
|
+
NeoAgent is beta software maintained primarily by one person. Expect breaking
|
|
92
|
+
changes and rough edges. Review the
|
|
93
|
+
[security boundaries](docs/security-boundaries.md) before connecting sensitive
|
|
94
|
+
accounts or giving the agent access to a personal workstation.
|
|
95
|
+
|
|
96
|
+
Start with the [documentation](https://neolabs-systems.github.io/NeoAgent/docs/).
|
|
97
|
+
Use [GitHub Discussions](https://github.com/NeoLabs-Systems/NeoAgent/discussions)
|
|
98
|
+
for questions and [GitHub Issues](https://github.com/NeoLabs-Systems/NeoAgent/issues)
|
|
99
|
+
for reproducible bugs. Security reports belong in the process described by
|
|
100
|
+
[SECURITY.md](SECURITY.md).
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Agent run lifecycle
|
|
2
|
+
|
|
3
|
+
An agent run is the durable execution record for a chat request, scheduled
|
|
4
|
+
task, integration event, messaging event, widget refresh, or delegated job.
|
|
5
|
+
|
|
6
|
+
## 1. Resolve context
|
|
7
|
+
|
|
8
|
+
The caller supplies the user, agent, trigger source, conversation, and optional
|
|
9
|
+
model override. The engine resolves the effective agent settings and available
|
|
10
|
+
models, then creates the run record.
|
|
11
|
+
|
|
12
|
+
The prompt context can include:
|
|
13
|
+
|
|
14
|
+
- Agent identity and behavior settings
|
|
15
|
+
- Conversation history and working summary
|
|
16
|
+
- Core memory and the auto-maintained user profile
|
|
17
|
+
- Query-specific recalled memory
|
|
18
|
+
- Installed skills
|
|
19
|
+
- Available integrations, MCP tools, and runtime health
|
|
20
|
+
- Platform-specific output guidance
|
|
21
|
+
|
|
22
|
+
Large history and tool results are compacted before model calls.
|
|
23
|
+
|
|
24
|
+
## 2. Analyze and select tools
|
|
25
|
+
|
|
26
|
+
The engine classifies the request as a direct response or an execution task,
|
|
27
|
+
selects a planning depth, and activates a bounded tool catalog. Complex runs
|
|
28
|
+
can produce an execution plan, use subagents, and request a final verification
|
|
29
|
+
pass.
|
|
30
|
+
|
|
31
|
+
Model selection is scoped to the user and agent. Explicit run or task
|
|
32
|
+
overrides take precedence when the requested model is enabled and available.
|
|
33
|
+
|
|
34
|
+
## 3. Execute the loop
|
|
35
|
+
|
|
36
|
+
Each model turn can return text, completion state, or tool calls. Before a tool
|
|
37
|
+
runs:
|
|
38
|
+
|
|
39
|
+
1. Arguments are normalized.
|
|
40
|
+
2. The `before_tool_call` hooks execute.
|
|
41
|
+
3. Server security policy can deny or suspend the call for approval.
|
|
42
|
+
4. The tool is dispatched to its service or runtime backend.
|
|
43
|
+
5. The result is compacted and appended to the next model turn.
|
|
44
|
+
|
|
45
|
+
The engine records steps, run events, model usage, timing, and artifacts.
|
|
46
|
+
Repetition guards and loop limits prevent unbounded retries.
|
|
47
|
+
|
|
48
|
+
## 4. Complete and deliver
|
|
49
|
+
|
|
50
|
+
The final response is sanitized and stored. Messaging-triggered runs send an
|
|
51
|
+
explicit message or use the final response as a fallback when nothing visible
|
|
52
|
+
was already delivered.
|
|
53
|
+
|
|
54
|
+
The engine emits `run:complete`, persists prompt and usage metrics, refreshes
|
|
55
|
+
conversation summaries and working state, and cancels unfinished subagents.
|
|
56
|
+
Failures and user stops produce separate terminal run states.
|
|
57
|
+
|
|
58
|
+
## 5. Post-run processing
|
|
59
|
+
|
|
60
|
+
Completed conversations can run structured memory consolidation. The engine
|
|
61
|
+
extracts durable candidates, reconciles updates, and invalidates prompt caches
|
|
62
|
+
after memory changes.
|
|
63
|
+
|
|
64
|
+
The `on_loop_end` hook provides a non-blocking observer for learning and
|
|
65
|
+
analytics. Hook errors cannot change the completed run outcome.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Agents and users
|
|
2
|
+
|
|
3
|
+
NeoAgent separates two concepts:
|
|
4
|
+
|
|
5
|
+
- A **user** is an account that can sign in to the server.
|
|
6
|
+
- An **agent** is a configured AI identity owned by a user.
|
|
7
|
+
|
|
8
|
+
## Agents
|
|
9
|
+
|
|
10
|
+
The main agent is created automatically. Additional agents are managed in the
|
|
11
|
+
operator interface and can be used as specialists.
|
|
12
|
+
|
|
13
|
+
Each agent has its own conversations, memory, model settings, integrations,
|
|
14
|
+
messaging assignments, tasks, and run history. This separation lets one user
|
|
15
|
+
maintain, for example, a personal agent and a work agent without merging their
|
|
16
|
+
context.
|
|
17
|
+
|
|
18
|
+
Agents can also be marked for orchestrator use. An orchestrator can delegate
|
|
19
|
+
work to other agents; a normal specialist is intended to complete its assigned
|
|
20
|
+
run directly.
|
|
21
|
+
|
|
22
|
+
## User accounts
|
|
23
|
+
|
|
24
|
+
Self-hosted installations can support more than one account. Administrative
|
|
25
|
+
controls include account management, provider configuration, logs, and runtime
|
|
26
|
+
updates.
|
|
27
|
+
|
|
28
|
+
Optional SMTP configuration enables:
|
|
29
|
+
|
|
30
|
+
- Signup confirmation
|
|
31
|
+
- Password reset
|
|
32
|
+
- Email-change confirmation
|
|
33
|
+
- New-device or unusual-login notifications
|
|
34
|
+
- Password and account-change notifications
|
|
35
|
+
|
|
36
|
+
See [Configuration](configuration.md#service-email) for the server variables.
|
|
37
|
+
|
|
38
|
+
## Isolation model
|
|
39
|
+
|
|
40
|
+
Application data is scoped by user and, where applicable, agent. The default
|
|
41
|
+
browser and terminal runtime is created per user. Official integration
|
|
42
|
+
credentials remain server-side and are assigned to a particular user and
|
|
43
|
+
agent.
|
|
44
|
+
|
|
45
|
+
This is application and runtime isolation, not a promise that every capability
|
|
46
|
+
runs inside a VM. Android commands run through ADB on the NeoAgent host, and a
|
|
47
|
+
paired desktop or Chrome profile grants access to that paired machine. Read
|
|
48
|
+
[Security boundaries](security-boundaries.md) before hosting untrusted users.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Architecture
|
|
2
|
+
|
|
3
|
+
NeoAgent is a Node.js service with Flutter clients. The server owns
|
|
4
|
+
authentication, model access, agent execution, tools, integrations, automation,
|
|
5
|
+
memory, persistence, and real-time state.
|
|
6
|
+
|
|
7
|
+
## Main components
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
Flutter clients and messaging channels
|
|
11
|
+
|
|
|
12
|
+
Express + Socket.IO
|
|
13
|
+
|
|
|
14
|
+
agents / AI engine / tasks / integrations
|
|
15
|
+
|
|
|
16
|
+
runtime backends / SQLite / agent data
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
### Server
|
|
20
|
+
|
|
21
|
+
`server/index.js` creates the application and service managers. Express routes
|
|
22
|
+
handle HTTP boundaries and delegate behavior to services. Socket.IO publishes
|
|
23
|
+
run progress, approvals, messages, device state, and operational updates.
|
|
24
|
+
|
|
25
|
+
The server uses CommonJS. Routes should remain thin; business logic belongs in
|
|
26
|
+
`server/services/`.
|
|
27
|
+
|
|
28
|
+
### Clients
|
|
29
|
+
|
|
30
|
+
The Flutter codebase produces the web operator interface, Android client,
|
|
31
|
+
desktop clients, and Android launcher build. `MainController` is the root
|
|
32
|
+
application state object. Platform behavior is implemented through conditional
|
|
33
|
+
bridge files and native Android code where required.
|
|
34
|
+
|
|
35
|
+
### Persistence
|
|
36
|
+
|
|
37
|
+
NeoAgent uses one `better-sqlite3` database instance. It stores users, agents,
|
|
38
|
+
settings, conversations, runs, tasks, integration connections, memory,
|
|
39
|
+
recordings, health data, permissions, and operational state.
|
|
40
|
+
|
|
41
|
+
Runtime files live outside the package source under `NEOAGENT_HOME`. Schema
|
|
42
|
+
changes are applied through the migration layer rather than ad hoc service SQL.
|
|
43
|
+
|
|
44
|
+
### Execution runtimes
|
|
45
|
+
|
|
46
|
+
Browser and terminal tools normally use the per-user isolated runtime. A user
|
|
47
|
+
can select a paired Chrome extension for browser work or a paired desktop
|
|
48
|
+
client for shell and desktop control. Android remains a host ADB capability.
|
|
49
|
+
|
|
50
|
+
## Subsystem guides
|
|
51
|
+
|
|
52
|
+
- [Agent run lifecycle](agent-run-lifecycle.md)
|
|
53
|
+
- [Memory architecture](memory-architecture.md)
|
|
54
|
+
- [Runtime and tool execution](runtime-and-tools.md)
|
|
55
|
+
- [Agents, automation, and triggers](automation-architecture.md)
|
|
56
|
+
- [Integrations and messaging](integrations-architecture.md)
|
|
57
|
+
- [Clients and device bridges](clients-and-devices.md)
|
|
58
|
+
- [Persistence and migrations](persistence.md)
|
|
59
|
+
- [Development and testing](development.md)
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Agents, automation, and triggers
|
|
2
|
+
|
|
3
|
+
Agents, tasks, and runs share a common scope: user ID plus agent ID. A task does
|
|
4
|
+
not create a separate agent context; it invokes the configured agent with
|
|
5
|
+
trigger metadata.
|
|
6
|
+
|
|
7
|
+
## Agent profiles
|
|
8
|
+
|
|
9
|
+
The agent manager resolves the selected profile and guarantees a main agent for
|
|
10
|
+
each user. Agent-scoped tables store settings, conversations, memory, runs,
|
|
11
|
+
integration connections, and task ownership.
|
|
12
|
+
|
|
13
|
+
Orchestrator profiles can delegate work through subagents. Delegated runs keep
|
|
14
|
+
their own execution state while preserving the caller's user and intended
|
|
15
|
+
agent scope.
|
|
16
|
+
|
|
17
|
+
## Task adapters
|
|
18
|
+
|
|
19
|
+
The trigger registry loads adapters for:
|
|
20
|
+
|
|
21
|
+
- recurring and one-time schedules;
|
|
22
|
+
- manual execution;
|
|
23
|
+
- authenticated webhooks;
|
|
24
|
+
- Gmail and Outlook email;
|
|
25
|
+
- Slack and Teams messages;
|
|
26
|
+
- personal WhatsApp messages; and
|
|
27
|
+
- weather events.
|
|
28
|
+
|
|
29
|
+
Adapters validate and normalize configuration, summarize it for the UI, and
|
|
30
|
+
provide trigger-specific runtime behavior.
|
|
31
|
+
|
|
32
|
+
## Scheduling and polling
|
|
33
|
+
|
|
34
|
+
Recurring schedules are registered with `node-cron`. One-time tasks and polled
|
|
35
|
+
integration triggers are checked by runtime pollers. Event-capable integration
|
|
36
|
+
sources can attach listeners when the task runtime starts.
|
|
37
|
+
|
|
38
|
+
The repository prevents duplicate active executions for the same task and
|
|
39
|
+
records trigger fingerprints so the same external event is not repeatedly
|
|
40
|
+
processed.
|
|
41
|
+
|
|
42
|
+
## Execution and delivery
|
|
43
|
+
|
|
44
|
+
The task runtime creates an agent run with trigger context, captures the final
|
|
45
|
+
response, and optionally sends it to a normalized messaging target. Run success
|
|
46
|
+
and delivery success are distinct states.
|
|
47
|
+
|
|
48
|
+
Notification triggers from the Android client enter through a separate route
|
|
49
|
+
and directly request an agent evaluation; they are not stored schedule
|
|
50
|
+
adapters.
|
package/docs/automation.md
CHANGED
|
@@ -1,94 +1,78 @@
|
|
|
1
|
-
# Automation
|
|
1
|
+
# Automation and triggers
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Automations run the same agent loop and tools used by chat. They can start on a
|
|
4
|
+
schedule, from a supported account event, or through a webhook, and can deliver
|
|
5
|
+
their result through a configured messaging channel.
|
|
4
6
|
|
|
5
|
-
##
|
|
7
|
+
## Create a task
|
|
6
8
|
|
|
7
|
-
Open **Tasks
|
|
9
|
+
Open **Tasks**, choose the owning agent, select a trigger, and write a
|
|
10
|
+
self-contained instruction. A task can use the agent's model or a task-specific
|
|
11
|
+
override.
|
|
8
12
|
|
|
9
|
-
|
|
13
|
+
The currently implemented trigger families are:
|
|
14
|
+
|
|
15
|
+
| Trigger | Behavior |
|
|
10
16
|
|---|---|
|
|
11
|
-
|
|
|
12
|
-
|
|
|
13
|
-
|
|
|
14
|
-
|
|
|
15
|
-
|
|
|
17
|
+
| Schedule | Recurring cron expression or one-time timestamp |
|
|
18
|
+
| Gmail | Run when a matching Gmail message is received |
|
|
19
|
+
| Outlook | Run when a matching Outlook message is received |
|
|
20
|
+
| Slack | Run when a matching Slack message is received |
|
|
21
|
+
| Teams | Run when a matching Teams message is received |
|
|
22
|
+
| Personal WhatsApp | Run when a matching personal-account message is received |
|
|
23
|
+
| Weather | Run for configured forecast events such as rain or temperature thresholds |
|
|
24
|
+
| Webhook | Run after an authenticated task webhook request |
|
|
16
25
|
|
|
17
|
-
|
|
26
|
+
The Android app can also forward device notifications to
|
|
27
|
+
`/api/triggers/notification`. Notification runs are evaluated by the agent and
|
|
28
|
+
are separate from saved tasks.
|
|
18
29
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
│ │ │ │ │
|
|
26
|
-
* * * * *
|
|
30
|
+
## Schedules
|
|
31
|
+
|
|
32
|
+
Recurring tasks use five-field cron:
|
|
33
|
+
|
|
34
|
+
```text
|
|
35
|
+
minute hour day-of-month month day-of-week
|
|
27
36
|
```
|
|
28
37
|
|
|
29
|
-
|
|
38
|
+
Examples:
|
|
30
39
|
|
|
31
40
|
| Expression | Runs |
|
|
32
41
|
|---|---|
|
|
33
|
-
| `0 9 * * *` |
|
|
34
|
-
| `0 9 * * 1-5` | Weekdays at
|
|
35
|
-
| `0 8 * * 1` |
|
|
36
|
-
| `0 18 * * 5` | Every Friday at 6:00 PM |
|
|
37
|
-
| `0 9 1 * *` | First of every month at 9:00 AM |
|
|
38
|
-
| `0 */4 * * *` | Every 4 hours |
|
|
42
|
+
| `0 9 * * *` | Every day at 09:00 |
|
|
43
|
+
| `0 9 * * 1-5` | Weekdays at 09:00 |
|
|
44
|
+
| `0 8 * * 1` | Mondays at 08:00 |
|
|
39
45
|
| `*/30 * * * *` | Every 30 minutes |
|
|
40
46
|
|
|
41
|
-
|
|
47
|
+
Schedules use the server's configured time context. Confirm the next-run value
|
|
48
|
+
shown in the UI when the server and user are in different time zones.
|
|
42
49
|
|
|
43
|
-
|
|
50
|
+
## Write unattended instructions
|
|
44
51
|
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
```
|
|
52
|
+
A task prompt must contain enough context to run later without the current chat.
|
|
53
|
+
State what to inspect, what counts as actionable, where to deliver the result,
|
|
54
|
+
and when no message should be sent.
|
|
49
55
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
56
|
+
```text
|
|
57
|
+
Search unread Gmail received since the previous run. Summarize messages that
|
|
58
|
+
need a reply and send the summary to my Telegram chat. Do not send anything
|
|
59
|
+
when no reply is needed.
|
|
53
60
|
```
|
|
54
61
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
Run `df -h` and `free -m`. If disk usage on any partition is above 85% or available memory is below 500MB, send me a Telegram alert with the details. Otherwise do nothing.
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
**Weekly email digest**
|
|
61
|
-
```
|
|
62
|
-
Search my Gmail for unread emails from the last 7 days. Group them by sender domain and summarize the main topics. Send the summary to my Telegram.
|
|
63
|
-
```
|
|
62
|
+
Prefer official integrations or MCP tools over browser automation when both
|
|
63
|
+
can perform the action. Structured tools are easier to restrict and diagnose.
|
|
64
64
|
|
|
65
|
-
##
|
|
65
|
+
## Runs and delivery
|
|
66
66
|
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|---|---|
|
|
71
|
-
| **Browser** | Navigate, extract content, screenshot, evaluate JavaScript |
|
|
72
|
-
| **CLI** | Shell commands in a persistent terminal |
|
|
73
|
-
| **Files** | Read, write, search host files |
|
|
74
|
-
| **Memory** | Store and retrieve long-term facts |
|
|
75
|
-
| **Messaging** | Send results through any connected platform |
|
|
76
|
-
| **MCP** | Tools from configured remote MCP servers |
|
|
77
|
-
| **Integrations** | Gmail, Calendar, Notion, Slack, and other OAuth tools |
|
|
78
|
-
| **Recordings** | Search and read transcripts |
|
|
79
|
-
| **Health** | Read synced Android Health Connect metrics |
|
|
80
|
-
| **Android** | Control an emulator or device |
|
|
81
|
-
| **Subagents** | Spawn parallel helpers inside a longer run |
|
|
82
|
-
| **Outputs** | Artifacts, images, Mermaid graphs, markdown tables |
|
|
83
|
-
|
|
84
|
-
Prefer official integrations and MCP tools over browser automation when both can do the job — they are more reliable and easier to audit.
|
|
67
|
+
Open **Runs** to inspect the trigger, tool calls, approvals, output, and error
|
|
68
|
+
for each execution. Delivery requires a configured messaging destination; a
|
|
69
|
+
completed run can still have a delivery error.
|
|
85
70
|
|
|
86
71
|
## Safety
|
|
87
72
|
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
-
|
|
92
|
-
-
|
|
93
|
-
-
|
|
94
|
-
- Browser, CLI, Android, and file tools run on the NeoAgent server — not necessarily your current laptop
|
|
73
|
+
- Start with read-only integration accounts.
|
|
74
|
+
- Keep write, shell, Android, and desktop categories on approval unless the
|
|
75
|
+
task runs in a controlled environment.
|
|
76
|
+
- Do not put secrets in prompts.
|
|
77
|
+
- Restrict messaging allowlists so untrusted chats cannot trigger an agent.
|
|
78
|
+
- Treat email, web pages, messages, and webhook bodies as untrusted input.
|