# Kortecx-core: A Distributed Runtime Kernel for AI Agents

> Kortecx-core is a distributed runtime for AI Agents written in Rust, focusing on solving the exactly-once orchestration problem in Agent workflows and providing reliable fault recovery mechanisms for non-deterministic Agent steps that change the external world.

- 板块: [Openclaw Llm](https://www.zingnex.cn/en/forum/board/openclaw-llm)
- 发布时间: 2026-05-23T09:14:46.000Z
- 最近活动: 2026-05-23T09:21:38.815Z
- 热度: 157.9
- 关键词: AI Agent, 分布式运行时, Rust, exactly-once, 容错, 事件溯源, 工作流编排
- 页面链接: https://www.zingnex.cn/en/forum/thread/kortecx-core-ai-agent
- Canonical: https://www.zingnex.cn/forum/thread/kortecx-core-ai-agent
- Markdown 来源: floors_fallback

---

## Introduction / Main Floor: Kortecx-core: A Distributed Runtime Kernel for AI Agents

Kortecx-core is a distributed runtime for AI Agents written in Rust, focusing on solving the exactly-once orchestration problem in Agent workflows and providing reliable fault recovery mechanisms for non-deterministic Agent steps that change the external world.

## Original Author and Source

- **Original Author/Maintainer**: Kortecx Team
- **Source Platform**: GitHub
- **Original Title**: kortecx-core
- **Original Link**: https://github.com/Kortecx/kortecx-core
- **Release Date**: May 23, 2026

## Project Background and Motivation

Most current Agent frameworks have fundamental flaws in handling fault recovery. Agent workflows differ from traditional data pipelines: Agent steps call model sampling and may change the external world—invoking tools, accessing APIs, writing to external systems. These operations cannot be safely recomputed: if a worker node crashes during execution, it may lead to duplicate payments, duplicate emails, or data with silent errors.

Existing frameworks usually use simple retry mechanisms or do not handle this at all, leading to hidden state leaking into worker node memory, fragile coordination via message queues, and no persistent records of attempts or successes. When problems occur, developers can only debug by reading logs.

Kortecx-core takes the opposite stance: every Agent attempt is a persistent fact appended to the log. During recovery, committed steps are never re-run—instead, results are re-read.

## Core Design Philosophy

Kortecx-core treats Agent workflows as a set of atomic operations requiring exactly-once semantics. This is similar to data stream processing systems like Spark, but with fundamental adjustments for Agent scenarios:

- **Not a recomputable description**: Traditional RDDs are recomputable, while Mote (Kortecx's minimal execution unit) is a persisted attempt record
- **Append log as coordination mechanism**: Schedulers, executors, and recovery mechanisms are coordinated via facts committed to the log, not direct message passing
- **Projection as read view**: Dependency graphs, ready sets, lineage relationships, etc., are query projections of the log, not persisted mutable graphs

## Mote: Atomic Execution Unit

Mote is the minimal indivisible unit for runtime scheduling, movement, and recovery. It is a persisted record of an attempt to do something, not a recomputable description. A committed Mote is a fact in the log and is never re-run during recovery.

Each Mote carries a non-deterministic label:
- **PURE**: Pure function, no side effects
- **READ-ONLY-NONDET**: Read-only non-deterministic operation
- **WORLD-MUTATING**: Operation that changes the external world

The runtime uses different recovery strategies based on the label: proactive recovery for safe labels, and operator-gated recovery for dangerous labels.

## Log: Synchronization Base

The log is append-only, and the runtime's dependency graph is a projection folded from the log (event sourcing), never stored as a mutable graph. This makes the jump from single-node to distributed a matter of wiring, not rewriting.

## Content Storage: Load Separation

The log only carries a 32-byte content hash (ContentRef); the actual payload is stored in content storage using content-addressable naming. Automatic deduplication is a free side effect. The local file system implementation is open-sourced with the core, and S3 and replication implementations follow the same trait.

## Build Requirements

- Rust 1.94.0 (fixed via rust-toolchain.toml; rustup automatically installs the correct channel)
- just (install via cargo install just or package manager)