Harngine: an execution framework for TypeScript agent applications

I'm building Harngine, a TypeScript execution framework for agent applications. A model can answer a turn or propose a tool call, but an application also needs to decide which calls are allowed, when to wait for a person, how to continue after a restart, and how to explain what ran. Harngine provides the runtime for that work.

An application defines Agents, Workflows, and Tools, then starts Work. Harngine persists the execution and its history. The application still owns its UI, users, domain rules, and definition of success. Model adapters handle provider transport; Tool adapters connect external systems.

The five concepts

An Agent or Workflow defines how a task can run. Work records this particular run. That distinction matters when a process restarts or a developer needs to inspect a decision afterward.

What Harngine handles

Execution and recovery. Work has a stable identity and persisted state. Workflows use named durable operations, so completed steps can be recognized when execution resumes. A task can wait for a timer or a person without losing its place.

Tool boundaries. Tools declare input and output schemas. Harngine validates Calls, checks authority and approval policy, records attempts, and supports cancellation. Model output proposing a Tool does not by itself grant permission to execute it.

Human decisions. A Workflow or Agent can wait for a question or approval. The interaction and its outcome become part of the Work history.

Inspection. Applications can examine context, model responses, decisions, Tool activity, interactions, and results. This gives developers more than a final answer when they need to understand behavior.

Continuity. Sessions can carry conversation across multiple objectives, while each objective remains separate Work. This is useful for an assistant that works with a person over time.

Harngine currently runs as an embedded Node.js runtime backed by SQLite. One application process owns a runtime directory at a time, and active Work needs its original Agent and Tool revisions to continue after a restart. Harngine does not choose the product's UI or business policy. External writes still need an idempotency or reconciliation strategy appropriate to the target system; persisted Work does not make an external effect happen exactly once.

Where it fits

Harngine can support coding assistants, support processes, research tools, and persistent interactive applications. The repository includes examples of different shapes, from a small Workflow to larger applications. They are ways to use the framework, rather than its limits.

Version 0.1.0 is available on npm and requires Node.js 24.21 or later in the 24.x line. The public API may change before v1.

npm install harngine

Start with the source and examples or read the framework guide. The small recovery example shows a typed Tool call and a durable timer without requiring a model account.

For a brief visual introduction, watch the Harngine framework video. It includes two example applications after the framework overview.

I'm interested in the execution problems other builders encounter. Where do your agent applications need more control or visibility: recovery, Tool authority, human approval, or the history of a run?