@tangle-network/agent-runtime 0.344.0 → 0.349.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tangle-network/agent-runtime",
-  "version": "0.344.0",
+  "version": "0.349.0",
   "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": {
@@ -112,14 +112,14 @@
   "devDependencies": {
     "@arethetypeswrong/cli": "0.18.5",
     "@biomejs/biome": "^2.5.11",
-    "@modelcontextprotocol/sdk": "1.30.0",
-    "@tangle-network/agent-eval": "0.220.1",
-    "@tangle-network/agent-interface": "5.7.0",
+    "@modelcontextprotocol/sdk": "1.32.0",
+    "@tangle-network/agent-eval": "0.221.2",
+    "@tangle-network/agent-interface": "5.7.1",
     "@tangle-network/agent-provider-cli-bridge": "2.0.1",
     "@tangle-network/agent-provider-daytona": "0.6.0",
     "@tangle-network/agent-provider-e2b": "0.6.0",
-    "@tangle-network/agent-provider-tangle": "4.4.6",
-    "@tangle-network/sandbox": "0.64.13",
+    "@tangle-network/agent-provider-tangle": "4.4.7",
+    "@tangle-network/sandbox": "0.64.39",
     "@types/node": "26.4.0",
     "@types/tar-stream": "3.1.4",
     "miniflare": "4.20260722.0",
@@ -140,15 +140,15 @@
   },
   "license": "MIT",
   "peerDependencies": {
-    "@tangle-network/agent-eval": ">=0.218.1 <0.221.0",
-    "@tangle-network/agent-interface": ">=5.7.0 <6.0.0",
+    "@tangle-network/agent-eval": ">=0.221.2 <0.222.0",
+    "@tangle-network/agent-interface": ">=5.7.1 <6.0.0",
     "@tangle-network/sandbox": ">=0.61.1 <0.61.2 || >=0.62.2 <0.62.3 || >=0.62.14 <0.62.16 || >=0.63.10 <0.65.0"
   },
   "dependencies": {
     "@earendil-works/pi-codemode": "1.0.4",
-    "@tangle-network/agent-core": ">=0.13.1 <0.14.0",
-    "@tangle-network/agent-knowledge": "^22.0.13",
-    "@tangle-network/agent-profile-materialize": ">=0.25.2 <0.26.0",
+    "@tangle-network/agent-core": ">=0.13.2 <0.14.0",
+    "@tangle-network/agent-knowledge": "^22.0.16",
+    "@tangle-network/agent-profile-materialize": ">=0.27.3 <0.28.0",
     "@tangle-network/agent-trace-contract": "^2.1.0",
     "tar-stream": "3.2.1",
     "zod": "4.6.5"

package/skills/agent-graphs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: agent-graphs
-description: Author fixed AgentGraph roles, routes, delegation, analysis, completion and budgets.
+description: Design factories and fixed AgentGraph roles, routes, delegation, checks and budgets.
 ---
 
 # Agent Graphs
@@ -9,7 +9,7 @@ Use `runGraph` when roles are known before execution and their relationships mus
 When the order, branches, repair loops and stop rules are known too, author a flow graph: `entry` plus `routes` edges, with no root and no brain.
 Parallel stages are a fork (`to` lists several nodes, spawned at once) and waiting for all of them is a join (`from` lists several nodes); converging plain routes into one running node throw `GraphRouteError` with reason `target-live`.
 A loop per item is a flow graph inside a maps item, and a flow graph can run as a `run_graph` subtask.
-A human approval in a flow is a gate (`gates: [{ id, question, choices }]` with one routes edge per choice matching `/choice`), answered by the caller's `decideGate` while the run is held; a wait of days without a held process belongs to a Platform workflow `wait.*` or `decision` action.
+A caller-decided branch can use a gate (`gates: [{ id, question, choices }]` with one routes edge per choice matching `/choice`), answered by `decideGate` while the run is held. For factory human review, end the run as described below.
 Keep a root (delegation edges) only when a model must decide what runs next; a root brain that only orders fixed stages is the anti-pattern a flow graph replaces.
 Use a smaller maintained composition when it provides the required behavior.
 Use dynamic supervision when the agent must discover or create roles while working.
@@ -18,6 +18,44 @@ A request for review alone does not require a graph.
 Read the current [API decision table](https://github.com/tangle-network/agent-runtime/blob/main/docs/canonical-api.md), [AgentGraph contract](https://github.com/tangle-network/agent-runtime/blob/main/src/runtime/supervise/graph.ts), and a relevant [runnable example](https://github.com/tangle-network/agent-runtime/tree/main/examples/graphs).
 These distinguish the fixed AgentGraph API from other graph or supervision contracts.
 
+Production designs: search [Factory’s design catalog](https://github.com/tangle-network/factory/blob/main/README.md) before authoring a new graph.
+
+## Design a factory
+
+Use the vocabulary from the [software-factory design reference](https://github.com/mattpocock/skills/pull/1316) when a consumer needs recurring work across graph executions.
+A **task** defines repeatable work, such as implementation or review, on a ticket, PR, or codebase.
+A **run** is one execution of that task, including any graph nodes and agent sessions it needs.
+A **trigger** starts a run; a **runner** supplies its execution environment.
+Keep task identity stable across runs and record each run's own identity and result.
+
+Name the product that owns each service slot before authoring the task's graph:
+
+| Slot | Responsibility |
+| --- | --- |
+| Ticket tracker | Durable work requests, discussion, and human decisions |
+| Ticket source | External feedback or signals that create tickets |
+| Git host | Source revisions, branches, PRs, and reviews |
+| Orchestrator | Admit triggers, start runs, and retain their status |
+| Observability platform | Inspect run logs, traces, and failures; choose none explicitly if existing run pages suffice |
+
+One product may fill several slots. Reuse each existing owner and its durable records.
+Name the runner too; retain work and decisions through the owning services before its process exits.
+An observability signal that should change work must reach the tracker or git host through an explicit task or ticket source.
+
+Treat triggers as **accelerators** and checks as **brakes**.
+Deterministic checks establish required behavior; independent automated review examines the change; human review supplies decisions and findings that improve both.
+Honor the consumer's existing merge and release policy rather than adding approval gates.
+Introduce automated triggers individually with an explicit throttle, such as a sampling rate, schedule, or concurrency cap; increase admission only after reviewing failures and accepted outcomes.
+Bound repair cycles by attempts and budget, then record unresolved work for human review.
+
+Factory runs never wait for a human.
+Publish the question or review request durably and finish; a later human decision triggers a new run that reads that record.
+An in-run graph gate holds execution and therefore does not implement this factory boundary.
+
+Before implementation, answer for every task: what triggers it; which services it reads and writes; what runs next; where humans re-enter; and how overlapping runs avoid duplicate work.
+For each ticket source, name how duplicate tickets are prevented.
+The design is complete when every slot has an owner, every task has those answers, and trigger throttles and repair limits are explicit.
+
 ## Author the required relationships
 
 Define the artifact and independent completion check before choosing roles.

package/skills/graph-designer/SKILL.md

@@ -10,6 +10,8 @@ that does the work, run it under your granted permissions, and record what happe
 Every execution is fully traced like any graph run — the registry plus the run's journal
 is the knowledge.
 
+Production designs: search [Factory’s design catalog](https://github.com/tangle-network/factory/blob/main/README.md) before authoring; record a delivered Factory run through `recordGraphRun` like any graph.
+
 ## The loop (every input)
 
 1. Compute the task shape: the durable description you will look this kind of work up by
@@ -41,6 +43,10 @@ one axis at a time so the next record attributes the difference. When an optimiz
 (agent-eval) is available, feed it the losing graph's journal; otherwise your reasoned
 mutation IS the search step.
 
+When the registry promotes a winning topology for a task type, retain a case under
+`skills/agent-graphs/cases/` citing the run and its measured outcome. The cited record
+provides the evidence; a descriptive ranking alone does not establish a win.
+
 ## Profiles improve the same way graphs do
 
 A worker profile is named and content-addressed; when a mutation rewrites a node's

package/skills/profile-authoring/SKILL.md

@@ -13,7 +13,7 @@ Do not constrain agents with prohibitions: change what is rewarded and who is in
 ## A profile that starts
 
 A refused profile fails before its first model turn, and it fails the same way on every retry.
-On 2026-10-10 Discovery lost 20 driver attempts to unpublished tool names and 3 spawns to a missing subscription source.
+Discovery lost 20 driver attempts to unpublished tool names and 3 spawns to a missing subscription source.
 Start from a profile that already ran (in a Discovery play, `inputs/profile-examples/<family>.json`) and change only `name`, `description` and `prompt.instructions`.
 
 | Field | Rule |