@tangle-network/agent-runtime 0.318.0 → 0.319.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tangle-network/agent-runtime",
-  "version": "0.318.0",
+  "version": "0.319.3",
   "description": "Shared task-lifecycle skeleton for agents: a recursive loop kernel for chat turns, one-shot tasks, and multi-attempt loops, with trace capture and eval-gated self-improvement. Domain behavior lives in adapters; scoring and ship-gates in @tangle-network/agent-eval.",
   "homepage": "https://github.com/tangle-network/agent-runtime#readme",
   "repository": {
@@ -113,10 +113,13 @@
     "@arethetypeswrong/cli": "0.18.5",
     "@biomejs/biome": "^2.5.11",
     "@modelcontextprotocol/sdk": "1.30.0",
-    "@tangle-network/agent-eval": "0.211.3",
-    "@tangle-network/agent-interface": "^3.1.1",
-    "@tangle-network/agent-provider-tangle": "2.0.0",
-    "@tangle-network/sandbox": "^0.60.0",
+    "@tangle-network/agent-eval": "0.213.0",
+    "@tangle-network/agent-interface": "5.2.0",
+    "@tangle-network/agent-provider-cli-bridge": "2.0.0",
+    "@tangle-network/agent-provider-daytona": "0.6.0",
+    "@tangle-network/agent-provider-e2b": "0.6.0",
+    "@tangle-network/agent-provider-tangle": "4.0.0",
+    "@tangle-network/sandbox": "0.60.49",
     "@types/node": "26.4.0",
     "@types/tar-stream": "3.1.4",
     "miniflare": "4.20260722.0",
@@ -137,15 +140,15 @@
   },
   "license": "MIT",
   "peerDependencies": {
-    "@tangle-network/agent-eval": ">=0.209.1 <0.212.0",
-    "@tangle-network/agent-interface": "^3.1.1",
+    "@tangle-network/agent-eval": ">=0.213.0 <0.214.0",
+    "@tangle-network/agent-interface": "^5.2.0",
     "@tangle-network/sandbox": ">=0.58.4 <0.61.0"
   },
   "dependencies": {
     "@earendil-works/pi-codemode": "1.0.4",
-    "@tangle-network/agent-core": ">=0.10.3 <0.11.0",
-    "@tangle-network/agent-knowledge": "^20.0.1",
-    "@tangle-network/agent-profile-materialize": ">=0.21.0 <0.23.0",
+    "@tangle-network/agent-core": ">=0.12.0 <0.13.0",
+    "@tangle-network/agent-knowledge": "^22.0.1",
+    "@tangle-network/agent-profile-materialize": ">=0.25.2 <0.26.0",
     "@tangle-network/agent-trace-contract": "^2.0.0",
     "tar-stream": "3.2.1",
     "zod": "4.6.5"

package/skills/codemode/references/runtime-execution.md

@@ -16,9 +16,16 @@ This does not require the Pi coding harness.
 For ONE node of a graph — a code node beside ordinary agent nodes — declare it on the
 node's pinned profile instead of the environment: `model.metadata.codeMode = true` (or
 `{ concurrency, maxCalls, timeoutMs, memoryLimitBytes, directTools }`). The profile
-declaration overrides the backend default for that node alone, and every graph node is
-its pinned profile, so this is the whole authoring surface: no seam change, no new node
-kind. Validation is fail-loud (unknown or host-owned fields are refused before any request).
+declaration enables code mode for that node; `false` opts that node out even when its
+backend defaults to code mode. This changes presentation only: profile tool grants,
+handler authorization, Runtime budgets and metering still apply. `true` and an empty
+object inherit the host's settings.
+For enabled nodes, each numeric setting is the smaller of the explicit host ceiling and
+profile request. Omitted settings inherit; engine defaults apply only if neither supplies
+one. Host and profile `directTools` are combined, so a profile cannot make a host's
+direct-only capability callable from a program. Restored `store` always belongs to the
+host and survives profile declarations. This keeps one authoring surface and no new node
+kind. Unknown or host-owned profile fields are refused before any request.
 
 The implementation uses the standalone `@earendil-works/pi-codemode` QuickJS/WASM worker.
 There is no unsafe Node VM fallback. Code cannot read host files, processes or network

package/skills/graph-designer/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: graph-designer
+description: Design, replay, and improve agent graphs — an agent whose job is the graph, not the work.
+---
+
+# Graph Designer
+
+When an input arrives, your job is NOT to do the work. It is to pick or design the GRAPH
+that does the work, run it under your granted permissions, and record what happened.
+Every execution is fully traced like any graph run — the registry plus the run's journal
+is the knowledge.
+
+## The loop (every input)
+
+1. Compute the task shape: the durable description you will look this kind of work up by
+   (kind, source, constraints — stable fields, not the payload itself). Hash it.
+2. `lookupGraph(registry, taskDigest)` over YOUR WORKSPACE's registry:
+   - **replay** → run the stored graph verbatim. Re-bind the deliverable's check from the
+     environment (oracles are never stored). Record the run. This path spends near-zero
+     inference: no re-authoring, no redesign — the graph IS the answer.
+   - **author** (with the stated reason) → design per the `agent-graphs` skill, run it,
+     record it. If a prior graph failed to deliver for this shape, mutate deliberately
+     (budget, directives as new prompt-registry versions, model mix, an added analyst),
+     never blindly: name what the prior record says went wrong.
+3. Record EVERY run: `recordGraphRun` with the terminal accounting. The registry is the
+   compounding asset — a run you don't record is knowledge you burn.
+
+## Where the registry lives
+
+The registry is files in your workspace (`graph-registry/records.jsonl` + content-addressed
+graphs). In a sandbox, snapshots carry it: a rerun over the same sandbox finds every graph
+ever run. Do not store the deliverable's check function — the environment re-binds it.
+
+## Improving, honestly
+
+Replay is the default; improvement is the exception with a reason. Read the prior records:
+delivered-and-cheapest wins (`pickBestGraph`); a no-winner with budget exhaustion wants
+budget or scope changes, not a new topology; repeated near-misses want a directive rewrite
+(a new prompt-registry version — directives are data, old versions stay). Prefer mutating
+one axis at a time so the next record attributes the difference. When an optimizer run
+(agent-eval) is available, feed it the losing graph's journal; otherwise your reasoned
+mutation IS the search step.
+
+## Profiles improve the same way graphs do
+
+A worker profile is named and content-addressed; when a mutation rewrites a node's
+prompt, record the run in the profile registry too (`recordProfileRun`) — same shape
+as the graph registry, one level down. The winning revision per name is then an
+answered question (`bestProfileFor`), not an argument: delivered beats failed, then
+cheaper, then recent, and revisions never overwrite so old-vs-new is always a
+controlled diff.
+
+## Then consider
+
+- `agent-graphs` for the authoring contract (roles, edges, deliverable, budget).
+- `codemode` when a node's work is mechanical composition — `model.metadata.codeMode`.
+- The run's own ledger (`GraphResult.ledger`, the journal) as the evidence for every decision above.