Category: agents
-
Essence Precedes Existence: A Task–Environment–Capacity View of Multi-Agent Systems
TEC describes an agent as a task bound to a capacity through a view of an environment, and uses this framework to examine coordination, context, verification, and self-improvement.
-
Why Is the Agent Loop a Plugin? Inside DeepSeek Harness's Plugin System
TL;DR: In DeepSeek Harness, a Plugin is not an optional attachment to an otherwise complete application. It is a TypeScript module that Cordis mounts inside the same Node.js process with explicit dependencies and a managed lifetime. DSH uses Cordis to create the Context; Cordis then waits for Services, activates the Plugin, and withdraws its Effects when it leaves. The most common activation entry point is apply(ctx). A Tool is only one model-facing action a Plugin may register; the Tool Registry, Session, and even the Agent Loop are themselves Plugins.
-
After You Say ‘Fix This Bug’: How DeepSeek Harness Organizes Turns and Sessions
TL;DR: In DeepSeek Harness, a follow-up Input can wake the Agent Loop; a Turn is one continuous run that may contain several Steps, and each Step is one model request together with the Tools it asks to run. The Session Event Log records more than chat: it preserves execution boundaries, model-visible content, and action results. The Agent Loop is a Plugin that coordinates those Services in order, while persistence, resume, crash recovery, and fork all build on the same history.
-
The Agent Loop Is Only the Beginning: What Does DeepSeek Harness Do Around the Model?
TL;DR: The Agent Loop explains how a model alternates between reasoning and tool calls. A Harness must also decide what the model sees, turn tool calls into real operations, preserve task progress, and stop unsafe actions before they reach the host system.
-
Codex Source Dive (VI): Context Engineering
Codex context is a managed runtime surface: AGENTS.md, skills, thread history, compaction, and runtime settings each have ownership rules that let long-running work survive.
-
Codex Source Dive (V): The Security Model
Codex security is a layered execution membrane: sandboxing defines the technical boundary, approvals decide review, exec policy classifies command risk, and OS backends enforce the result.
-
Codex Source Dive (IV): The Tool Runtime
Codex tools are model-visible schemas backed by a policy-bound runtime that routes shell commands, patches, MCP, skills, permissions, sandboxing, streams, and history through one managed execution path.
-
Self-Harness: Harnesses That Improve Themselves
Self-Harness is best read as evidence-driven harness versioning: mine failed traces, propose bounded scaffold edits, and promote only changes that survive regression tests.