System 1 vs System 2 agent harnesses, with Jev in the System 1 role
Explains two ways to put AI inside an app: System 1 has the model make bounded judgments from options set by code, where Jev fits, while System 2 has the model plan multi-step tasks with code still holding permissions.
System 1 vs. System 2 Agent Harnesses, clearly explained: (bookmark this) There are two different ways to put AI inside an application. A System 1 harness asks the model to make a bounded judgment. The app provides a request and relevant state. The model selects a constrained result such as a category, score, route, or extracted field. Code checks confidence and policy before executing the result or escalating the case. The model does not own the workflow. It selects from choices supplied by code. This works well for intent classification, model routing, risk gates, reranking, and other high-volume decisions where the possible outputs are known in advance. Jev is designed for this System 1 role to make fast, bounded judgments while application code controls the workflow. A System 2 harness handles work whose path cannot be specified upfront. The LLM receives a goal, constraints, and current state. It plans the next step, while a guarded router controls which tools it can invoke. Tool results return to the harness, which updates state and verifies progress. Each cycle can end in a final action, a question for the user, or another plan. The LLM helps drive the workflow, but it should not have authority. Tool permissions, budgets, stop conditions, and final execution remain in application code. This pattern is useful for coding, research, incident investigation, and other tasks involving several dependent actions. So this is not primarily a small-model versus large-model distinction but rather a difference in control flow. Most production apps need both: System 1 for fast, bounded judgments and System 2 for ambiguous or multi-step work. The next engineering problem is running both patterns without maintaining a separate execution layer for every harness. And the solution to this is now actually open-source and implemented in HarnessRouter. It provides the infrastructure layer between an application and the harnesses that execute its work. - Its System One base can run Jev and other decision models that select finite actions using typed outputs and confidence gates. - Its agent-harness bases support runtimes such as Codex, Claude Code, and Hermes, which can plan, call tools, manage files, and complete open-ended tasks. GitHub repo: http://github.com/HarnessRouter/harnessrouter (don't forget to star it ⭐) HarnessRouter does not make these systems reason identically. Instead, it only standardizes the infrastructure surrounding their execution. Through the Unified Harness Protocol, an application gets one contract for starting tasks, streaming progress, continuing sessions, exchanging files, cancelling work, and reporting structured failures. This lets an application select the appropriate harness without rebuilding its task lifecycle around every runtime. If you want to dive deeper, Akshay wrote a detailed article explaining how HarnessRouter and the Unified Harness Protocol provide this infrastructure layer. It covers why model routing is not harness routing, how tasks and sessions work across runtimes, the local setup, and a complete API call. Read it below.
This post quotes another post: x.com/703601972/status/2100888166219886818