loopengine 0.0.1

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Evan Yan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,336 @@
+# loopengine
+
+A minimal framework for defining and running tool-using AI agents. Write an
+agent as a plain config object — persona, tools, permission rules — and run
+it through one generic ReAct loop over the CLI, an HTTP API, or both. No
+chain DSL, no hidden control flow: `run-agent.ts` is a single readable
+function you can step through top to bottom.
+
+It's built on six small, independently-published packages that each solve
+one piece of the agent-loop problem:
+
+| Package | Responsibility |
+|---|---|
+| [`actauth`](https://www.npmjs.com/package/actauth) | Rule-based permission gating (allow/ask/deny) with human-approval hooks |
+| [`contextclip`](https://www.npmjs.com/package/contextclip) | Context-window budget tracking with staged recovery |
+| [`reflowkit`](https://www.npmjs.com/package/reflowkit) | Retries prompt-too-long / truncated-output failures |
+| [`sessionknit`](https://www.npmjs.com/package/sessionknit) | Durable, DAG-shaped session log with crash-interruption detection |
+| [`skillgarden`](https://www.npmjs.com/package/skillgarden) | `SKILL.md`-based skill discovery and lazy loading |
+| [`toollane`](https://www.npmjs.com/package/toollane) | Schedules approved tool calls into parallel/solo execution lanes |
+
+`run-agent.ts` wires the first five together — `sessionknit` sits one layer
+out, in `session-store.ts`, since it persists what `run-agent.ts` produces
+rather than participating in the loop itself. Everything else in this repo
+— agent definitions, channel adapters — is built on top of those.
+
+## Using loopengine as a library
+
+This repo is two things in one: a small library (the loop itself) and a
+reference app built on top of it (demo agents, a CLI, an HTTP server). Only
+the library half ships to npm:
+
+```bash
+npm install loopengine actauth contextclip reflowkit toollane skillgarden
+```
+
+```ts
+import { runAgent, type AgentConfig, type ToolDefinition } from 'loopengine'
+
+const getWeather: ToolDefinition = {
+  name: 'get_weather',
+  description: 'Look up the weather for a city',
+  input_schema: { type: 'object', properties: { city: { type: 'string' } }, required: ['city'] },
+  execute: async (input) => `Sunny in ${input.city}`,
+}
+
+const config: AgentConfig = {
+  name: 'weather-agent',
+  systemPrompt: 'You answer questions about the weather.',
+  tools: [getWeather],
+  rules: [{ scopePattern: 'default/production/weather-agent', tool: 'get_weather', decision: 'allow' }],
+  defaultDecision: 'ask',
+}
+
+// bring your own ModelCall, or use the one below
+const result = await runAgent(config, myModelCall, "What's the weather in Boston?", [])
+console.log(result.text)
+```
+
+The full exported surface: `runAgent`, `AgentConfig`/`ToolSchema`/`ToolDefinition`,
+`loadAgent` (for MCP-backed tools), `connectMcpTools`, `FileSessionStore`/
+`RedisSessionStore`/`createSessionStore`, `VectorIndex`/`embed`/
+`cosineSimilarity` (for RAG — see below), and `createAnthropicModelCall` (a
+real, ready-to-use `ModelCall`). See `index.ts` for the exact list.
+
+**Not** part of the package: `agents/*.ts` (this repo's own demo agents),
+`agent-registry.ts` (this repo's own name → config lookup table — build your
+own, same one-line-per-agent shape), `adapters/cli.ts`/`adapters/http.ts`
+(one specific CLI/HTTP wiring choice, not imposed on every consumer), and
+the `Dockerfile`. Everything below this point describes that reference app —
+read it as a worked example of what to build with the library, not as
+library API itself.
+
+## Quick start
+
+```bash
+npm install
+npx tsx agents/file-agent.ts             # run the file-summarizer demo agent
+npx tsx agents/customer-service-agent.ts # run the customer-service demo agent
+npx tsx agents/rag-agent.ts              # run the retrieval-augmented demo agent
+```
+
+All demo agents use a **simulated** model call (no `ANTHROPIC_API_KEY` is
+wired up) — see "Wiring a real model" below.
+
+## Defining your own agent
+
+An agent is an `AgentConfig` (`agent-config.ts`): a name, a system prompt, a
+list of tools, and ActAuth permission rules.
+
+```ts
+import type { AgentConfig } from './agent-config.js'
+
+export const config: AgentConfig = {
+  name: 'my-agent',
+  systemPrompt: 'You are ...',
+  tools: [
+    {
+      name: 'do_thing',
+      description: 'What the model sees when deciding to call this',
+      input_schema: { type: 'object', properties: { id: { type: 'string' } }, required: ['id'] },
+      execute: async (input) => {
+        // real implementation — DB call, HTTP request, whatever
+        return { ok: true }
+      },
+    },
+  ],
+  rules: [
+    { scopePattern: 'default/production/my-agent', tool: 'do_thing', decision: 'allow' },
+  ],
+  defaultDecision: 'ask', // anything not covered by a rule requires approval
+}
+```
+
+`agents/file-agent.ts` and `agents/customer-service-agent.ts` are two complete, working
+examples — same `runAgent` loop, entirely different personas and tools.
+
+To make a new agent runnable through the adapters, add one line to
+`agent-registry.ts` mapping its name to its `config` and a `createModelCall`
+factory.
+
+## Connecting MCP tools
+
+A tool doesn't have to be hand-written — `AgentConfig.mcpServers` connects to
+a real MCP server and turns everything it exposes into ordinary tools, with
+the same ActAuth gating and ToolLane scheduling as `do_thing` above:
+
+```ts
+export const config: AgentConfig = {
+  name: 'my-mcp-agent',
+  systemPrompt: 'You are ...',
+  mcpServers: [
+    { command: 'npx', args: ['-y', '@modelcontextprotocol/server-filesystem', '/some/dir'] },
+  ],
+  rules: [
+    { scopePattern: 'default/production/my-mcp-agent', tool: 'read_text_file', decision: 'allow' },
+  ],
+  defaultDecision: 'ask', // any tool the server exposes that you didn't write a rule for
+}
+```
+
+`agents/mcp-filesystem-agent.ts` is a complete example — it has zero hand-written
+tools; every one comes from the official
+`@modelcontextprotocol/server-filesystem`, spawned as a real subprocess.
+`load-agent.ts` is what resolves `mcpServers` into real tools: it runs for
+every agent (a no-op if `mcpServers` is absent), which is what makes this a
+config change rather than a bespoke loader function per server — write rules
+for the tool names you expect the server to expose (check its docs, or
+connect once and call `listTools()` yourself), the same way you'd write
+rules for a hand-written tool. Anything the server exposes that you didn't
+write a rule for still safely falls through to `defaultDecision`.
+
+## Retrieval (RAG)
+
+RAG is just another tool — the model decides when to call it, `run-agent.ts`
+doesn't know or care that "executing" this particular tool means a vector
+search instead of a filesystem read or an MCP round-trip:
+
+```ts
+const searchDocs: ToolDefinition = {
+  name: 'search_docs',
+  description: 'Search the knowledge base for relevant passages',
+  input_schema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] },
+  execute: async (input) => {
+    const hits = index.search(input.query as string, 3) // top-3 chunks
+    return hits.map((h) => h.text).join('\n\n')
+  },
+}
+```
+
+`agents/rag-agent.ts` is a complete example, backed by `vector-index.ts` — a
+small, dependency-free in-memory vector index (feature-hashing embeddings,
+cosine-similarity search) good enough to prove the retrieval mechanics
+end-to-end without wiring up a real embedding API. Swap `embed()` for a real
+embedding model, or swap `VectorIndex` for a real vector DB client, and the
+`search_docs` tool works unchanged — same "host provides the real
+implementation, the package proves the pipeline" pattern as ContextClip's
+`Summarizer` or ActAuth's `Approver`. The retrieved text comes back as an
+ordinary tool result, subject to the same ActAuth gating, ToolLane
+scheduling, and ContextClip budget tracking as any other tool call.
+
+## Running an agent
+
+**CLI:**
+
+```bash
+npx tsx adapters/cli.ts --agent customer-service --session s1 "order A-1001 arrived broken"
+```
+
+**HTTP:**
+
+```bash
+npx tsx adapters/http.ts
+curl -X POST localhost:8787/agents/customer-service/messages \
+  -H 'content-type: application/json' \
+  -d '{"customerEmail":"a@example.com","message":"order A-1001 arrived broken"}'
+```
+
+**HTTP, streamed:** same request, `/stream` suffix, one Server-Sent Event per
+loop step instead of a single response after the whole thing finishes —
+`contextclip:check`, `actauth:decision`, `toollane:result`, ..., a final
+`done` with the answer:
+
+```bash
+curl -N -X POST localhost:8787/agents/customer-service/messages/stream \
+  -H 'content-type: application/json' \
+  -d '{"customerEmail":"a@example.com","message":"order A-1001 arrived broken"}'
+```
+
+Both adapters are thin: they own request parsing and session persistence,
+and call the same `runAgent(config, modelCall, message, history)` underneath.
+`runAgent` itself does no I/O — callers own conversation history, which is
+what lets it serve a one-shot CLI call and a long-lived chat session with no
+code difference. The streaming route isn't a separate code path through
+`runAgent` either — it forwards the same `onEvent` hook the non-streaming
+route just discards, over SSE instead of into a log. What this streams is
+loop *steps* (tool calls, permission decisions, budget checks), not model
+output tokens — no `ModelCall` implementation here (fake or
+`createAnthropicModelCall`) streams partial text from the model itself, so
+there's nothing at the token level to forward yet.
+
+## Sessions and multi-tenancy
+
+`session-store.ts` exposes one method, `withSession(sessionId, fn)`, that
+resumes history, runs `fn` **exclusively** for that session, and appends
+whatever new messages `fn` produced — this is what stops two concurrent
+requests for the same conversation from racing on read-modify-write.
+
+History itself is a [`sessionknit`](https://www.npmjs.com/package/sessionknit)
+log, not a flat file rewritten whole on every turn: each message is one
+entry in an append-only, parent-linked chain, so a turn only ever appends,
+never rewrites what's already durable. That buys two things a flat
+rewrite can't:
+
+- **Non-blocking, debounced writes** instead of a full read-modify-write of
+  the entire session every turn.
+- **Interruption detection.** `run-agent.ts` pushes one
+  `[requested: tool_a, tool_b]` message before any tool runs, then one
+  `[... result]` message per completed tool as they finish. If the process
+  dies in that window, the next `resume()` sees a request with no result
+  behind it, flags the session as resumed-after-interruption, and injects a
+  note into context saying so — instead of silently resending an
+  incomplete turn as if it were clean.
+
+Two implementations, same `SessionStore` interface:
+
+- `FileSessionStore` — one JSONL entry log per session under `.sessions/`,
+  locked in-process. Fine for local dev and the CLI.
+- `RedisSessionStore` — same log shape (a Redis list of entries, one
+  `RPUSH` per append), with a real distributed lock, safe across multiple
+  server instances.
+
+`createSessionStore()` picks between them based on `REDIS_URL` — set it and
+you get Redis, otherwise it falls back to the file store. Either way,
+turn-level exclusivity (no two concurrent turns for the same session
+interleaving) is still this module's job, not SessionKnit's — SessionKnit's
+own topology repair handles branching *within* one resumed chain (parallel
+tool calls, crash recovery), not races between two full concurrent turns.
+
+The HTTP adapter derives the session key from `customerEmail` (hashed, so
+raw emails never end up in storage keys), so different customers can never
+read or write each other's history, and concurrent messages from the same
+customer are serialized rather than dropped.
+
+## Deployment
+
+```bash
+docker compose up --build
+```
+
+builds the HTTP adapter into a container (`Dockerfile`, multi-stage:
+`npm ci` + `tsc`, then a slim runtime image) and starts it alongside a Redis
+container (`docker-compose.yml`). For a real deployment, push the same
+image to any container platform (Cloud Run, Fargate, Fly.io) with `REDIS_URL`
+and any tool-specific secrets set as environment variables.
+
+## Wiring a real model
+
+Every example agent (`agents/file-agent.ts`, `agents/customer-service-agent.ts`,
+`agents/mcp-filesystem-agent.ts`, `agents/rag-agent.ts`) still uses a canned,
+turn-counting `ModelCall` so the whole loop is runnable and testable with no
+API key. To go live, swap it
+for `createAnthropicModelCall` (`anthropic-model-call.ts`), the one real
+`ModelCall` implementation this repo ships:
+
+```ts
+import { createAnthropicModelCall } from './anthropic-model-call.js'
+
+const modelCall = createAnthropicModelCall({ model: 'claude-sonnet-5' }) // reads ANTHROPIC_API_KEY from the env
+
+const result = await runAgent(config, modelCall, 'order A-1001 arrived broken', [])
+```
+
+Nothing else in `run-agent.ts`, the adapters, or any `AgentConfig` needs to
+change — `ModelCall` is the only seam a real API call needs.
+
+One tradeoff worth knowing: loopengine's `Message` type (from `contextclip`)
+is deliberately generic — `{role, content: string}` — so conversation
+history round-trips to the API as plain user/assistant text turns, not
+Anthropic's native `tool_use`/`tool_result` content blocks. Claude reads
+`"[lookup_order result] {...}"` as plain text just fine and the conversation
+still works correctly, but it's not the structured, block-native history the
+API is built around. This was verified against the real SDK (with a stubbed
+`fetch`, not a live call) — request shape, tool schemas, and response
+mapping all round-trip correctly end to end.
+
+## Skills
+
+Agents can discover and invoke `SKILL.md` files (see `skills/`), the same
+convention production coding agents use: a short frontmatter index (`name`,
+`description`) stays in context at all times, and the full body is loaded
+only when the model actually invokes that skill. Set `skillsDirs` on an
+`AgentConfig` to enable it; omit it for agents that don't need skills
+(`agents/customer-service-agent.ts` doesn't).
+
+## Project layout
+
+```
+index.ts                    Public API surface — what actually ships to npm
+agent-config.ts            AgentConfig type — the thing you fill in to define an agent
+run-agent.ts                The generic ReAct loop every agent and adapter runs through
+load-agent.ts               Resolves AgentConfig.mcpServers into real tools (no-op without it)
+mcp-tools.ts                 Wraps one MCP server's tools as ToolDefinition[]
+vector-index.ts             Dependency-free embeddings + cosine-similarity search, for RAG
+agent-registry.ts          Maps agent name -> {config, createModelCall}, via load-agent.ts
+session-store.ts           SessionStore: FileSessionStore, RedisSessionStore, createSessionStore()
+anthropic-model-call.ts    createAnthropicModelCall — the one real ModelCall this repo ships
+agents/file-agent.ts               Example agent: summarizes text files
+agents/customer-service-agent.ts  Example agent: order lookup / refund / email
+agents/mcp-filesystem-agent.ts    Example agent: every tool comes from a real MCP server, zero hand-written
+agents/rag-agent.ts                Example agent: retrieves from an in-memory vector index
+adapters/cli.ts             Channel adapter: command line
+adapters/http.ts            Channel adapter: HTTP API
+skills/                     SKILL.md files discoverable by agents
+examples/file-agent/        Sample input files + generated output for the file-agent demo
+Dockerfile, docker-compose.yml   Container build + local Redis for testing
+```

package/dist/agent-config.d.ts

@@ -0,0 +1,40 @@
+import type { Rule, Decision, Scope, Approver } from 'actauth';
+import type { SafetyClassifier } from 'toollane';
+import type { StdioServerParameters } from '@modelcontextprotocol/sdk/client/stdio.js';
+export interface ToolSchema {
+    name: string;
+    description: string;
+    /** JSON schema sent to the model so it knows how to call the tool. */
+    input_schema: Record<string, unknown>;
+}
+export interface ToolDefinition extends ToolSchema {
+    execute: (input: Record<string, unknown>) => Promise<unknown>;
+}
+export interface AgentConfig {
+    /** Also doubles as the ActAuth scope.agent segment. */
+    name: string;
+    systemPrompt: string;
+    /** Hand-written tools. Default []  — an agent can run on mcpServers alone. */
+    tools?: ToolDefinition[];
+    /** MCP servers to connect at load time (see load-agent.ts); their
+     * tools are discovered via listTools() and appended to `tools`. This
+     * is what makes adding an MCP-backed agent a config change — write
+     * rules for the tool names you expect it to expose (check its docs, or
+     * probe it once), same as for a hand-written tool. Anything it exposes
+     * that you didn't write a rule for still safely falls through to
+     * defaultDecision. */
+    mcpServers?: StdioServerParameters[];
+    /** ActAuth rules, e.g. { scopePattern: 'default/production/customer-service', tool: 'issue_refund', decision: 'ask' } */
+    rules: Rule[];
+    /** Decision when no rule matches. Default 'ask' — new tools are opt-in, not silently allowed. */
+    defaultDecision?: Decision;
+    /** Default ConsoleApprover (blocks on stdin) — pass e.g. a Slack-backed Approver for unattended agents. */
+    approver?: Approver;
+    scope?: Partial<Omit<Scope, 'agent'>>;
+    /** SKILL.md directories this agent can discover and invoke. Omit if the agent has no skills. */
+    skillsDirs?: string[];
+    skillIndexBudgetTokens?: number;
+    contextBudgetTokens?: number;
+    /** Which tools ToolLane may run in a parallel lane. Default: none (every tool runs solo). */
+    isSafeTool?: SafetyClassifier;
+}

package/dist/agent-config.js

@@ -0,0 +1 @@
+export {};

package/dist/anthropic-model-call.d.ts

@@ -0,0 +1,11 @@
+import Anthropic from '@anthropic-ai/sdk';
+import type { ModelCall } from './run-agent.js';
+export interface AnthropicModelCallOptions {
+    /** Defaults to the ANTHROPIC_API_KEY env var, same as the SDK itself. */
+    apiKey?: string;
+    model?: string;
+    maxTokens?: number;
+    /** Inject a pre-configured client instead of building one from apiKey — e.g. to pass a custom `fetch` in tests. */
+    client?: Anthropic;
+}
+export declare function createAnthropicModelCall(options?: AnthropicModelCallOptions): ModelCall;

package/dist/anthropic-model-call.js

@@ -0,0 +1,49 @@
+// The one real ModelCall implementation loopengine ships. Every example
+// agent (file-agent.ts, customer-service-agent.ts, mcp-filesystem-agent.ts)
+// still uses a canned, turn-counting fake so the whole loop is runnable
+// with no API key — swap that fake for createAnthropicModelCall(...) and
+// nothing in run-agent.ts, the adapters, or any AgentConfig changes.
+// ModelCall is the only seam this needed.
+//
+// loopengine's Message type (contextclip) is deliberately generic —
+// {role, content: string} — so conversation history round-trips to the
+// API as plain user/assistant text turns, not Anthropic's native
+// tool_use/tool_result content blocks. Claude reads
+// "[lookup_order result] {...}" as plain text just fine and the
+// conversation still works correctly, but it's not the structured,
+// block-native history the API is built around. If you need that
+// fidelity later, it means changing what run-agent.ts stores in
+// `messages`, not this file.
+import Anthropic from '@anthropic-ai/sdk';
+export function createAnthropicModelCall(options = {}) {
+    const client = options.client ?? new Anthropic({ apiKey: options.apiKey });
+    const model = options.model ?? 'claude-sonnet-5';
+    const maxTokens = options.maxTokens ?? 4096;
+    return async (messages, system, tools) => {
+        const response = await client.messages.create({
+            model,
+            max_tokens: maxTokens,
+            system,
+            messages: messages.map((m) => ({
+                role: m.role === 'assistant' ? 'assistant' : 'user',
+                content: m.content,
+            })),
+            tools: tools.length
+                ? tools.map((t) => ({
+                    name: t.name,
+                    description: t.description,
+                    input_schema: t.input_schema,
+                }))
+                : undefined,
+        });
+        const content = response.content.map((block) => {
+            if (block.type === 'text')
+                return { type: 'text', text: block.text };
+            if (block.type === 'tool_use') {
+                return { type: 'tool_use', id: block.id, name: block.name, input: block.input };
+            }
+            return { type: block.type };
+        });
+        return { stop_reason: response.stop_reason ?? 'end_turn', content };
+    };
+}

package/dist/index.d.ts

@@ -0,0 +1,13 @@
+export { runAgent } from './run-agent.js';
+export type { ModelCall, ModelContentBlock, ModelResponse, RunAgentOptions, RunAgentResult, } from './run-agent.js';
+export type { AgentConfig, ToolSchema, ToolDefinition } from './agent-config.js';
+export { loadAgent } from './load-agent.js';
+export type { LoadedAgent } from './load-agent.js';
+export { connectMcpTools } from './mcp-tools.js';
+export type { McpConnection } from './mcp-tools.js';
+export { FileSessionStore, RedisSessionStore, createSessionStore } from './session-store.js';
+export type { SessionStore, SessionResult } from './session-store.js';
+export { VectorIndex, embed, cosineSimilarity } from './vector-index.js';
+export type { Document, ScoredDocument } from './vector-index.js';
+export { createAnthropicModelCall } from './anthropic-model-call.js';
+export type { AnthropicModelCallOptions } from './anthropic-model-call.js';

package/dist/index.js

@@ -0,0 +1,11 @@
+// The public API — everything a consumer building on loopengine needs to
+// define and run their own agent. `agents/*.ts`, `agent-registry.ts`,
+// `adapters/*.ts`, and the Dockerfile are this repo's own reference app
+// built on top of this surface, not part of it — see the README section
+// "Using loopengine as a library" for the boundary and why.
+export { runAgent } from './run-agent.js';
+export { loadAgent } from './load-agent.js';
+export { connectMcpTools } from './mcp-tools.js';
+export { FileSessionStore, RedisSessionStore, createSessionStore } from './session-store.js';
+export { VectorIndex, embed, cosineSimilarity } from './vector-index.js';
+export { createAnthropicModelCall } from './anthropic-model-call.js';

package/dist/load-agent.d.ts

@@ -0,0 +1,8 @@
+import type { AgentConfig } from './agent-config.js';
+export interface LoadedAgent {
+    /** Same config, with tools = hand-written tools + everything discovered from mcpServers. */
+    config: AgentConfig;
+    /** Closes every MCP connection this load opened. No-op if the config had no mcpServers. */
+    close: () => Promise<void>;
+}
+export declare function loadAgent(config: AgentConfig): Promise<LoadedAgent>;

package/dist/load-agent.js

@@ -0,0 +1,27 @@
+// Resolves an AgentConfig's mcpServers (if any) into real tools. This is
+// what makes MCP support config-driven instead of one bespoke async
+// builder function per server: an agent that declares mcpServers and one
+// that doesn't both go through loadAgent() the same way — it's a no-op
+// passthrough for the latter. agent-registry.ts calls this for every
+// agent, so adding a new MCP-backed agent means writing an AgentConfig,
+// not a new .ts file with its own connection-handling logic.
+import { connectMcpTools } from './mcp-tools.js';
+export async function loadAgent(config) {
+    if (!config.mcpServers?.length) {
+        return { config: { ...config, tools: config.tools ?? [] }, close: async () => { } };
+    }
+    const connections = await Promise.all(config.mcpServers.map(connectMcpTools));
+    const mcpTools = connections.flatMap((c) => c.tools);
+    // Last-one-wins on name collisions (hand-written tool vs. MCP tool, or
+    // two MCP servers exposing the same name) — same resolution run-agent.ts
+    // itself uses when it builds its own tool map. Sending the model a
+    // duplicate tool name in its schema list would be a live API error, so
+    // this dedupes before it gets that far.
+    const byName = new Map([...(config.tools ?? []), ...mcpTools].map((t) => [t.name, t]));
+    return {
+        config: { ...config, tools: [...byName.values()] },
+        close: async () => {
+            await Promise.all(connections.map((c) => c.close()));
+        },
+    };
+}

package/dist/mcp-tools.d.ts

@@ -0,0 +1,11 @@
+import { type StdioServerParameters } from '@modelcontextprotocol/sdk/client/stdio.js';
+import type { ToolDefinition } from './agent-config.js';
+export interface McpConnection {
+    tools: ToolDefinition[];
+    close: () => Promise<void>;
+}
+/** Spawns an MCP server over stdio, discovers its tools via listTools(),
+ * and wraps each one so execute() forwards to callTool() on the real
+ * server. Call close() when the agent is done with it (or on process
+ * shutdown) to kill the child process. */
+export declare function connectMcpTools(serverParams: StdioServerParameters): Promise<McpConnection>;

package/dist/mcp-tools.js

@@ -0,0 +1,31 @@
+// Wraps a real MCP server's tools as ToolDefinition[] — the same shape as
+// any hand-written tool (agent-config.ts), so they drop straight into
+// AgentConfig.tools. Neither run-agent.ts nor ActAuth nor ToolLane know or
+// care that these particular tools proxy to a subprocess speaking MCP
+// instead of running in-process; permission gating and execution still go
+// through the exact same path as lookup_order or read_file.
+import { Client } from '@modelcontextprotocol/sdk/client/index.js';
+import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
+/** Spawns an MCP server over stdio, discovers its tools via listTools(),
+ * and wraps each one so execute() forwards to callTool() on the real
+ * server. Call close() when the agent is done with it (or on process
+ * shutdown) to kill the child process. */
+export async function connectMcpTools(serverParams) {
+    const client = new Client({ name: 'loopengine', version: '0.0.1' });
+    await client.connect(new StdioClientTransport(serverParams));
+    const { tools } = await client.listTools();
+    const toolDefs = tools.map((tool) => ({
+        name: tool.name,
+        description: tool.description ?? tool.name,
+        input_schema: tool.inputSchema,
+        execute: async (input) => {
+            const result = await client.callTool({ name: tool.name, arguments: input });
+            const text = result.content
+                .filter((block) => block.type === 'text')
+                .map((block) => block.text)
+                .join('\n');
+            return result.isError ? { error: text } : text;
+        },
+    }));
+    return { tools: toolDefs, close: () => client.close() };
+}

package/dist/run-agent.d.ts

@@ -0,0 +1,28 @@
+import { type Message } from 'contextclip';
+import type { AgentConfig, ToolSchema } from './agent-config.js';
+export interface ModelContentBlock {
+    type: string;
+    text?: string;
+    id?: string;
+    name?: string;
+    input?: Record<string, unknown>;
+}
+export interface ModelResponse {
+    stop_reason: string;
+    content: ModelContentBlock[];
+}
+/** Swap the Anthropic SDK in here — this is the only seam a real API call needs. */
+export type ModelCall = (messages: Message[], system: string, tools: ToolSchema[]) => Promise<ModelResponse>;
+export interface RunAgentOptions {
+    /** Emitted at each loop step for callers that want visibility (logging, UI, tests). Default: no-op. */
+    onEvent?: (event: string, detail: unknown) => void;
+}
+export interface RunAgentResult {
+    /** Final assistant text for this turn. */
+    text: string;
+    /** Full conversation so far, including this turn — pass back in as
+     * `history` on the next call to continue the conversation. Opaque to
+     * the caller: store/transmit it, don't inspect or mutate it. */
+    history: Message[];
+}
+export declare function runAgent(config: AgentConfig, modelCall: ModelCall, userMessage: string, history?: Message[], options?: RunAgentOptions): Promise<RunAgentResult>;

package/dist/run-agent.js

@@ -0,0 +1,100 @@
+// The one ReAct loop every agent runs through, and every channel adapter
+// (CLI, HTTP, ...) calls unchanged — only their AgentConfig and modelCall
+// differ. runAgent itself does no I/O and holds no state between calls:
+// callers own conversation history, which is what lets the same function
+// serve a one-shot CLI invocation and a long-lived chat session.
+import { Gate, RuleSet, ConsoleApprover } from 'actauth';
+import { SkillGarden } from 'skillgarden';
+import { ContextClipper } from 'contextclip';
+import { ToolLane } from 'toollane';
+import { Reflow } from 'reflowkit';
+export async function runAgent(config, modelCall, userMessage, history = [], options = {}) {
+    const log = options.onEvent ?? (() => { });
+    const scope = { tenant: 'default', environment: 'production', ...config.scope, agent: config.name };
+    const skillGarden = config.skillsDirs?.length
+        ? new SkillGarden({ dirs: config.skillsDirs, indexBudgetTokens: config.skillIndexBudgetTokens ?? 200 })
+        : null;
+    const skillIndex = skillGarden?.buildIndex().included ?? [];
+    const contextClip = new ContextClipper({ budgetTokens: config.contextBudgetTokens ?? 8000, tailMessages: 4 });
+    const rules = new RuleSet(config.rules, config.defaultDecision ?? 'ask');
+    const gate = new Gate(rules, config.approver ?? new ConsoleApprover());
+    const toolLane = new ToolLane({ isSafe: config.isSafeTool ?? (() => false) });
+    const reflow = new Reflow({
+        onPromptTooLong: async (messages) => {
+            const result = await contextClip.recover(messages);
+            log('reflow:recover', { from: messages.length, to: result.messages.length });
+            return result.messages;
+        },
+    });
+    // Optional on AgentConfig — an MCP-only agent's tools are populated by
+    // load-agent.ts before this ever runs, but default defensively here too
+    // in case a config reaches runAgent without going through it.
+    const tools = config.tools ?? [];
+    const toolsByName = new Map(tools.map((t) => [t.name, t]));
+    const toolSchemas = tools.map(({ name, description, input_schema }) => ({
+        name,
+        description,
+        input_schema,
+    }));
+    const systemPrompt = skillIndex.length
+        ? `${config.systemPrompt}\n\nAvailable skills:\n${skillIndex.map((s) => `- ${s.name}: ${s.description}`).join('\n')}`
+        : config.systemPrompt;
+    let messages = [...history, { role: 'user', content: userMessage }];
+    for (;;) {
+        const budget = contextClip.check(messages);
+        log('contextclip:check', budget);
+        if (budget.action === 'nudge' && budget.nudge)
+            messages.push(budget.nudge);
+        const { value: response, recoveries } = await reflow.call((msgs) => modelCall(msgs, systemPrompt, toolSchemas), messages);
+        if (recoveries.length > 0)
+            log('reflow:recoveries', recoveries);
+        const toolUseBlocks = response.content.filter((b) => b.type === 'tool_use');
+        if (toolUseBlocks.length === 0) {
+            const text = response.content.find((b) => b.type === 'text')?.text ?? '';
+            log('loop:done', text);
+            messages.push({ role: 'assistant', content: text });
+            return { text, history: messages };
+        }
+        // Skill invocation injects instructions into context; it isn't a tool
+        // that needs ActAuth gating or ToolLane scheduling.
+        const skillCall = toolUseBlocks.find((b) => b.name === 'Skill');
+        if (skillCall && skillGarden) {
+            const body = skillGarden.invoke(skillCall.input.skill);
+            log('skillgarden:invoke', skillCall.input.skill);
+            messages.push({ role: 'assistant', content: `[called Skill: ${skillCall.input.skill}]` });
+            messages.push({ role: 'user', content: body });
+            continue;
+        }
+        const approved = [];
+        const denied = [];
+        const reasons = new Map();
+        for (const block of toolUseBlocks) {
+            const decision = await gate.evaluate(block.name, block.input ?? {}, scope);
+            log('actauth:decision', { tool: block.name, decision: decision.decision, reason: decision.reason });
+            if (decision.decision === 'allow') {
+                approved.push(block);
+            }
+            else {
+                denied.push(block);
+                reasons.set(block.id, decision.reason);
+            }
+        }
+        messages.push({ role: 'assistant', content: `[requested: ${toolUseBlocks.map((b) => b.name).join(', ')}]` });
+        // Every requested tool gets exactly one result message back — a denied
+        // call is not simply dropped, or the model has no way to tell "denied"
+        // apart from "hasn't run yet" and may just re-request it forever.
+        for (const block of denied) {
+            messages.push({ role: 'user', content: `[${block.name} result] denied: ${reasons.get(block.id)}` });
+        }
+        const calls = approved.map((b) => ({
+            id: b.id,
+            name: b.name,
+            execute: () => toolsByName.get(b.name).execute(b.input ?? {}),
+        }));
+        for await (const result of toolLane.run(calls)) {
+            const summary = result.status === 'fulfilled' ? JSON.stringify(result.value) : `ERROR: ${result.error}`;
+            log('toollane:result', { name: result.name, summary });
+            messages.push({ role: 'user', content: `[${result.name} result] ${summary}` });
+        }
+    }
+}

package/dist/session-store.d.ts

@@ -0,0 +1,52 @@
+import { type Storage } from 'sessionknit';
+import type { Message } from 'contextclip';
+export interface SessionResult<T> {
+    history: Message[];
+    result: T;
+}
+export interface SessionStore {
+    /** Loads history for sessionId, runs fn exclusively — no other
+     * withSession call for the same sessionId runs concurrently, in this
+     * process or (for RedisSessionStore) any other — appends the new
+     * messages fn's result adds, and resolves with fn's result. */
+    withSession<T>(sessionId: string, fn: (history: Message[]) => Promise<SessionResult<T>>): Promise<T>;
+    close(): Promise<void>;
+}
+/** Wraps a SessionKnit log behind the flat load/run/append contract
+ * runAgent's callers use. Shared by both the file- and Redis-backed
+ * stores below — only the Storage and the lock differ. */
+declare class SessionKnitStore implements SessionStore {
+    private readonly lock;
+    private readonly onClose;
+    private readonly knit;
+    constructor(storage: Storage<Message>, lock: <T>(sessionId: string, fn: () => Promise<T>) => Promise<T>, onClose?: () => Promise<void>);
+    withSession<T>(sessionId: string, fn: (history: Message[]) => Promise<SessionResult<T>>): Promise<T>;
+    close(): Promise<void>;
+}
+/** One JSONL entry log per session under `dir`. Fine for a single local
+ * process (CLI, dev server); not safe across multiple processes/instances
+ * — those need RedisSessionStore. */
+export declare class FileSessionStore extends SessionKnitStore {
+    constructor(dir: string);
+}
+/** Redis-backed store for multi-instance deployments. Locking is a
+ * single-instance-Redis lock (SET NX PX + a compare-and-delete unlock
+ * script) — good enough as long as session state lives in one Redis; true
+ * multi-node Redlock is overkill until it doesn't. This lock is what keeps
+ * two concurrent turns for the same session from interleaving appends
+ * across instances — SessionKnit's own topology repair handles branching
+ * *within* one resumed chain, not that. */
+export declare class RedisSessionStore extends SessionKnitStore {
+    private readonly lockTtlMs;
+    private readonly lockRetryDelayMs;
+    private readonly lockMaxWaitMs;
+    private readonly redis;
+    constructor(redisUrl: string, lockTtlMs?: number, lockRetryDelayMs?: number, lockMaxWaitMs?: number);
+    private lockKeyFor;
+    private withLock;
+}
+/** Picks the store from environment so adapters don't hardcode a backend:
+ * REDIS_URL set -> RedisSessionStore (required once you run >1 instance),
+ * otherwise FileSessionStore under .sessions (fine for local dev). */
+export declare function createSessionStore(): SessionStore;
+export {};

package/dist/session-store.js

@@ -0,0 +1,170 @@
+// Where conversation history lives between calls to runAgent, and how
+// concurrent requests for the *same* session are kept from racing on
+// read-modify-write. Adapters never call load/save directly — they go
+// through withSession, so locking isn't something each adapter has to
+// remember to do correctly.
+//
+// Storage itself is SessionKnit: a durable, append-only, parent-linked log
+// per session, rather than a flat blob rewritten whole on every turn. That
+// buys two things runAgent's history array can't give itself:
+//   - non-blocking, debounced writes instead of a full read-modify-write
+//     of the entire session on every turn
+//   - interruption detection — if the process dies between requesting
+//     tools and recording their results (run-agent.ts pushes an
+//     "[requested: ...]" message before any tool runs, then one
+//     "[... result]" message per completed tool), the next resume() sees
+//     an unresolved request and injects a note into context saying so,
+//     instead of silently resending an incomplete turn as if it were
+//     clean.
+// SessionKnit's own topology repair is for branches *within* one resumed
+// chain (parallel tool calls, crash recovery) — it isn't a substitute for
+// turn-level exclusivity, so this module still serializes concurrent
+// withSession calls for the same sessionId itself (KeyedMutex / a Redis
+// lock), same as before.
+import { randomUUID } from 'node:crypto';
+import path from 'node:path';
+import { Redis } from 'ioredis';
+import { SessionKnit, FileStorage } from 'sessionknit';
+/** Serializes async work per key within this process. Good enough for
+ * FileSessionStore (single process); RedisSessionStore needs a real
+ * distributed lock instead since multiple server instances share it. */
+class KeyedMutex {
+    tails = new Map();
+    run(key, fn) {
+        const prevTail = this.tails.get(key) ?? Promise.resolve();
+        const result = prevTail.then(fn, fn);
+        this.tails.set(key, result.catch(() => { }));
+        return result;
+    }
+}
+// run-agent.ts pushes exactly one "[requested: tool_a, tool_b]" assistant
+// message before any tool executes, then one "[tool result]" user message
+// per completed tool as they finish (adapters/http.ts, adapters/cli.ts
+// never see this — it lives entirely inside the messages array runAgent
+// returns). If the process dies in that window, the request message is the
+// last thing on disk with no result behind it.
+function hasUnresolvedToolCall(message) {
+    return message.role === 'assistant' && message.content.startsWith('[requested:');
+}
+function buildContinuation() {
+    return {
+        role: 'user',
+        content: '[session resumed after an interruption — the assistant had requested tool calls but the process stopped before any results were recorded; treat those tools as not having run]',
+    };
+}
+/** Wraps a SessionKnit log behind the flat load/run/append contract
+ * runAgent's callers use. Shared by both the file- and Redis-backed
+ * stores below — only the Storage and the lock differ. */
+class SessionKnitStore {
+    lock;
+    onClose;
+    knit;
+    constructor(storage, lock, onClose = async () => { }) {
+        this.lock = lock;
+        this.onClose = onClose;
+        this.knit = new SessionKnit(storage, { hasUnresolvedToolCall, buildContinuation });
+    }
+    async withSession(sessionId, fn) {
+        return this.lock(sessionId, async () => {
+            const { messages, leafId } = await this.knit.resume(sessionId);
+            const { history: nextHistory, result } = await fn(messages);
+            // Everything fn's history grew by beyond what resume() handed it —
+            // this naturally excludes the synthetic continuation message too
+            // (it's already counted in messages.length), which is exactly right:
+            // it's a resend-only hint, never meant to be durably stored.
+            let parentId = leafId;
+            for (const message of nextHistory.slice(messages.length)) {
+                const id = randomUUID();
+                await this.knit.append(sessionId, { id, parentId, message });
+                parentId = id;
+            }
+            await this.knit.flush(sessionId);
+            return result;
+        });
+    }
+    async close() {
+        await this.onClose();
+    }
+}
+const fileMutex = new KeyedMutex();
+/** One JSONL entry log per session under `dir`. Fine for a single local
+ * process (CLI, dev server); not safe across multiple processes/instances
+ * — those need RedisSessionStore. */
+export class FileSessionStore extends SessionKnitStore {
+    constructor(dir) {
+        super(new FileStorage(dir), (sessionId, fn) => fileMutex.run(path.resolve(dir, sessionId), fn));
+    }
+}
+/** SessionKnit Storage backed by a Redis list — one RPUSH per appended
+ * entry. Redis is already durable per write, so unlike FileStorage there's
+ * nothing to debounce: flush() is a no-op. */
+class RedisEntryStorage {
+    redis;
+    constructor(redis) {
+        this.redis = redis;
+    }
+    keyFor(sessionId) {
+        return `session-log:${sessionId}`;
+    }
+    async append(sessionId, entry) {
+        await this.redis.rpush(this.keyFor(sessionId), JSON.stringify(entry));
+    }
+    async flush() { }
+    async readAll(sessionId) {
+        const raw = await this.redis.lrange(this.keyFor(sessionId), 0, -1);
+        return raw.map((line) => JSON.parse(line));
+    }
+}
+/** Redis-backed store for multi-instance deployments. Locking is a
+ * single-instance-Redis lock (SET NX PX + a compare-and-delete unlock
+ * script) — good enough as long as session state lives in one Redis; true
+ * multi-node Redlock is overkill until it doesn't. This lock is what keeps
+ * two concurrent turns for the same session from interleaving appends
+ * across instances — SessionKnit's own topology repair handles branching
+ * *within* one resumed chain, not that. */
+export class RedisSessionStore extends SessionKnitStore {
+    lockTtlMs;
+    lockRetryDelayMs;
+    lockMaxWaitMs;
+    redis;
+    constructor(redisUrl, lockTtlMs = 30_000, lockRetryDelayMs = 50, lockMaxWaitMs = 15_000) {
+        const redis = new Redis(redisUrl);
+        super(new RedisEntryStorage(redis), (sessionId, fn) => this.withLock(sessionId, fn), () => redis.quit().then(() => { }));
+        this.lockTtlMs = lockTtlMs;
+        this.lockRetryDelayMs = lockRetryDelayMs;
+        this.lockMaxWaitMs = lockMaxWaitMs;
+        this.redis = redis;
+    }
+    lockKeyFor(sessionId) {
+        return `session-lock:${sessionId}`;
+    }
+    async withLock(sessionId, fn) {
+        const lockKey = this.lockKeyFor(sessionId);
+        const token = randomUUID();
+        const deadline = Date.now() + this.lockMaxWaitMs;
+        for (;;) {
+            const ok = await this.redis.set(lockKey, token, 'PX', this.lockTtlMs, 'NX');
+            if (ok)
+                break;
+            if (Date.now() > deadline)
+                throw new Error(`timed out waiting for lock on session '${sessionId}'`);
+            await new Promise((resolve) => setTimeout(resolve, this.lockRetryDelayMs));
+        }
+        try {
+            return await fn();
+        }
+        finally {
+            // Only delete if we still hold it — otherwise we'd release a lock our
+            // TTL already expired and a different request has since acquired.
+            const script = `if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end`;
+            await this.redis.eval(script, 1, lockKey, token);
+        }
+    }
+}
+/** Picks the store from environment so adapters don't hardcode a backend:
+ * REDIS_URL set -> RedisSessionStore (required once you run >1 instance),
+ * otherwise FileSessionStore under .sessions (fine for local dev). */
+export function createSessionStore() {
+    const redisUrl = process.env.REDIS_URL;
+    return redisUrl ? new RedisSessionStore(redisUrl) : new FileSessionStore('.sessions');
+}

package/dist/vector-index.d.ts

@@ -0,0 +1,25 @@
+/** Hashes each token into one of EMBEDDING_DIMENSIONS buckets (FNV-1a),
+ * with the hash's sign deciding +1/-1 to reduce collision bias, then
+ * L2-normalizes. Works on tokens it's never seen and needs no training
+ * step, at the cost of real embedding quality — a stand-in, not a
+ * production embedding model. */
+export declare function embed(text: string): Float64Array;
+/** Both inputs are unit vectors (embed() normalizes), so the dot product
+ * already is the cosine similarity. */
+export declare function cosineSimilarity(a: Float64Array, b: Float64Array): number;
+export interface Document {
+    id: string;
+    text: string;
+}
+export interface ScoredDocument extends Document {
+    score: number;
+}
+/** In-memory vector store: add() embeds and keeps the document, search()
+ * returns the top-k most similar by cosine similarity. Swap for a real
+ * vector DB (pgvector, Pinecone, ...) once the corpus outgrows memory —
+ * same shape, so callers (like a search_docs tool) don't need to change. */
+export declare class VectorIndex {
+    private readonly documents;
+    add(id: string, text: string): void;
+    search(query: string, topK?: number): ScoredDocument[];
+}

package/dist/vector-index.js

@@ -0,0 +1,72 @@
+// A small, dependency-free vector index for RAG demos — feature-hashing
+// embeddings (no external embedding API call, no vocabulary to train)
+// plus cosine-similarity search. Real technique (the "hashing trick"),
+// just not a learned one — good enough to prove the retrieval mechanics
+// end-to-end without wiring up a live embedding model. Swap embed() for a
+// real one and VectorIndex works unchanged: same seam as ContextClip's
+// Summarizer or ActAuth's Approver — a working default the rest of the
+// pipeline can be built and tested against.
+// Higher dimensions mean fewer hash collisions between unrelated tokens,
+// which matters more here than with a learned embedding since there's no
+// training to smooth collisions out — 1024 keeps ranking stable for the
+// short, few-dozen-document corpora this is meant for.
+const EMBEDDING_DIMENSIONS = 1024;
+function tokenize(text) {
+    return text.toLowerCase().match(/[a-z0-9]+/g) ?? [];
+}
+function normalize(vector) {
+    let magnitude = 0;
+    for (const value of vector)
+        magnitude += value * value;
+    magnitude = Math.sqrt(magnitude);
+    if (magnitude === 0)
+        return vector;
+    const result = new Float64Array(vector.length);
+    for (let i = 0; i < vector.length; i++)
+        result[i] = vector[i] / magnitude;
+    return result;
+}
+/** Hashes each token into one of EMBEDDING_DIMENSIONS buckets (FNV-1a),
+ * with the hash's sign deciding +1/-1 to reduce collision bias, then
+ * L2-normalizes. Works on tokens it's never seen and needs no training
+ * step, at the cost of real embedding quality — a stand-in, not a
+ * production embedding model. */
+export function embed(text) {
+    const vector = new Float64Array(EMBEDDING_DIMENSIONS);
+    for (const token of tokenize(text)) {
+        let hash = 2166136261; // FNV offset basis
+        for (let i = 0; i < token.length; i++) {
+            hash ^= token.charCodeAt(i);
+            hash = Math.imul(hash, 16777619); // FNV prime
+        }
+        const bucket = Math.abs(hash) % EMBEDDING_DIMENSIONS;
+        const sign = hash & 1 ? 1 : -1;
+        vector[bucket] += sign;
+    }
+    return normalize(vector);
+}
+/** Both inputs are unit vectors (embed() normalizes), so the dot product
+ * already is the cosine similarity. */
+export function cosineSimilarity(a, b) {
+    let dot = 0;
+    for (let i = 0; i < a.length; i++)
+        dot += a[i] * b[i];
+    return dot;
+}
+/** In-memory vector store: add() embeds and keeps the document, search()
+ * returns the top-k most similar by cosine similarity. Swap for a real
+ * vector DB (pgvector, Pinecone, ...) once the corpus outgrows memory —
+ * same shape, so callers (like a search_docs tool) don't need to change. */
+export class VectorIndex {
+    documents = [];
+    add(id, text) {
+        this.documents.push({ id, text, vector: embed(text) });
+    }
+    search(query, topK = 3) {
+        const queryVector = embed(query);
+        return this.documents
+            .map(({ id, text, vector }) => ({ id, text, score: cosineSimilarity(queryVector, vector) }))
+            .sort((a, b) => b.score - a.score)
+            .slice(0, topK);
+    }
+}

package/package.json

@@ -0,0 +1,56 @@
+{
+  "name": "loopengine",
+  "version": "0.0.1",
+  "type": "module",
+  "description": "A minimal framework for defining and running tool-using AI agents over CLI, HTTP, or both.",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/evanyan22/loopengine.git"
+  },
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "files": [
+    "dist/index.js",
+    "dist/index.d.ts",
+    "dist/run-agent.js",
+    "dist/run-agent.d.ts",
+    "dist/agent-config.js",
+    "dist/agent-config.d.ts",
+    "dist/load-agent.js",
+    "dist/load-agent.d.ts",
+    "dist/mcp-tools.js",
+    "dist/mcp-tools.d.ts",
+    "dist/session-store.js",
+    "dist/session-store.d.ts",
+    "dist/vector-index.js",
+    "dist/vector-index.d.ts",
+    "dist/anthropic-model-call.js",
+    "dist/anthropic-model-call.d.ts",
+    "LICENSE"
+  ],
+  "scripts": {
+    "build": "tsc",
+    "prepublishOnly": "npm run build",
+    "start": "node dist/adapters/http.js",
+    "test": "vitest run"
+  },
+  "dependencies": {
+    "@anthropic-ai/sdk": "^0.116.0",
+    "@modelcontextprotocol/sdk": "^1.30.0",
+    "actauth": "^0.0.2",
+    "contextclip": "^0.0.1",
+    "ioredis": "^6.0.0",
+    "reflowkit": "^0.0.1",
+    "sessionknit": "^0.0.2",
+    "skillgarden": "^0.0.1",
+    "toollane": "^0.0.1"
+  },
+  "devDependencies": {
+    "@modelcontextprotocol/server-filesystem": "^2026.7.10",
+    "@types/node": "^26.2.0",
+    "tsx": "^4.19.0",
+    "typescript": "^5.7.0",
+    "vitest": "^2.1.9"
+  }
+}