Update README.md
This commit is contained in:
13
README.md
13
README.md
@@ -2,7 +2,6 @@
|
||||
|
||||
**A self-optimizing agentic runtime for small language models**
|
||||
|
||||
---
|
||||
|
||||
## 1. Vision
|
||||
|
||||
@@ -16,7 +15,6 @@ The core insight: **most of the cost in agentic systems isn't the task, it's re-
|
||||
|
||||
> ren minimizes LLM calls by learning from its own successful executions, converting repeated tasks into deterministic, zero-inference scripts — so the small model is only invoked for genuinely novel work.
|
||||
|
||||
---
|
||||
|
||||
## 2. The Problem
|
||||
|
||||
@@ -31,7 +29,6 @@ Existing tools spend 15–20k tokens on system prompt before the user has typed
|
||||
|
||||
**ren's answer:** keep the system prompt minimal (under ~1.5k tokens), and instead of trying to make the model smarter, make the *system* smarter about when to invoke the model at all.
|
||||
|
||||
---
|
||||
|
||||
## 3. Core Design Principles
|
||||
|
||||
@@ -42,7 +39,6 @@ Existing tools spend 15–20k tokens on system prompt before the user has typed
|
||||
5. **The model is a fallback, not the default.** The steady-state behavior of a mature ren installation should be: most tasks resolve via recipe match, and the LLM is invoked only for genuinely novel requests.
|
||||
6. **Everything the system learns is inspectable.** Traces and recipes are plain JSON/scripts on disk — a user (or the model itself) can read exactly what ren has learned to do and why.
|
||||
|
||||
---
|
||||
|
||||
## 4. High-Level Architecture
|
||||
|
||||
@@ -103,7 +99,6 @@ The system has two loops:
|
||||
|
||||
Over time, the ratio of fast-loop to slow-loop invocations should increase for any given user's workflow, since recurring tasks get captured.
|
||||
|
||||
---
|
||||
|
||||
## 5. Component Deep-Dive
|
||||
|
||||
@@ -135,7 +130,6 @@ The core LLM-driven execution engine. Talks to any OpenAI-compatible completions
|
||||
|
||||
These are intentionally general-purpose placeholders. The long-term tool model is closer to MCP servers / pluggable scripts than a fixed hardcoded set.
|
||||
|
||||
---
|
||||
|
||||
### 5.2 Trace Recorder (`trace.rs`)
|
||||
|
||||
@@ -163,7 +157,6 @@ Every agent run — successful or not — is serialized to `traces/<unix_ms>_<sl
|
||||
- `id` doubles as both a unique identifier and a natural sort key (Unix ms timestamp).
|
||||
- The full `messages` array is preserved verbatim — this is what makes recipe extraction possible. Nothing is summarized or lost at record time.
|
||||
|
||||
---
|
||||
|
||||
### 5.3 Recipe Extractor (`recipe.rs`)
|
||||
|
||||
@@ -210,7 +203,6 @@ Saved to `recipes/<id>_<slugified-trigger>.json`.
|
||||
|
||||
`run_count` / `success_count` are pre-wired into the schema for the recipe runner to update — this gives a future confidence-decay mechanism (a recipe that starts failing repeatedly should get deprioritized or flagged for re-extraction) without needing a schema migration later.
|
||||
|
||||
---
|
||||
|
||||
### 5.4 Script Language Decision
|
||||
|
||||
@@ -244,7 +236,6 @@ set -euo pipefail
|
||||
|
||||
`set -euo pipefail` ensures failures propagate instead of silently continuing; the `:` parameter-check pattern gives a clear error if a required env var wasn't supplied.
|
||||
|
||||
---
|
||||
|
||||
## 6. Planned Components (Not Yet Built)
|
||||
|
||||
@@ -282,7 +273,6 @@ This is explicitly lower priority than the success path — the core value propo
|
||||
|
||||
Currently hardcoded (endpoint URL, model name, `MAX_ITERATIONS`, `MAX_TOOL_OUTPUT`). Needs to move to a `ren.toml` before the codebase grows further — flagged as technical debt, not urgent.
|
||||
|
||||
---
|
||||
|
||||
## 7. Technology Choices & Rationale
|
||||
|
||||
@@ -294,7 +284,6 @@ Currently hardcoded (endpoint URL, model name, `MAX_ITERATIONS`, `MAX_TOOL_OUTPU
|
||||
| **Plain JSON files** for traces/recipes (no database, for now) | Fully inspectable and diffable by a human or the model itself. No schema migration tooling needed yet at expected scale (hundreds of recipes). Revisit if/when recipe counts grow past what a flat directory scan can handle at matcher startup time. |
|
||||
| **Environment variables** for recipe parameters | Uniform interface across shell and Python, avoids string-interpolation injection risk entirely, and matches how both languages naturally expect external input. |
|
||||
|
||||
---
|
||||
|
||||
## 8. What "Done" Looks Like (Steady State)
|
||||
|
||||
@@ -305,7 +294,6 @@ A mature ren installation, after some period of use on a given machine/workflow,
|
||||
- The recipe store is a legible, growing library that a user can audit, edit, or delete from directly — it's not a black box.
|
||||
- System prompt size stays flat regardless of how many recipes exist, since recipes are matched via embedding similarity, not stuffed into context.
|
||||
|
||||
---
|
||||
|
||||
## 9. Current Implementation Status
|
||||
|
||||
@@ -321,7 +309,6 @@ A mature ren installation, after some period of use on a given machine/workflow,
|
||||
| Config file (`ren.toml`) | ⏳ Not started |
|
||||
| Tool plugin system (beyond `run_curl` / `run_shell`) | ⏳ Not started |
|
||||
|
||||
---
|
||||
|
||||
## 10. Open Questions Tracker
|
||||
|
||||
|
||||
Reference in New Issue
Block a user