@rudderhq/cli 0.2.7-canary.4 → 0.2.7-canary.6
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 +48 -47
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,76 +1,76 @@
|
|
|
1
1
|
# Rudder
|
|
2
2
|
|
|
3
|
-
>
|
|
3
|
+
> Build your self-improving Agent Team.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Agents that think, build, play, and learn from real work.
|
|
6
6
|
|
|
7
|
-
Rudder
|
|
7
|
+
Rudder turns goals, issues, agent runs, reviews, and feedback into a work loop for agent teams. It gives humans and agents a shared operating structure for assigning work, running agents, reviewing outputs, controlling spend, and preserving the lessons that should make the next run better.
|
|
8
8
|
|
|
9
|
-
Rudder
|
|
10
|
-
|
|
11
|
-
## The Design Idea
|
|
9
|
+
Rudder began as a fork of an early version of Paperclip. That gave the project a practical starting point for agent operations; Rudder is now evolving around a sharper product idea: agent teams improve when real work leaves behind durable context, decisions, feedback, and reusable operating patterns.
|
|
12
10
|
|
|
13
|
-
Rudder is
|
|
11
|
+
Rudder is built for the moment when agent work stops looking like a single prompt and starts looking like a real team.
|
|
14
12
|
|
|
15
|
-
|
|
13
|
+
## The Work Loop
|
|
16
14
|
|
|
17
|
-
Rudder
|
|
15
|
+
Rudder is designed around the loop that makes agent work compound:
|
|
18
16
|
|
|
19
|
-
|
|
17
|
+
```text
|
|
18
|
+
Goal -> Issue -> Agent run -> Review -> Feedback -> Learning -> Better future runs
|
|
19
|
+
```
|
|
20
20
|
|
|
21
|
-
|
|
21
|
+
The control plane matters because this loop needs structure. Goals explain why work exists. Issues make work durable. Heartbeats run agents in a visible way. Reviews and approvals keep autonomy governable. Feedback, comments, documents, run history, and skills give the team a place to keep what it learned.
|
|
22
22
|
|
|
23
|
-
|
|
23
|
+
Rudder does not assume every lesson is automatically promoted into a new skill or workflow. The product direction is to make those promotion paths explicit, reviewable, and reusable instead of leaving them buried in chat transcripts or one-off prompts.
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
## The Design Idea
|
|
26
26
|
|
|
27
|
-
|
|
27
|
+
The most useful way to work with agents is closer to the way humans coordinate with each other.
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
People do not operate through one giant shared prompt. They work through shared goals, explicit roles, durable work objects, context attached to the task, clear handoffs, and escalation paths when judgment or approval is needed. Teams also need visibility: what is moving, what is blocked, what it costs, and where intervention matters.
|
|
30
30
|
|
|
31
|
-
|
|
31
|
+
Rudder turns those coordination patterns into product primitives for agent teams:
|
|
32
32
|
|
|
33
|
-
|
|
34
34
|
|
|
35
|
-
|
|
36
36
|
|
|
37
|
-
|
|
38
38
|
|
|
39
|
+
|
|
39
40
|
|
|
41
|
+
|
|
40
42
|
|
|
41
|
-
|
|
43
|
+
|
|
42
44
|
|
|
43
|
-
|
|
44
|
-
- every task should trace back to a goal
|
|
45
|
-
- agents should have explicit roles, runtime config, and reporting lines
|
|
46
|
-
- chat should help clarify and route work, while durable execution stays attached to issues, approvals, and outputs
|
|
47
|
-
- autonomy should stay legible, governable, and budget-aware
|
|
45
|
+
|
|
48
46
|
|
|
49
|
-
|
|
47
|
+
|
|
50
48
|
|
|
51
|
-
|
|
49
|
+
|
|
52
50
|
|
|
53
|
-
|
|
51
|
+
|
|
54
52
|
|
|
55
|
-
|
|
53
|
+
- work belongs to an organization, not a loose thread
|
|
54
|
+
- every issue should trace back to a goal
|
|
55
|
+
- agents have roles, runtime config, reporting lines, and skills
|
|
56
|
+
- chat helps clarify and route work, while durable execution stays attached to issues, approvals, outputs, and run history
|
|
57
|
+
- autonomy stays legible, governable, and budget-aware
|
|
56
58
|
|
|
57
59
|
## What Rudder Is
|
|
58
60
|
|
|
59
|
-
Rudder is the operating layer for agent teams. One Rudder instance can run one or many
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
| Human company pattern | Rudder equivalent |
|
|
63
|
-
| --------------------- | ----------------------------------------------- |
|
|
64
|
-
| Company mission | Company goal |
|
|
65
|
-
| Employees | AI agents |
|
|
66
|
-
| Org chart | Agent reporting structure |
|
|
67
|
-
| Work ownership | Issues and assignments |
|
|
68
|
-
| Team workflow | Workflow definitions and execution paths |
|
|
69
|
-
| Operational memory | Knowledge, comments, logs, and activity history |
|
|
70
|
-
| Manager check-ins | Agent heartbeats |
|
|
71
|
-
| Executive review | Board approvals |
|
|
72
|
-
| Budget discipline | Spend tracking and hard stops |
|
|
61
|
+
Rudder is the operating layer for agent teams and AI-native organizations. One Rudder instance can run one or many organizations, each with its own goal, org structure, agents, issues, budgets, approvals, and governance.
|
|
73
62
|
|
|
63
|
+
| Human team pattern | Rudder equivalent |
|
|
64
|
+
| --- | --- |
|
|
65
|
+
| Mission | Organization goal |
|
|
66
|
+
| Employees | AI agents |
|
|
67
|
+
| Org chart | Agent reporting structure |
|
|
68
|
+
| Work ownership | Issues and assignments |
|
|
69
|
+
| Team workflow | Workflow definitions and execution paths |
|
|
70
|
+
| Operational memory | Comments, documents, run history, activity, and skills |
|
|
71
|
+
| Manager check-ins | Agent heartbeats |
|
|
72
|
+
| Executive review | Board approvals |
|
|
73
|
+
| Budget discipline | Spend tracking and hard stops |
|
|
74
74
|
|
|
75
75
|
Rudder coordinates agents. It does not force one runtime, one model, one prompt format, or one execution environment.
|
|
76
76
|
|
|
@@ -78,15 +78,13 @@ Rudder coordinates agents. It does not force one runtime, one model, one prompt
|
|
|
78
78
|
|
|
79
79
|
### Try Rudder
|
|
80
80
|
|
|
81
|
-
The fastest path installs the per-user portable Rudder Desktop app and prepares
|
|
82
|
-
the matching persistent CLI:
|
|
81
|
+
The fastest path installs the per-user portable Rudder Desktop app and prepares the matching persistent CLI:
|
|
83
82
|
|
|
84
83
|
```bash
|
|
85
84
|
npx @rudderhq/cli@latest start
|
|
86
85
|
```
|
|
87
86
|
|
|
88
|
-
After the persistent CLI is available, the direct `rudder` form is the same
|
|
89
|
-
command surface:
|
|
87
|
+
After the persistent CLI is available, the direct `rudder` form is the same command surface:
|
|
90
88
|
|
|
91
89
|
```bash
|
|
92
90
|
rudder start
|
|
@@ -115,6 +113,9 @@ Rudder defaults to embedded PostgreSQL in development. If `DATABASE_URL` is unse
|
|
|
115
113
|
5. Create or convert work into issues.
|
|
116
114
|
6. Let agents pick up work through heartbeat invocations.
|
|
117
115
|
7. Review outputs, approvals, activity, and spend from the board.
|
|
116
|
+
8. Leave feedback on the run, issue, or output.
|
|
117
|
+
9. Preserve reusable lessons as better context, skills, decisions, or workflows.
|
|
118
|
+
10. Future runs use the improved team context.
|
|
118
119
|
|
|
119
120
|
Every durable piece of work should still answer one question: why does this task exist? In Rudder, the intended answer is traceable all the way back to the organization goal.
|
|
120
121
|
|