Most real applications should start as “System 1”: a bounded workflow where the code decides the steps and the model fills in narrow decisions. Add “System 2” autonomy only where open-ended planning clearly pays for its extra cost and risk. When I checked four popular frameworks’ source code, none of them asks a human before an action by default, so the guardrails this article describes are your job to switch on.
The One Question That Decides It
AI engineer Avi Chawla popularised a useful split between System 1 and System 2 agent “harnesses”. It isn’t about which model is smarter. It’s about who controls the workflow. I reduce it to one question: does your code already know the steps, or does the model have to discover them?
- If the steps are known and the hard part is one judgment inside them, use System 1.
- If the next step depends on information that only appears at runtime, use System 2, with guardrails.
A full autonomous loop for a simple classification adds cost and failure modes. Forcing a genuinely exploratory task into a rigid decision tree fails the other way.
System 1: The Model Makes a Bounded Judgment
Your application already knows the valid answers; the model chooses, scores or extracts. Take a support ticket that must go to billing, technical support, account access or fraud. The model makes the semantic call that plain rules struggle with, then your code checks the confidence, applies business rules and either acts or escalates to a person. Code owns the action boundary.
It fits intent classification, model routing, risk gates, reranking, moderation, document classification and field extraction. It’s also easier to test: you measure whether the model picked the right category, not whether a free-form answer “looks right”. Models such as TypeSafe’s Jev are built for this: unstructured context in, typed answers with probabilities out.
System 2: The Model Plans
Here the model gets a goal, constraints and the current state, and decides what to do next. Picture an AI coding agent working out why tests broke after a dependency upgrade: read files, search, run tests, read an error, form a hypothesis, edit, test again. You can’t script that sequence in advance.
Planning freedom doesn’t have to mean execution freedom. A good harness puts a deterministic router between the model and its tools: the model requests an action, and code decides whether the tool is available, the arguments are valid, approval is needed and policy allows it. That matters most for tools that send email, change databases, deploy, spend money or touch production, because those can’t simply be undone.
The Two Side by Side
| Aspect | System 1 harness | System 2 harness |
|---|---|---|
| The model’s job | Choose, score or extract within known options | Plan, act and adapt toward a goal |
| Who owns the workflow | Your code | The model, inside limits your code sets |
| Output | A typed answer with probabilities | Free text and tool calls |
| How you test it | Label accuracy and calibration on a test set | Task success and step-by-step traces |
| Cost and speed | Small and predictable per decision | Variable, many model calls per task |
| Typical failure | A confident wrong choice | Wandering, looping or an unsafe action |
| Typical uses | Routing, classification, risk gates, reranking | Coding agents, research, multi-step operations |
The Best Systems Use Both
A System 2 coding agent can plan how to debug an app, while a System 1 check classifies the risk of each command before it runs and another bounded model decides whether to stop, retry or escalate. That gives the model freedom where reasoning helps and keeps deterministic software in charge of the boundaries that shouldn’t be probabilistic.
We Checked the Defaults: How Much Autonomy Do Frameworks Give an Agent?
Method: on 15 October 2026 we downloaded the current source code of four popular agent frameworks from GitHub and looked up, in the code itself, two settings that decide how “System 2” an agent behaves out of the box: whether a human must approve actions, and how many steps the agent may take before it is stopped. The search was done with AI assistance and every value below was read from the source file. We did not run the frameworks.
| Framework | Human approval by default? | How you turn it on | Default step limit |
|---|---|---|---|
| LangGraph | No | interrupt() inside a node, or interrupt_before / interrupt_after when compiling the graph | Recursion limit of 10,007 steps (overridable with an environment variable) |
| OpenAI Agents SDK | No (needs_approval = False) | Set needs_approval on a tool; input and output guardrails are separate decorators | DEFAULT_MAX_TURNS = 10 |
| CrewAI | No (human_input = False) | human_input=True on a task; guardrails retry up to 3 times by default | max_iter = 25 per agent |
| Microsoft Agent Framework | No (approval_mode = "never_require") | approval_mode="always_require" on a tool | 100 iterations for workflows; 10 in the agent harness loop |
- No framework ships with a human checkpoint. Guardrails exist in all four, but they’re off until you turn them on.
- Step limits differ by a factor of a thousand. An OpenAI Agents SDK run stops after 10 turns; a LangGraph graph can run over ten thousand steps. Move an agent between frameworks and its runaway-cost behaviour changes completely.
- Approval is per tool, not per agent in the OpenAI and Microsoft frameworks. That fits my advice: let the agent read freely, and require a human for tools that send, pay, delete or deploy.
Before deploying, write down your framework’s step limit and list which tools require approval. If the answer is “none”, you’ve built an agent with no human checkpoint, however clever its planning looks.
What Early Evidence Suggests
Independent preprints on Jev, not peer reviewed, report strong accuracy on short, well-scoped judgments but some overconfidence, so check its confidence scores on your own data; I summarise them in the Jev for RAG guide. Turing Post reports that OpenAI announced a Decisions API in limited preview that answers developer-defined questions with finite choices for classification, routing and action selection. Vercel’s guidance on Jev in an agent loop adds three engineering rules: put the decision model at a defined decision point, keep retries separate from routing, and reuse a recorded routing decision when a workflow resumes with unchanged input.
Where the Metaphor Breaks Down
The labels borrow from Daniel Kahneman’s Thinking, Fast and Slow, where System 1 is fast and automatic and System 2 slow and deliberate. Treat it as an analogy about control and cost, not about how AI “thinks”. Bounded doesn’t mean correct: a System 1 model can be confidently wrong, so you still need thresholds and a human path. And the split is about control flow, not model size; a large model can serve in either role.
A Pre-Deployment Checklist
- Can the task be written as a fixed workflow with one or two judgment points? If yes, start with System 1.
- Which tools can send, pay, delete or deploy? Mark each as approval-required.
- What’s the step limit, and what happens when it’s hit?
- Are routing decisions and tool calls logged?
- Have you tested failure cases and a prompt-injection attempt, and compared task success with a simple deterministic baseline?
FAQ
Is System 2 always better for agents?
No. It costs more, is harder to test and has more ways to fail. Use it only where the path genuinely can’t be known in advance.
Do LangGraph or CrewAI ask for human approval by default?
No. In our 15 October 2026 source check, none of LangGraph, the OpenAI Agents SDK, CrewAI or Microsoft Agent Framework required approval by default.
Related: AI agent safety · Which agent frameworks are still maintained · AI agent infrastructure · MiniCPM5-2B for local agents
Sources
- Avi Chawla’s explanation of System 1 vs System 2 agent harnesses on X
- Sanity glossary: Jev (TypeSafe AI model)
- TypeSafe documentation
- Vercel: Jev in an agent loop
- Turing Post: OpenAI DevDay announcements
- Source code of LangGraph, OpenAI Agents SDK, CrewAI and Microsoft Agent Framework on GitHub, read 15 October 2026
